Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 112, views: 37.137 •

Er zijn in de Android-broncode stukken code gevonden die exact lijken op code die toebehoort aan Oracle en met copyright zijn beschermd. Het is echter onzeker of de bewuste bestanden ook gebruikt zijn in de firmware van smartphones.

Patentenblog Foss Patents vond zes bestanden waaruit blijkt dat grote delen code lijken te zijn gekopieerd uit Java 2 Standard Edition. Het weblog stelde een aantal pdf-documenten op waarin de code van enkele Java-files vergeleken wordt met het equivalent in de Android-broncode die door Google werd gepubliceerd bij de release van Android-versies Froyo en Gingerbread: uit de documenten blijkt dat de code inderdaad een kopie van Java-software lijkt te zijn.

Daarnaast werden er in de Android-broncode 37 files gevonden waarvan de header meldt dat de code toebehoort aan Sun Microsystems, het bedrijf dat door Oracle is overgenomen. Daarbij stond er ook vermeld dat de code niet zomaar verspreid mag worden, terwijl Google de code onder de Apache-licentie uitgeeft met zijn Android-besturingssysteem.

Foss Patents kwam de overeenkomsten in code op het spoor door verscheidene bestanden in een subdirectory van de Java-code genaamd acl te vergelijken met het equivalent uit de Android-code; hiervoor werd de decompiler JAD gebruikt.

Oracle klaagde Google in augustus aan voor inbreuk op zeven van zijn patenten, die het verkreeg door de overname van Java-maker Sun Microsystems. De genoemde patenten beschrijven met name de wijze waarop Java werkt. Later deed Oracle hier nog een schepje bovenop door in een aanklacht te claimen dat Google code voor Android rechtstreeks heeft gekopieerd van Java.

Om dat hard te maken diende Oracle bij de rechtbank een bewijsstuk in om het kopiëren aan te tonen. Hiervoor werd het bestand PolicyNodeImpl.java van zowel Android als Java met elkaar vergeleken.

Door de nieuwe vondsten lijkt het erop dat Google niet erg sterk staat in de zaak tegen Oracle. Echter stellen andere bronnen dat de bewuste bestanden niet daadwerkelijk gebruikt zijn in het Android-OS. Zo meldt ZDnet dat de gekopieerde software vooral bedoeld is voor test-doeleinden, en beschikbaar is gesteld door Sun om code te kunnen debuggen. Tevens achterhaalde de site dat Google de file PolicyNodeImpl.java, waar Oracle naar verwijst in de rechtszaak, al op 30 oktober heeft verwijderd. De andere zes bestanden zijn kortgeleden uit de Android-broncode gehaald, waarbij ontwikkelaar Dan Bornstein aangeeft dat het om "zinloze tests" gaat.

Arstechnica kwam na het bestuderen van de files tot dezelfde conclusie, en meldt dat de betrokken bestanden aan de Android-broncode zijn toegevoegd door het bedrijf Sonivox, een lid van de Open Handset Alliance die formeel de ontwikkelaar is van Android. Hierdoor is het aannemelijk dat Google niet bewust delen van Java-code heeft overgenomen voor gebruik in zijn mobiele besturingssysteem.

Het is onbekend in hoeverre de gekopieerde code invloed zal hebben in de rechtzaak die Oracle tegen Google aanspande: zelfs wanneer de internetgigant inderdaad de bewuste bestanden niet gebruikt heeft om de verscheidene versies van het Android-OS mee uit te brengen, heeft het de code waarvan Oracle eigenaar is wel zonder de benodigde toestemming onder de Apache-licentie uitgebracht.

Eerder verdedigde de internetgigant zich door te stellen dat Oracle in het aangeleverde bewijsmateriaal delen van de headers had gemodificeerd of verwijderd. Het blijkt echter dat de headers, waarin melding wordt gemaakt van het copyright, er in de originele bestanden wel zijn, en tevens te vinden zijn in de broncode van Android.

Daarnaast is eveneens onbekend in hoeverre dit invloed zal hebben op de smartphonemakers die Android-toestellen uitbrengen: hoewel de broncode files bevat met kopieën van Java-code hoeft dat niet te betekenen dat fabrikanten deze code daadwerkelijk hebben gebruikt.

De patentclaims rondom Android vormen de grootste bedreiging voor het snel groeiende mobiele besturingssysteem. Naast Google zelf zijn ook diverse fabrikanten aangeklaagd wegens patentschendingen in het OS. De patentclaims maken het voor fabrikanten minder aantrekkelijk om Android-toestellen te maken. Analisten verwachten dat Android in 2011 het wereldwijd marktleiderschap op het gebied van smartphoneplatformen gaat overnemen van Symbian.

Code Android vs Java

Reacties (112)

Reactiefilter:-11120104+165+26+30
Dit is niet zo slim van google... maar is heir nooit iemand anders eerder achter gekomen?
Als je het artikel goed leest en vooral het bronartikel van ZDnet is een aanrader, dan zul je zien dat er niet veel (niets) van de claims overblijft en er zeker geen grond voor kwade wil is.
Als je het artikel goed leest en vooral het bronartikel van ZDnet is een aanrader, dan zul je zien dat er niet veel (niets) van de claims overblijft en er zeker geen grond voor kwade wil is.
Daar kom je niet ver mee bij de Amerikaanse rechter, kijk maar eens naar de straffen die normale burgers opgelegd krijgen voor het 'zonder kwade wil' of 'onbewust' verspreiden van copyrighted content.

Zelfs al is de code geen onderdeel van Android, Google is wel verantwoordelijk voor de repository en zo het er nu uitziet heeft Oracle geen toesteming gegeven om de bewuste bestanden te distribueren. En zelfs al zou dat wel het geval zijn dan nog hebben ze een probleem want iets of iemand heeft de licentie voorwaarden veranderd en dat is gegarandeerd niet gebeurt met toestemming van Oracle.

