Google har en god dag i retten

Selv hvis linjerne ikke var fjernet, så har en ekspert indkaldt af Oracle tidligere oplyst, at de ikke repræsenterede en værdi.

Keeper32 (3) skrev:

Skyder man så ikke sig selv lidt i foden? =-)

Brugernavn skrev:

Han var nok på Googles lønningsliste :-P

nielsbjerg (6) skrev:

Eller også var det bare 9 linier som ikke var fantastisk vigtige..

Keeper32 (3) skrev:

Selv hvis linjerne ikke var fjernet, så har en ekspert indkaldt af Oracle tidligere oplyst, at de ikke repræsenterede en værdi.

Skyder man så ikke sig selv lidt i foden? =-)

private static void rangeCheck(int arrayLen, int fromIndex, int toIndex) {
if (fromIndex > toIndex)
throw new IllegalArgumentException("fromIndex(" + fromIndex +
") > toIndex(" + toIndex+")");

if (fromIndex < 0)
throw new ArrayIndexOutOfBoundsException(fromIndex);

if (toIndex > arrayLen)
throw new ArrayIndexOutOfBoundsException(toIndex);

}

nielsbjerg (1) skrev:

Jeg glæder mig til den dag, hvor software producenter kigger hindanden dybt i øjnene og bliver enige om, at aflyse sowtware patenter. Det virker som om hele gamet er opfundet af dygtige advokater for at have noget at bestille....

ykok (5) skrev:

Glæder mig så endnu mere til den dag hvor patent trolls firmaerne også gør det

Emil Melgaard (12) skrev:

Jeg tror de havde svært ved at finde en ekspert der mente at denne kode er $6 milliarder værd

XorpiZ (14) skrev:

Handler retssagen ikke om copyright?

kasperd (15) skrev:

Når firmaer af den størrelse først sagsøger hinanden, så er det vist normal procedure at blande det hele sammen i et kæmpe søgsmål.

kasperd (15) skrev:

Der er kun en sikker måde at undgå at blive sagsøgt for at overtræde et patent, og det er ved at lade være med at lave nogle produkter. Og det er der nogen der har opdaget og gjort til en forretningsmodel.

kblood (10) skrev:

You want 6 billion? That would have to be a big fat nooo.

XorpiZ (14) skrev:

Handler retssagen ikke om copyright?

kasperd (15) skrev:

Der er kun en sikker måde at undgå at blive sagsøgt for at overtræde et patent, og det er ved at lade være med at lave nogle produkter.

arne_v (19) skrev:

Sagen handler om:
* nogle patenter
* nogle specifikke kode copyright krænkelser
* copyright på API i sin helhed

Så der er også patenter i sagen.

Men denne nyhed drejer sig om de specifikke kode copyright krænkelser.

Hvor der altså er 9 linier som er ulovligt kopieret tilbage i sagen (der var også nogle unit tests som var kopieret, men da de ikke er distribueret med Android så er de røget ud af sagen - formentligt samtidigt med at antallet af patenter blev skåret ned fra 6 til 2).

Incauta (13) skrev:

Er det ikke de samme linier kode, som en gut fra Google selv har doneret til Sun i sin tid?

f-style (7) skrev:

da Oracle primært opkøbte Sun for at sagsøge andre firmaer

Borgbjerg (8) skrev:

kilde?

f-style (11) skrev:

http://news.cnet.com/8301-30685_3-20013549-264.htm...
http://www.forbes.com/sites/timworstall/2011/06/19...
http://www.computerworld.com/s/article/9131829/Ora...
http://www.techdirt.com/articles/20100813/00004910...

Måske lidt for hårdt sagt at det var deres primære grund, men det er et af grundende til de købte sun.

During the integration meetings between Sun and Oracle, where we were being grilled about the patent situation between Sun and Google, we could see the Oracle lawyer's eyes sparkle.

arne_v (20) skrev:

De sikrer sig at de har så stor en patent portefølje at det afskrækker de fleste fra at sagsøge dem.

arne_v (22) skrev:

Og jeg ved iøvrigt ikke om den relevant kode var lavet af nogle af de nuværende Google ansatte.

kasperd (24) skrev:

Det virker bare kun imod firmaer, der rent faktisk laver noget. Et firma hvis eneste aktivitet er at sagsøge andre for patentovertrædelser har ingen grund til at frygte en stort portefølje. Det eneste der kan afskrække den slags firmaer er advokater.