[Reactie gewijzigd door Carbon op 22 januari 2011 12:51]

Waar ook naar moet worden gekeken is of Sun destijds hier aan mee heeft gewerkt. Als zij destijds toestemming hebben gegeven of hebben meegewerkt dan is het niet onlogisch dat die code in Android is gekomen.
Dat Oracle daarna Sun heeft overgenomen wil niet zeggen dat ze met terugwerkende kracht dit ongedaan kunnen maken of claims kunnen indienen. Sterker nog: hierdoor vervallen zelfs de claims van Oracle daar ze dit konden weten ten tijde van de overname en hebben ze dan eigenlijk toestemming gegeven om dit te gebruiken.
Lijkt me niet dat Sun dat heeft gedaan.
Die waren ook niet al te blij met Android. Vooral vanwege de 'verbastering' van de Java taal/specs.
Had Sun wel toestemming gegeven, dan draaide het Java, ipv Dalvik.
Het lijkt er anders deels op dat dergelijke code is gebruikt voor test doeleinde.

Daarnaast zal veel code exact zo op internet te vinden zijn, wanneer je functionaliteit vraagt. Ook weet ik niet hoe de java documentatie is. Maar als ik iets maak en ik kom op de msdn site van microsoft uit en daar staat wat ik moet hebben gebruik ik dat. Mogelijk zit dergelijke code letterlijk in windows.

Strafbaar, misschien in Amerika, maar ik zie het niet als iets fouts. Ik ben trouwens tegen software patenten. Al zou het wel leuk zijn dat als ik iets maak ik daar voor de rest van m'n leven voor betaald krijg natuurlijk(onterecht betaald overigens).

Verder blijft de belangrijkste vraag wat heeft de overname door Oracle voor invloed gehad, het lijkt namelijk alsof in den beginnen Sun toch heeft meegewerkt.
Ik ben trouwens tegen software patenten.
De essentie van dit verhaal gaat alleen niet over patenten maar over auteursrecht.

En wat jouw voorbeeld van msdn betreft: of dat strafbaar is of niet, hangt volledig af van de licentievoorwaarden die aan msdn hangen. Als die zeggen dat je code voorbeelden niet een op een mag overnemen, dan is het in Nederland net zo goed strafbaar. Het belangrijkste verschil tussen Nederland en de VS zal waarschijnlijk de strafmaat zijn.

[Reactie gewijzigd door anboni op 22 januari 2011 14:28]

Lees jij die licentie voorwaarde? Ken jij die, en moet ik die kennen.

Daarnaast als het dus niet mag via msdn zou je het als uitlokking kunnen zien, dat je hun broncode gebruikt. Immers staat de deur meer dan wagenwijd open.

Je ziet zelf toch ook wel dat het absurd is wat je zegt zelfs als je gelijk hebt voor de wet moet je toch zien dat het een erg vreemde situatie is.
Lees jij die licentie voorwaarde? Ken jij die, en moet ik die kennen.
Ja die lees ik als het van toepassing is op mijn software, en ja die moet ik kennen/lezen zet immer kruisje dat ik akkoord ga met die licentie en dat ik me er aan moet houden en dat het strafbaar is als ik dat niet doe. Je zit schijnbaar is de andere hoek en maakt geen software, leeft daar niet van, en betaald nooit iets en wilt dat andere alles voor jou gratis maken. Zit ik beetje in de goede richting? :D
zet immer kruisje dat ik akkoord ga met die licentie
Het ging nu om MSDN (of andere online documentatie). Als ik Google op "MSDN NaamVanEenOfAndereAPICall" (ik zou niet eens weten of MSDN een ingebouwde zoekmachines heeft) dan kom ik rechtstreeks bij de documentatie, inclusief "Examples" sectie die linkt naar code samples, zonder ooit iets aan te vinken.
Betekent dat dan maar meteen dat de "Terms of use" onderaan de pagina niet geldig zijn? Ik ben geen jurist, maar de GPL heeft een zinnetje erin staan met ongeveer de strekking "je hoeft deze licentie niet te accepteren, maar niks anders geeft je het recht om deze code op welke manier dan ook te gebruiken, dus als je het gebruikt vatten we dat op als het accepteren van deze licentie". Een soortgelijke redenatie zou je natuurlijk ook op MSDN en andere online documentatie (en, in dit geval belangrijker, code samples) los kunnen laten.
En wat jouw voorbeeld van msdn betreft: of dat strafbaar is of niet, hangt volledig af van de licentievoorwaarden die aan msdn hangen. Als die zeggen dat je code voorbeelden niet een op een mag overnemen, dan is het in Nederland net zo goed strafbaar.
Hier zit hem warschijnlijk de crux. Het plaatje onder aan het artikel toont een typisch voorbeeld bestand. Dit is dus niet echt test code maar voorbeelden hoe je iets kunt implementeren. Bij SUN (en dit doen vele fabrikanten) zetten ze gewoon dreugjes exact dezelfde copyright statement boven elke file, zelfs boven de files die ze in hun example application stoppen, terwijl die eigenlijk juist bedoeld is om als voorbeeld te dienen (en dus min of meer bedoeld is om gekopieerd te worden).

Dat gezegd hebbende heb ik niet zoveel medelijden met Google in deze want Dalvik is namelijk Evil, want niet compatible met Java runtimes. Men kan dus Java code compileren naar Dalvik, maar dit draait dan niet op een JVM en andersom. En dat is een trap in het gezicht van Java en vind ik als Java programmeur niet cool. Het credo van Java is: "Write Once, Run Anywhere", en Google breekt dit. Niet cool.

* OddesE heeft een Android telefoon en vindt hem fantastisch.
In de eerste plaats is het onmogelijk om alle code van alle software te kennen. Je weet dus nooit zeker of je auteursrechten schendt!

Daarnaast zijn generieke stukken code als "Hello world" ;) , echt niet meer beschermd door welk auteursrecht dan ook. Wie kan er nou "if instance$ {} then {} else false;" claimen? Juist, niemand.
Ik denk dat het er dan ook om gaat wat de functie of het doel is. En dat mag je beschermen.
Het is natuurlijk altijd fout als je hele libraries of bestande overneemt en het dan claimt als eigen... jammer dat Android zich daar blijkbaar schuldig aan heeft gemaakt...

Ik vraag me af... als dat zo is... is dat dan een afgewogen risico geweest of waren ze gewoon te lui om de functionaliteit van die java bestanden in eigen code te gieten?
Google heeft de code gepubliceerd onder een andere licentie dan is toegestaan zonder toestemming van de eigenaar, dus Oracle staat wel degelijk erg sterk. Ongeacht of de code ook daadwerkelijk door het AndroidOS wordt gebruikt.
Google heeft de code gepubliceerd onder een andere licentie dan is toegestaan zonder toestemming van de eigenaar, dus Oracle staat wel degelijk erg sterk.
Is dat wel zo? Aangezien:
Arstechnica kwam na het bestuderen van de files tot dezelfde conclusie, en meldt dat de betrokken bestanden aan de Android-broncode zijn toegevoegd door het bedrijf Sonivox, een lid van de Open Handset Alliance die formeel de ontwikkelaar is van Android. Hierdoor is het aannemelijk dat Google niet bewust delen van Java-code heeft overgenomen voor gebruik in zijn mobiele besturingssysteem.
Wie is er verantwoordelijk de leverancier of de ontwikkelaar?

Als ik programmeur zou zijn bij een bedrijf en het handig zou vinden om een stuk code te stelen en dit in mijn code te gebruiken. Ik neem aan dat de programmeur dan verantwoordelijk is.

In dit geval lijkt me dat Sonivox verantwoordelijk is. Dit bedrijf heeft waarschijnlijk ook "netjes" de overdracht van rechten gedaan c.q. gezegd dat Google copyright rechten van de code gekregen heeft.
In dit geval lijkt me dat Sonivox verantwoordelijk is. Dit bedrijf heeft waarschijnlijk ook "netjes" de overdracht van rechten gedaan c.q. gezegd dat Google copyright rechten van de code gekregen heeft.
Maakt niet uit wat Sonivox gedaan heeft: rechten die ze niet hebben kunnen ze niet overdragen en wat ze zeggen maakt al helemaal niets uit. Google dient zorgvuldig om te gaan met wat ze publiceren, net zo goed als alle andere bedrijven.

Microsoft had op een gegeven moment ook zoiets bij de hand met een derde partij dat een stuk software aan MS had geleverd dat code van een open source project bevatte en daar werd hier op Tweakers toen absoluut niet zo coulant op gereageerd als op Google nu...beetje selectieve verontwaardiging.
Maakt niet uit wat Sonivox gedaan heeft: rechten die ze niet hebben kunnen ze niet overdragen en wat ze zeggen maakt al helemaal niets uit. Google dient zorgvuldig om te gaan met wat ze publiceren, net zo goed als alle andere bedrijven.
Dat is in veel gevallen onmogelijk zeker als het stukken code zijn, dat is zo goed als niet te controleren of deze copyright schenden.
Ze moeten net als alle andere bedrijven hier adequaat op reageren. Door of de code te verwijderen of iets met de eigenaar van de code regelen.
Microsoft had op een gegeven moment ook zoiets bij de hand met een derde partij dat een stuk software aan MS had geleverd dat code van een open source project bevatte en daar werd hier op Tweakers toen absoluut niet zo coulant op gereageerd als op Google nu...beetje selectieve verontwaardiging.
Dit is het hele verhaal.

nieuws: 'Windows 7 usb/dvd-downloadtool schendt gpl']

Een reactie van mij toen:
worldcitizen in 'nieuws: 'Windows 7 usb/dvd-downloadtool schendt gpl''

In de eerste tweakers post leek het erop dat het een door Microsoft zelf ontwikkelde tool was.

Tevens dit verhaal:
nieuws: Microsoft gaat broncode Windows 7 usb/dvd-downloadtool vrijgeven

In dit verhaal is het duidelijk dat de tool niet door Microsoft zelf ontwikkeld was.
Microsoft heeft uiteindelijk zich aan de GPL gehouden. Google heeft de gewraakte code verwijderd, dus op zich geen probleem.

[Reactie gewijzigd door worldcitizen op 23 januari 2011 18:08]

Het voorbeeldje is toch te belachelijk voor woorden?
Sommige patenten zijn echt belachelijk. Stel dat iemand patent zou vragen op 1+1, hoeveel andere manieren zijn er dan voor om dit 'algoritme' te gebruiken. Moeten we dan voortaan (2-1)+(2-1) schrijven?
Ik zie niet echt wat er belachelijk aan is. De licentie is duidelijk en staat zelfs in de bestanden. Dat Google zich daar niet aan houdt is belachelijk, niet dat mensen gaan klagen als hun eigendommen misbruikt worden. Of zullen we ook maar alle claims van de FSF omtrent GPL code als "Belachelijk" gaan negeren?
Het blijft een raar gegeven dat je iets kunt claimen omdat jij ergens als eerste aan gedacht hebt, of in ieder geval als eerste een claim op die gedachte legt.

Met enige regelmaat wordt een patentschending geclaimd in software die geheel onafhankelijk is ontwikkeld zonder dat de schrijver ooit de broncode of het patent gezien heeft. Voor zover ik weet is er in de definitie van 'patenteerbaar' nog altijd zoiets te vinden als dat het een uitvinding moet zijn die een kundig be-oefenaar van het vak niet zomaar kan bedenken.