kasperd (24) skrev:

Situationen bliver ekstra interessant hvis samme person har skrevet kode til hvert af firmaerne med samme formål. I så fald er der en hvis sandsynlighed for at den resulterende kode ender med at være identisk. (Jo større mængde kode, des mindre sandsynlighed for at de er identiske).

Det vil ikke være en overtrædelse af ophavsretten selvom de to implementationer er identiske.

kasperd (15) skrev:

Nej, men at ligefrem kalde koden værdiløs er heller ikke fair. Google burde dømmes til at betale en erstatning på et par hundrede dollars for at have kopieret den kode. (Og så kan de to firmaer dele sagsomkostningerne).

kasperd (24) skrev:

Situationen bliver ekstra interessant hvis samme person har skrevet kode til hvert af firmaerne med samme formål. I så fald er der en hvis sandsynlighed for at den resulterende kode ender med at være identisk. (Jo større mængde kode, des mindre sandsynlighed for at de er identiske).

arne_v (25) skrev:

Men den antallet af successfulde firmaer i den branche er dog heldigvis begrænset.

Emil Melgaard (28) skrev:

Det er rigtigt, men det er jo stadigvæk ikke afgjort om det er "fair use" eller "de minimis".

Emil Melgaard (28) skrev:

Det er den samme person (Joshua Bloch) der oprindeligt har skrevet det da han arbejdede for Sun, men han har indrømmet at han nok har kopieret det til Android i stedet for at skrive det igen:

http://www.theverge.com/2012/4/19/2961128/google-c...

Emil Melgaard (28) skrev:

Det forhindrer dem dog ikke i at sagsøge. Jeg tror ikke der er nogen stor virksomhed med en stor patentportefølge der ikke på et eller andet tidspunkt er blevet sagsøgt for patentmisbrug.

arne_v (30) skrev:

Jeg er sikker på at Google enten har omskrevet dem eller med glæde vil gøre det.

arne_v (26) skrev:

Det er gængs praksis i branchen ikke at tillade folk at implementere det samme som de har implementeret for et andet firma.

kblood (34) skrev:

#34

Jo, det er

kasperd (33) skrev:

Det har intet med ophavsret at gøre. Men det er nok ikke et usædvanligt krav for en konkurrenceklausul. Men en konkurrenceklausul er en aftale mellem en medarbejder og en virksomhed. Den kan aldrig pålægge en anden virksomhed forpligtelser. Desuden er konkurrenceklausuler tidsbegrænset. Typisk løber de kun et år.

Hvis det var sådan forløbet havde været kunne Oracle gøre krav imod den pågældende medarbejder, såfremt koden var skrevet igen indenfor et år efter han forlod Sun. Men de kunne aldrig gøre Google ansvarlig. Hvis derimod koden er kopieret er det et andet spørgsmål. I sidste ende lyder det dog ikke til at der er kopieret kode i et omfang der er af nogen interesse.

If you have looked at Microsoft's proprietary implementation of .NET or their shared source code (which is also proprietary), you will not be able to contribute to Mono. If you would like to contribute in this area, be careful to not look into them in Visual Studio debugging experience.

In general, be careful when you are implementing free software and you have access to proprietary code. We need to make sure that we are not using someone else's copyrighted code accidentally.

Do not use the ildasm, reflector or other equivalent tools program to disassemble proprietary code when you are planning to reimplement a class for Mono. If you have done this, we will not be able to use your code.

With the success of the IBM PC in 1983, Phoenix decided to provide an IBM PC compatible ROM BIOS to the PC market. A licensable ROM BIOS would allow clone PC manufacturers to run the same applications, and even the MS-DOS that was being used by IBM. However, to do this Phoenix needed a strategy for defense against IBM copyright infringement lawsuits. IBM would claim that the Phoenix programmers had copied parts of the IBM BIOS code published by IBM in its Technical Reference manuals.[citation needed] Due to the nature of low-level programming two well-written pieces of code that perform the same function there will inevitably be some degree of similarity. As such it would be impossible for Phoenix to defend itself on the grounds that no part of its BIOS matched IBM's. Phoenix developed a "clean room" technique that isolated the engineers who had been contaminated by reading the IBM source listings in the IBM Technical Reference Manuals. The contaminated engineers wrote specifications for the BIOS APIs and provided the specifications to "clean" engineers who had not been exposed to IBM BIOS source code. Those "clean" engineers developed code from scratch to mimic the BIOS APIs. This technique provided Phoenix with a defensibly non-infringing IBM PC-compatible ROM BIOS. Because the programmers who wrote the Phoenix code had never read IBM's reference manuals, nothing they wrote could have been copied from IBM's code, no matter how closely the two matched.[4] The first Phoenix PC ROM BIOS was introduced in May, 1984, and helped fuel the growth in the PC industry.