Vaak bewijst het feit dat software die patenten zou schenden geschreven wordt zonder het patent te kennen en zonder broncode te jatten al dat er kundige be-oefenaars zijn die dat kennelijk wel degelijk kunnen bedenken. Daarmee vervalt de patenteerbaarheid.
Dit geval heeft niets met patenten te maken (ondanks de naam van de blog) maar net copyright violation. Dat is totaal iets anders (en veel gemakkelijker te verkrijgen of te vervolgen.)
Stel dat iemand patent zou vragen op 1+1, hoeveel andere manieren zijn er dan voor om dit 'algoritme' te gebruiken.
Dat valt niet te patenteren: http://en.m.wikipedia.org/wiki/Patentability

Geen reden tot paniek dus. En een patent heeft steeds pas waarde als het zich in een rechtzaak bewezen heeft. Tenzij je blindelings andermans uitvinding kopieert, heb je niks te vrezen.
En een patent heeft steeds pas waarde als het zich in een rechtzaak bewezen heeft.
In de praktijk wel, maar goedbeschouwd slaat dat natuurlijk ook nergens op; "rechtszekerheid" anyone?
Tenzij je blindelings andermans uitvinding kopieert, heb je niks te vrezen.
Dat is keihard niet waar. Het sleutelbegrip is "independant invention"; iemand vindt iets uit (de telefoon, om maar even een beroemd voorbeeld te pakken) en dient een patent in. Als iemand anders op hetzelfde moment dezelfde uitvinding doet (of zekfs net iets eerder uitgevonden maar net iets later de patentaanvraag ingediend heeft) dan heeft ie nergens recht op. En als een bepaald bedrijf een online winkelwagentje patenteert dan mag niet zomaar iedereen (zelfs als ze nog nooit van dat bedrijf of het patent gehoord hebben) ook een winkelwagentje implementeren, ook al hebben ze het zelf bedacht.
Waar jij misschien mee in de war bent is dat je (volgens Amerikaans recht) "alleen maar" een torenhoge schadevergoeding moet betalen als je "per ongeluk" inbreuk pleegt op een patent. Pas bij "wilful infringement" (er is aangetoond dat je het patent kende en toch pleegde je inbreuk) krijg je die x3 "bonus" eroverheen.

Niet dat dit ook maar iets te maken heeft met het nieuwsbericht (dat gaat over copyright en auteursrechten, niet over patenten), maar jouw claim moet even gecorrigeerd worden.
Wat is er belachelijk aan? Google geeft toch ook zijn algoritme voor haar zoekmachine niet vrij omdat het niet wil dat anderen het kopiëren. Is toch net hetzelfde? Google mag dat blijkbaar maar andere bedrijven mogen blijkbaar niets ondernemen om hun IP te beschermen.

[Reactie gewijzigd door WTF? op 22 januari 2011 10:40]

Het gaat hier om auteursrecht en daarin is alleen het kopiëren verboden. Het zelf nabouwen van de zoekmachine van Google (als je weet hoe die werkt) is geen auteursrechtelijke handeling, maar een patentenkwestie. Het gaat hier dus om auteursrecht.

Stel je voor, je zit weer op de middelbare school en je maakt een proefwerk. In het eerste voorbeeld hebben we het over wiskunde en één van de sommen is "Vereenvoudig de breuk 8/12". Je schrijft braaf en netjes 2/3 op. Je levert je proefwerk in je krijgt een 0 terug. Je vraagt aan de leraar hoe het zit en deze zegt "Nou, Pietje, die dan wel vijf tafels verderop zat heeft PRECIES hetzelfde antwoord! Je had ook 8/12 = 4/6 = 2/3 kunnen schrijven, maar dat deed je niet. Je zult het dus wel van hem hebben overgeschreven en daarom heb je een 0". Waarschijnlijk voel je je, als dit zich voordoet, flink genaaid.
Stel nu dat hetzelfde concept zich voordoet bij een geschiedenis proefwerk. De vraag luidt "Geef een uiteenzetting van de situatie in Europa in aanloop naar de Eerste Wereldoorlog". Je schrijft een blaadje vol, levert het proefwerk in en krijgt een 0. Wat blijkt, Pietje, die vijf tafels verderop zat heeft précies dezelfde tekst opgeschreven. In deze situatie zul je waarschijnlijk Pietje ervan verdenken jouw tekst te hebben overgeschreven en minder moeite hebben met het vermoeden van de leraar.

In praktijk zal in het eerste geval geen sprake zijn van auteursrecht, omdat het zéér waarschijnlijk is dat twee afzonderlijke mensen op de gegeven vraag exact hetzelfde antwoord zullen geven. In het tweede geval is er waarschijnlijk wel sprake van auteursrecht, omdat de kans extreem klein is dat twee mensen dezelfde uiteenzetting schrijven. Maar de vraag is natuurlijk waar de grens ligt - wanneer is het toeval dat twee mensen hetzelfde idee hetzelfde opschrijven en wanneer is dat niet meer zo?
In het geval van het plaatje onderaan dit artikel vind ik het persoonlijk ook aan de dubieuze kant of hier sprake is van auteursrecht - de code ligt dusdanig voor de hand, dat ik het (op basis van dit fragment) wat cru zou vinden om de programmeur een 0 te geven voor overschrijven. Ik beoordeel dat soort zaken toch liever aan de hand van wat ingewikkeldere code.
kan me persoonlijk niet voorstellen dat de code in het plaatje onderaan het artikel niet over geschreven is, het enige verschil zijn de plaatsen van de brackets.

Als deze code gebruikt is voor debuggen zal het wel een vergissing zijn geweest om de code onder een andere licentie uit te brengen.
ooit al java code geschreven?

In het plaatje in de code zie je 5 getters/setters,

als ik die schrijf is dit in netbeans: rechterklik op de 5variabelen, create getters/setters en boem 70% van de code is er. Volgens de licentie van netbeans heb ik hier het copyright op. Netbeans is grootendeels geschreven door sun, dus laat deze code al maar weg, hiervoor hebben we toestemming van sun om ze te gebruiken.

blijft die if else clause over.
5lijntjes, opmaak kan wat opgeschoven zijn zodat alles in het plaatje paste, dus de line endings tellen niet mee.

Nu is het niet echt ondenkbaar dat wanneer je enkele 100.000 lijnen code schrijft er wel enkele lijntjes overeen komen. Zeker zo triviaal als deze, if instance of, cast, else return false. Ik zie persoonlijk niet veel andere mogelijkheden om dit te schrijven in java.

Ik kan me dus zeer, zeer makkelijk voorstellen dat die code niet gecopieerd is,
Ik ben er zelfs zeker van dat iedereen die al eens een iets uitgebreider java project geschreven heeft code heeft die hier 90% mee overeenkomt. En waarschijnlijk dezelfde naamgeving zou gebruiken moest met dezelfde interface implementeren.

Dit is gewoon standaard leerboek code.

[Reactie gewijzigd door Keneo op 23 januari 2011 01:17]

Het gaat om getters/setters...

Daar is al niet veel verandering in mogelijk wil je de functionaliteit behouden..
Daar zeg jij iets, stel jij maakt plastic zakjes die jij 1+1 noemt dan mag bijna iedereen 1+1 gewoon nog gebruiken maar als een andere plastic zakjes fabriek ook opeens 1+1 gaat heten jaaa dat kan niet.

Dus het is echt niet zo zwart wit als dat jij doet voorkomen.
Sommige patenten zijn echt belachelijk.
Klopt, maar het gaat hier over copyright, niet over patenten. Het is lastig te ontkennen dat het bestand rechts een kopie is van het bestand links.

Copyright is goed.

Een patent zou je verbieden de functionaliteit te implementeren zelfs als je hem helemaal zelf zou schrijven, zonder voorbeeld. Zonder te weten dat er al een implementatie was zelfs.

Jammer dat je hier +1 kunt scoren voor comments die kant noch wal raken en de hele discussie het bos in sturen. Ik heb nog liever offtopic posts dan dit soort desinformatie.

[Reactie gewijzigd door OddesE op 22 januari 2011 21:49]

Als jij de eerste zou zijn die bedacht had om zulke cijfers te gebruiken en daar op die manier mee te rekenen: absoluut. Deze uitvinding heeft de wereld geen windeieren gelegd. Dat het nu, heel heel veel jaren later, voor de hand liggend lijkt maakt het niet minder een fantastische uitvinding.

Dus ik zou zeggen bedenk ik iets waar de wereld net zoveel aan heeft en patenteer het alleszins: jij schatrijk en de wereld een stuk beter af. ;)
Weer een storm in een glas water, want de bestanden waar het om gaat zitten a) niet in android zelf maar hebben met de unit testen te maken en b) zijn al een tijd terug verwijderd uit de source tree.

http://www.zdnet.com/blog...ion-found-in-android/2162

Verwijderd (comment: Remove pointless tests):
http://android.git.kernel...a1d6fe52409432ccc576c2fe3

[Reactie gewijzigd door Chilly_Willy op 22 januari 2011 09:05]

Grotendeels irrelevant.

De code was een deel van een groter geheel. De copyright over code geldt niet enkel file per file maar ook project per project.

Maw zelfs als je slecht enkele file van een project mishandelt, dan is het perfect mogelijk dat je hiermee de volledige code base vergiftigd.

De oorspronkelijke code was GPL. De GPL license is heel duidelijk dat het niet volgen van de license er voor zorgt dat je alle rechten verliest. Een nieuwe license header toevoegen bovenaan die file was een blunder van formaat, zelfs als die file uiteindelijk later (veel later!) gewist wordt.

In de praktijk is dit geval vermoedelijk op zich niet genoeg als smoking gun, maar het is uitermate interessant om te gebruiken als je een case wilt maken dat inbreuken geregeld plaatsvonden.
Het schijnt dat SUN ze zelf op de website heeft gezet voor 'test' doeleinden. Aangezien ze daar 'schijnbaar' ook alleen voor gebruikt zouden zijn, zou je denken dat er niet veel aan de hand is.

Ongeacht dat de licensie die 'veranderd' zou zijn in jou ogen, is het niet misbruikt ten gevolge van diezelfde licensie, dus al met al, een storm in een glas water.

edit: typo

[Reactie gewijzigd door TiTbB op 22 januari 2011 10:18]

Ongeacht dat de licensie die 'veranderd' zou zijn in jou ogen,
Dat iemand de licensie heeft veranderd is een feit, blijft de vraag of daar toestemming voor is gegeven.
is het niet misbruikt ten gevolge van diezelfde licensie
Het eigenhandig veranderen van een licentie is misbruik. De inhoud van de originele licentie speelt daarbij geen enkele rol.
Maakt dat uit dan?

De code was bijna 1:1 terug te vinden, zo stom is echt NIEMAND omdat er zo in te laten staan als het daadwerkelijk in het OS terug te vinden is.