B. Residual Rights. If You examine the Technology after accepting
this License and remember anything about it later, You are not
"tainted" in a way that would prevent You from creating or
contributing to an independent implementation, but this License grants
You no rights to Sun's copyrights or patents for use in such an
implementation.

18. Does the JRL prevent me from being able to create an independent open source implementation of the licensed technology?

The JRL is not a tainting license and includes an express Òresidual knowledgeÓ clause which says you're not contaminated by things you happen to remember after examining the licensed technology. The JRL allows you to use the source code for the purpose of JRL-related activities but does not prohibit you from working on an independent implementation of the technology afterwards. Obviously, if your intention is to create an ÒindependentÓ implementation of the technology then it is inappropriate to actively study JRL source while working on such an implementation. It is appropriate, however, to allow some decent interval of time (e.g. two weeks) to elapse between working on a project that involves looking at some JRL source code and working on a project that involves creating an independent implementation of the same technology.

kasperd (35) skrev:

kblood (34) skrev:

#34

Jo, det er

Skal det forstås sådan at du er uenig med dig selv?

arne_v (37) skrev:

Mono er meget klare i deres formulering.

kblood (40) skrev:

Var den del jeg besvarede.

kasperd (41) skrev:

kblood (40) skrev:

Var den del jeg besvarede.

Det fremgår dog ikke, den tekst var ikke engang en del af indlæg nummer #34 som du skrev svaret til.

kblood (42) skrev:

men ser nu ud til at du forstod det var et svar til dig siden du besvarede det.

kasperd (41) skrev:

Men det har næppe noget at gøre med, hvad der er lovligt og hvad der ikke er. Der er ingen der har interesse i at blive sagsøgt, heller ikke selvom man intet ulovligt har gjort. Og hvis der skulle være kode som af den ene eller den anden grund ligner hinanden, så vil der være nogen som tror det er kopieret, det behøver det ikke være.

Enten er man nødt til at have dygtige advokater, der kan bevise at man er uskyldig. Eller også er man nødt til at tage nogle ekstreme forholdsregler for at undgå tvivlstilfælde.

To win a claim of copyright infringement in civil or criminal court, a plaintiff must show he or she owns a valid copyright, the defendant actually copied the work, and the level of copying amounts to misappropriation. Under the doctrine of substantial similarity, a work can be found to infringe copyright even if the wording of text has been changed or visual or audible elements are altered.

Direct evidence of actual copying by a defendant rarely exists, so plaintiffs must often resort to indirectly proving copying. Typically, this is done by first showing that the defendant had access to the plaintiff's work and that the degree of similarity between the two works is so striking or substantial that the similarity could only have been caused by copying, and not, for example, through "coincidence, independent creation, or a prior common source." Some courts also use "probative similarity" to describe this standard. This inquiry is a question of fact determined by a jury.

The Abstraction-Filtration-Comparison test (AFC) is a method of identifying substantial similarity for the purposes of applying copyright law. In particular, the AFC test is used to determine whether non-literal elements of a computer program have been copied. The AFC test was developed by the United States Court of Appeals for the Second Circuit in 1992 in its opinion for Computer Associates Int. Inc. v. Altai Inc. It has been widely adopted by United States courts and recognized by courts outside the United States as well.

The AFC test is a three-step process for determining substantial similarity of the non-literal elements of a computer program. The process requires the court to first identify the increasing levels of abstraction of the program. Then, at each level of abstraction, material that is not protectable by copyright is identified and filtered out from further examination. The final step is to compare the defendant's program to the plaintiff's, looking only at the copyright-protected material as identified in the previous two steps, and determine whether the plaintiff's work was copied. In addition, the court will assess the relative significance of any copied material with respect to the entire program.

arne_v (46) skrev:

that the degree of similarity between the two works is so striking or substantial that the similarity could only have been caused by copying, and not, for example, through "coincidence, independent creation, or a prior common source."