Daarnaast zou die code op de website voor SUN te downloaden zijn, voor test doeleinden. Schijnbaar is het ook daarvoor gebruikt, dus wat zou die veranderde licensie dan uitmaken, als je daar al van kan spreken.
1 op 1 code is echt heel makkelijk op te sporen.. zouden ze echt zo dom zijn? haha vast niet...
Het schijnt dat SUN ze zelf op de website heeft gezet voor 'test' doeleinden. Aangezien ze daar 'schijnbaar' ook alleen voor gebruikt zouden zijn, zou je denken dat er niet veel aan de hand is.
Dat ze ze op de website zetten doet het copyright of de licentievoorwaarden die boven elk bestand staan niet teniet. Het is veilig om aan te nemen dat alles dat op internet staat dat door iemand anders gemaakt is onder de copyrightwetgeving valt, tenzij expliciet anders vermeld (bijv. met een opmerking bovenaan dat de code onder een OS of public domain licentie valt)
Maar het is nooit onderdeel van android zelf geweest.
Zeker wel. Het is onderdeel van de Android source tree die mensen kunnen downloaden. Het staat wellicht niet op de telefoon, maar is dus wel onderdeel van Android.
Euhm, nee.

Voor zover bekend, is het nooit gecompiled in het Android OS zelf en alleen gebruikt om te testen.
Euhm, ja dus.

Maakt niet uit of het in het Android OS zit wat op de telefoon draait, zoals ik al schreef.

Het zit in de code repository van het 'Android' project die de mensen kunnen downloaden.
Dus is het Android.
Zie bijvoorbeeld engadget.com.
Een semantische discussie.

De hamvraag is of een rechter ooit heel het Android project zou laten raken door wat er uit ziet als een kleine fout, een zogenaamde 'honest mistake'. Ik vermoed van niet en Google heeft genoeg geld en advocaten om die rechter daar heel lang en diep over na te denken.

Dus zoals het er voorlopig uitziet moet men de betreffende bestanden verwijderen (lijkt al gebeurd) en kan er wellicht een boete volgen voor overtreden van een licentie, maar zal Android zelf niet in gevaar komen.

EDIT:

Voorbeeld bestanden publiceren onder een GPL licentie is overigens echt van de pot gerukt, ook al zie ik dit wel vaker gebeuren.

[Reactie gewijzigd door OddesE op 22 januari 2011 21:55]

Als het dus al niet op de telefoons staat is het nooit commercieel gebruikt geweest en is de straf die ze er voor zullen krijgen dus ook bijlange niet zo hoog. Waarschijnlijk wel duur voor de open handheld alliance, maar als google even bijschiet is er geen enkel probleem.
dat maakt in dit geval niet veel uit. ze hebben code gebruikt zonder toestemming te vragen, dat het (ondertussen) nergens meer in zit doet niets af aan het feit dat je het moet vragen.
nu lijkt het anders te vallen onder "ik steel niet, ik leen het van je zonder dat je het weet".
Dat hearders die verwijzingen na Sun Microsystems kan ik nog als copy past beschouwen, maar andere code om een functie aan te roepen of uit te voeren daar voor zijn toch maar ''zoveel'' manieren om het zelfde doel te bereiken?
Klopt, en hoewel uit diffs blijkt dat de code bijna identiek is, is het interessante hier dat grote delen mogelijks automatisch gegenereerd zijn door Java IDE's (wat gemeengoed is in die tak van sport). Het voorbeeld plaatje laat bijvoorbeeld een paar functies zien die elk object moet hebben, en waarschijnlijk door code generatie automagisch uitgepoept kunnen worden.
Mogelijk, maar dat plaatje is slechts een triviaal voorbeeld, in een rechtszaak zou dat ook weinig waarde hebben.

Mbt het 'er zijn maar zoveel manieren' argument: dat is misschien (ten dele) waar (ten dele: in de meeste talen zijn er nagenoeg oneindig veel manieren om tot hetzelfde resultaat te komen), maar er zijn maar een paar methodes die aan alle voorwaarden voldoen (en dan specifiek mbt performance).

Maar als je iets verder kijkt zie je bijvoorbeeld een toString() functie, en die is (voor zover ik kan beoordelen) niet automatisch gegenereerd door een IDE, en is 100% exact hetzelfde links en rechts, met slechts hier en daar een andere code-formatting style (accolades op nieuwe of zelfde regel, voornamelijk). En dat kan allemaal aan de gebruikte decompiler (en zijn stijl) geweten worden.
De hele markt zit straks zo potdicht dat het nieuwe producten en innovatie in de weg staat... Als het zo doorgaat gaat dit echt zo'n groot probleem vormen. De bedrijven met veel patenten (Google niet) gaan hier echt heel erg van profiteren.
Jongen toch, doe toch niet dramatisch.

Om te beginnen: als je ooit betrokken raakt in een patent oorlog, prijs je dan gelukkig: het bewijst dat je bedrijf gigantisch succesvol is geweest en de bestaande orde bedreigt. Zie ook de paragraaf die start met "What does that mean in practice?" in dit essay van Paul Graham.

Ten tweede: dit verhaal heeft niets met patenten te maken, maar met ordinaire copyright violations. Google heeft code copieerd en vervolgens de header aangepast.

Dat die code uiteindelijk niet in de Android ROMs terecht komt (en veel later gewist is), doet vermoedelijk weinig ter zake.
De bedrijven met veel patenten (Google niet) gaan hier echt heel erg van profiteren.
Ik heb maar vier ledematen en toch heb ik net een glorieuze overwinning geboekt op een spin met acht ledematen.
als ik nu hier op papier een regel java instructies opschrijf durf ik te wedden dat Microsoft/Google/Apple/Oracle/Sun deze ook wel eens heet geschreven :+

pure onzin.
Het verschil zit hem erin dat dit zo erg gekopiert is dat de copyright logo er nog in zit
Stewie, je hebt niets te vrezen. Geen hond die er ooit in geinteresseerd zal zijn om jouw stukjes code te bekijken.
ik heb het over de linux kernel zelf.
Als je die files zo bekijkt die bij het artikel staan dan kun je wel stellen dat iedereen dat kan verzinnen. En misschien nog wel op de letter gelijk. Het kan natuurlijk nooit de bedoeling zijn om copyright te schenden maar als het zo onduidelijk is... Waar hebben we het dan nog over.
In mijn ogen zou een patent een goed idee moeten beschermen en niet dit soort prut. Als we het nu zouden hebben over grote stukken van de jvm ook, maar dit is een nutteloze bijzaak?

Volgens mij is het puur een Oracle actie om alle dingen die ze in de afgelopen jaren hebben gekocht helemaal uit te persen zodat ze er later een groot Oracle label aan kunnen hangen waar we vele duizenden euro's neer voor moeten gaan leggen. Ik ben niet zo te spreken over dit soort acties van Oracle. En ik ben bang dat er nog veel meer komt
Ik vind anders dat het goed laat zien dat Android gewoon snel plak en knipwerk is en het dus echt wel klopt wat Steve Jobs zei dat Google met Android gewoon de iPhone heeft gekopieerd. Een bedrijf met zoveel geld als Google heeft toch genoeg geld voor R&D dat het geen plagiaat moet plegen als het genoeg geld en tijd steekt in het ontwerpen van een OS. Dit laat overduidelijk zien dat ze heel snel een antwoord moesten hebben op de iPhone.

Laten we hopen dat Google de hardwarefabrikanten zoals Samsung, HTC en dergelijke geen miljardenschade berokkend want met al die patentclaims die er rond vliegen kan een veroordeling in deze zaak wel eens olie op het vuur zijn.

En laten we vooral hopen dat de fandroids in de toekomst nog op ondersteuning kunnen rekenen voor hun toch wel dure toestellen anders.

[Reactie gewijzigd door WTF? op 22 januari 2011 10:50]

Sorry maar als je denkt dat android knip- en plakwerk is door dit artikel en dat gelijk stelt aan het verwijt van iphone kopie, dan snap je er werkelijk niets van. Of ben je aan het trollen? Verdraaid, ik trap er nog in ook!
Ik denk dat we hier te maken hebben met een apple fanboy? :)

Het is wel kort door de bocht om te zeggen dat android knip-en plakwerk is. Het was wellicht een bewuste keuze van Android inc (android bestond al voor google zich er is mee gaan moeien in 2005) om de Java API te gebruiken om ontwikkelaars een SDK aan te bieden. Als er al een implementatie is van java, is het eenvoudig om die even te gebruiken om het systeem te testen. Foutje is wel dan om geen eigen implementatie te schrijven nadien.
Wat er precies gebeurd is gaan we wsl ook niet weten.

Verder wil ik nog toevoegen dat zowel android als iPhone in 2007 op de markt zijn verschenen. De iPhone is in een ijltempo ontwikkeld (dacht anderhalf jaar of minder zelfs). Android inc werd in 2005 door apple gekocht, dus google heeft allerminst apple gekopieerd, gezien zij er eerder mee bezig waren. Apple heeft gewoon een sprintje getrokken en was als eerste op de markt met een commercieel product.
Ik ben inderdaad geen fandroid zoals jij blijkt te zijn uit je relaas over de ontwikkeling van de iPhone. De geruchten over een iPhone circuleren al sinds 2002 dus ijltempo zou ik het echt niet noemen. :)

<conspiracy mode on>En wie oh wie trad er in 2006 toe tot de raad van bestuur van Apple? Ene Eric Schmidt. <conspiracy mode off>

[Reactie gewijzigd door WTF? op 22 januari 2011 12:35]

De geruchten over een iPhone circuleren al sinds 2002 dus ijltempo zou ik het echt niet noemen.
Aah, dus geruchten betekenen dat men er ook effectief mee bezig is? Wow, dat is nieuw. Snel wat geruchten verspreiden over een octocore android telefoon, dan is men er ook al mee bezig.

Alle gekheid op een stokje, ik zie niet in wat dit artikel te maken heeft met het feit dat "android" de "iPhone" zou gekopieerd hebben, dus dat stuk uit je reply was alvast erg merkwaardig. Verder slaat het nergens op dat je software (android) met hardware (iPhone) vergelijkt. Had je beter iOS vernoemd.
Volgens mij heb je nog nooit in het echt een android telefoon gezien. Dit is de meeste idiote post die ik ooit op t.net heb gezien (inclusief fipo's)....

reactie op post van WTF?

[Reactie gewijzigd door Drexz op 22 januari 2011 18:58]

Ik vind het feit dat het juist letter voor letter gekopieerd is, niet getuigen dat deze code misbruikt zou zijn.

De devs @ google and whereever, zijn heus wel zo slim om de copyright regels eruit te halen ALS ze al wat 'gestolen' zouden hebben, aangezien het er nog bijna 1:1 vermeld staat.
Als je die files zo bekijkt die bij het artikel staan dan kun je wel stellen dat iedereen dat kan verzinnen. En misschien nog wel op de letter gelijk.
Misschien, maar da's heel onwaarschijnlijk, zeker als je bekijkt dat Android een nieuwe implementatie van de JDK hoort te zijn. Dan zou je al gauw denken dat er meer gebruik gemaakt wordt van tools en dergelijke, ipv dat dingen als een toString() functie nog handmatig uitgetikt wordt. Vooral gebruik van Apache Commons of (omdat het Google is) Google Guava zou je verwachten. Voor een toString() functie is de toStringBuilder bijvoorbeeld behoorlijk handig.
Wat ontzettend slordig van de devs... Ze hadden de code natuurlijk er uit moeten halen alvorens de software uit te brengen. Bovendien kan je sowieso vraagtekens zetten bij de noodzaak van een miljardenbedrijf om nog plagiaat te plegen. Als je een kleine speler bent, soit, maar "with great power comes great responsibility".
Ik vindt het maar triviaal. ben niet bekend met Java maar de code uit de 7 documenten lijken op handler classes of delen uit een API, waarschijnlijk iets wat nodig is om compatible te kunnen zijn. Als ze nou daadwerkelijk grote blokken code of iets diep in de runtime van Sun hadden gekopiierd dan okey maar dit is zo oppervlakkig en de toegevoegde waarde is zo minimaal dat het (IMHO) de discussie niet eens waard is.
Dat doet er (naar verluidt) juridisch niet toe. Het maakt niet uit of het technisch belangrijk of triviaal is, het maakt niet eens uit of het meegecompiled of meegeleverd werd op smartphones. Het enige wat telt is dat die bestanden deel uitmaakten van het Android project, en een inbreuk zijn op de auteursrechten van Sun/Oracle.

Een jurist zegt het volgende op Engadget:
From a legal perspective, there’s no question that these files create increased copyright liability for Google, because the state of our current copyright law doesn’t make exceptions for how source code trees work, or whether or not a script pasted in a different license, or whether these files made it into handsets. The single most relevant legal question is whether or not copying and distributing these files was authorized by Oracle, and the answer clearly appears to be “nope”. […]

Why does this matter? Because we’re hearing that Oracle is dead-set on winning this case and eventually extracting a per-handset royalty on every Android handset shipped.

[Reactie gewijzigd door Arthur op 22 januari 2011 10:10]

Juist, het boeiende hieraan is dat de code voortkomt uit het Apache harmony project. In dit geval is Apache dus ook schuldig aan de verwijten van Oracle. Geen idee hoe dat juridisch uitpakt en of google er wat mee kan, maar het maakt het verhaal wel wat complexer.

Overigens heeft Google ook wel een aardige patent-portfolio en daarmee wapens in handen, er zullen nu vast een aantal google advocaten Oracle's IP aan het nalopen zijn op schendingen daarvan.
En dan als voorbeeld een stukje triviale boilerplate code, dat hetzelfde is voor ieder willekeurig object met één variabele van het type String? Het moet niet gekker worden. Voor de niet-Java programmeurs onder ons: patent aanvragen op bovenstaand voorbeeld is ongeveer gelijk aan patent aanvragen op '1 + 1 = 2',

@SizzLorr: idd, dit soort code wordt in de regel door IDEs gegenereerd. Bovenstaand stukje code is dus exact hetzelfde voor ieder object met één variabele van het type String.

[Reactie gewijzigd door NLxAROSA op 22 januari 2011 09:57]

Het plagieren tot daar aan toe, maar dit is zoals je een werkje van iemand op school overschrijft en zen naam laat staan.
Het voorbeeld in het plaatje echter is zo triviaal dat je een ontwikkelaar die deze standaard methoden op een andere manier zou implementeren, ter plekke zou moeten ontslaan. Het '1 + 1 = 2' voorbeeld van NLxAROSA beschrijft de trivialiteit prima.
Onzin. Er zitten juist in dit triviale stukje al zaken die opvallend zijn.

1. De constructor heeft een parameter genaamd s. Logisch? Nee, een ontwikkelaar zou dit meestal een zinnige naam geven.
2. Die parameter s wordt dan aan een variabele user toegekend. Daarna wordt die variabele met een getter beschikbaar gemaakt. De code generators die ik ken zullen dan een getUser functie genereren en geen getName().

Oftewel, de naamgeving van de twee variabelen is niet "standaard" en de kans dat twee implementaties dit precies hetzelfde doen? Ga morgen eens op kantoor aan je java programmeurs vragen of ze een class willen maken met een private String die een naam bevat. De kans dat je deze code terugkrijgt schat ik 0.
De kans dat je deze code terugkrijgt schat ik 0.
Ach, en wat dan nog? Dus hadden ze een andere parameternaam en getternaam voorzien dan was het wel okee, ook al doet het volledig hetzelfde? Ik heb toch problemen met het voorzien van voorbeelden van deze triviale aard. Het gegeven is gewoonweg te gemakkelijk, het gaat om een stomme POJO met een standaard equals-implementatie en nul komma nul logica.

Had men nu een voorbeeld aangebracht dat wat minder triviaal is en waar effectief bepaalde structuren worden gebruikt waar de kans op twee identieke oplossingen al kleiner wordt, okee, maar dit is gewoonweg belachelijk.

Trouwens, ik dacht dat je variabelenamen verliest met JAD? In welk geval de 'user' wel eens gewoon 'name' had kunnen zijn voor compilatie? Althans, de keren dat ik het gebruikte om bepaalde zaken te weten te komen had ik toch nog een beetje refactoring nodig om het geheel wat leesbaarder te maken.
Dus hadden ze een andere parameternaam en getternaam voorzien dan was het wel okee, ook al doet het volledig hetzelfde?
Nee, als ze de code gekopieerd hadden en alleen wat namen veranderd hadden was het kopieren nog steeds niet okee.

Maar het was iets minder makkelijk aannemelijk te maken dat ze het gekopieerd hadden.
De kwestie is gewoon dat het belachelijk is om een stelling rond kopiëren te illustreren met een POJO, net omwille van de aard van de klasse en de hoeveelheid boilerplate code. Volgens mij kan iedereen met een beetje kennis ter zake het daar wel mee eens zijn.

edit: ik zou trouwens absoluut niet in wat er erg is aan het kopiëren van een POJO met 1 attribuut, als ze dat al gedaan zouden hebben.

[Reactie gewijzigd door MatthiasDS op 22 januari 2011 15:45]

Op dit item kan niet meer gereageerd worden.



Populair: Desktops Vliegtuig Luchtvaart Crash Smartphones Laptops Apple Games Besturingssystemen Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013