Ontwikkelaar Linux-kernel klaagt VMware aan om overtreden gpl

Christoph Hellwig, een van de ontwikkelaars die werkt aan de Linux-kernel, klaagt VMware aan vanwege inbreuk op de gpl-licentievoorwaarden. Volgens Hellwig heeft VMware de regels overtreden door de broncode van zijn software niet openbaar te maken.

De gplv2 vereist dat van programma's die zijn gebaseerd op opensource-software ook de broncode openbaar wordt gemaakt, maar volgens Linux-kerneldeveloper Christoph Hellwig houdt VMware zich daar niet aan. Samen met de Software Freedom Conservancy heeft hij daarom besloten om VMware in Duitsland aan te klagen.

Doordat VMware zich niet aan de gplv2-licentievoorwaarden houdt, pleegt het bedrijf inbreuk op de auteursrechten van Hellwig, die de rechten op een deel van de Linux-kernel bezit. Dat claimt de SFC. De klacht heeft betrekking op de ESXi-virtualisatiesoftware van VMware. Zowel VMwares implementatie van BusyBox als de kernel van de ESXi-software zouden opensource-broncode bevatten, zonder dat VMware de broncode daarvan openbaar maakte.

Volgens de SFC pleegt VMware sinds 2007 inbreuk op de gpl. De afgelopen jaren zou VMware, na klachten vanuit de SFC, zijn gedrag wel enigszins hebben verbeterd, maar nog steeds niet genoeg om te voldoen aan de licentievoorwaarden van de gplv2-licentie.

Reacties (101)

[Venator]

Kan nog interessant worden, omdat er überhaupt maar heel weinig precedent over GPLv2 inbreuk bestaat en de meest belangrijke bepalingen in GPLv2 geen interpretatie kennen vanuit de meeste gerechtshoven. Zijn ook niet zo veel zaken over, maar deze is mogelijk wel interessant in dit daglicht: Versata vs Ameriprise

[Blokker_1999]

De reden dat deze zaak in Duitsland word aangespannen is omdat in het verleden er in Duitsland al wel zaken rondom de GPL geweest zijn en dat deze in het voordeel van de FOSS community zijn uitgedraaid. Net zoals vele patentschendingen in Texas terechtkomen.

[Maurits van Baerle]

Het zal ook mee hebben gespeeld dat Christoph Hellwig zelf een Duitser is. Hij heeft copyright op zijn eigen code en beschuldigt VMware van het inbreuk maken op zijn copyright. Dan is het niet vreemd dat je naar de rechter in je eigen land stapt.

Je moet niet vergeten dat de GPL erg zwaar leunt op copyright. Zonder copyright was de GPL niets waard geweest aangezien copyright gebruikt wordt als stok achter de deur. In principe is het kopiëren van code onder copyright niet toegestaan zonder toestemming van de auteur. Middels de GPL geef je als auteur eigenlijk aan dat er onder bepaalde voorwaarden (beschreven in de GPL) het toch is toegestaan dat je gebruikt maakt van die code. Maar, dat betekent dus wel dat je je aan die voorwaarden in de GPL moet houden. Doe je dat niet dan vervalt het tot een regelrechte copyright kwestie.

[Verwijderd]

Zonder copyright was de GPL niets waard geweest aangezien copyright gebruikt wordt als stok achter de deur.

Ter correctie. Zonder Copyright was GPL niet nodig geweest.
Dat is iets dat Richard Stallman iedere keer aangeeft in zijn lezingen.

Hij is namelijk tegen copyright.

Copyleft.

The concept of copyleft was described in Richard Stallman's GNU Manifesto in 1985 where he wrote:

GNU is not in the public domain. Everyone will be permitted to modify and redistribute GNU, but no distributor will be allowed to restrict its further redistribution. That is to say, proprietary modifications will not be allowed. I want to make sure that all versions of GNU remain free.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:40]

[OddesE]

Ter correctie. Zonder Copyright was GPL niet nodig geweest.

Ter correctie, Maurits heeft volkomen gelijk. Eén van de weinige mensen die de GPL echt gelezen heeft blijkbaar.

De GPL is een shrink-wrap license... Dit betekent zoveel als dat je je al aan de licentie commiteert op het moment dat je het programma 'uit de verpakking haalt'. Er is geen handtekening nodig.

Een overeenkomst zonder handtekening?? Hoe kan dat?

Dat kan doordat copyright jou het kopieren van het werk expliciet verbiedt (en daarmee het downloaden, installeren, verspreiden e.d.). Ga je het toch kopieren, dan zijn er dus maar twee mogelijkheden:

1) Je overtreedt de copyrightwetgeving
2) Je hebt toestemming gekregen van de auteur, waardoor je niet in overtreding bent.

De GPL is een vorm van toestemming van de auteur. Hij noemt gewoon de voorwaarden waaronder je mag kopieren. Daar MOET je aan voldoen want het is de enige juridische basis die jou toestaat dat kopieren uit te voeren. Voldoe je niet aan de GPL, dan ben je in overtreding van de copyright wetgeving.

Zonder copyright geen GPL. I.i.g. niet in zijn huidige (shrink-wrap) vorm.
Copyright bestond al jaren voordat de GPL bestond en kan dus makkelijk zonder de GPL.

Of de GPL nodig is lijkt me een nogal subjectief oordeel. Stallman vindt van wel. Velen die zijn licentie gebruiken zijn het blijkbaar met hem eens (of vinden die licentie op zijn minst handig). Het feit dat er nog legio andere licentievormen bestaan die min of meer hetzelfde bereiken bewijst eigenlijk wel dat er van 'nodig' (als in onmisbaar) geen sprake is.

Dat is iets dat Richard Stallman iedere keer aangeeft in zijn lezingen.

Sorry maar het maakt helemaal niks uit wat Stallman zegt in zijn lezingen. De GPL is een juridisch document dat losstaat van Stallman. Zijn lezingen en de andere dingen die hij zegt of schrijft hebben nul invloed op de GPL of de juridische implicaties daarvan. Hoogstens kan hij invloed uitoefenen op een toekomstige nieuwe versie van de GPL. GPLv2 is zoals het is en niets wat Stallman wel of niet zegt of schrijft verandert daar nog wat aan.

Hij is namelijk tegen copyright.

En tegen wachtwoorden. Klinkt echt als iemand met veel realiteitszin.

Wat ook al meteen aangeeft waarom je deze man beter niet zomaar kunt geloven. Hij is uiterst politiek gemotiveerd. Hij is een 'man on a mission'. Hij heeft een doel en dat is jou ervan te overtuigen dat je je informatie niet hoeft te beschermen, maar dat je alles moet delen met iedereen. Op zich prima, alleen wordt het een beetje lullig als hij vervolgens incorrecte (of toch op zijn minst incomplete) informatie over de GPL license gaat verspreiden... Zowel gebruikers van GPL'ed software als de ontwikkelaars die kiezen voor de GPL license hebben behoefte aan duidelijke informatie over hoe de license werkt en niet aan politiek gemotiveerde one-liners die feitelijk gewoon niet kloppen.

Free software is free as in free beer!

[Maurits van Baerle]

Zonder copyright had je gewoon de BSD licentie gehad. Iedereen kan alles gebruiken zonder dat je daar voorwaarden aan kunt stellen. Geen bronvermelding, geen teruggave van verbeteringen, geen inzicht in code etc.

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 23:40]

[Verwijderd]

Zonder copyright had je gewoon de BSD licentie gehad. Iedereen kan alles gebruiken zonder dat je daar voorwaarden aan kunt stellen. Geen bronvermelding, geen teruggave van verbeteringen, geen inzicht in code etc.

Zonder Copyright had je geen Licentie gehad. In dat geval zou de code waarschijnlijk veel vrijer gedeeld worden.
Nu zijn het vooral bedrijven die onder het moto van kennis is macht zo veel mogelijk onder hun eigen pet proberen te houden. Buiten de copyright zijn de patenten de andere optie.

[Maurits van Baerle]

Nou ja, ik zei het inderdaad verkeerd. Zonder copyright had je dezelfde situatie gehad als de BSD-licentie. Iedereen mag alles met jouw code. De BSD licentie zelf was inderdaad overbodig geweest.

Zonder copyright had je theoretisch wel een GPL licentie kunnen hebben maar die zou iedereen gewoon kunnen negeren omdat een GPL licentie niet bindend is zonder copyright als stok achter de deur.

[trogdor]

Zonder copyright of gpl, bsd of whatever was het maar helemaal de vraag of men code zou openbaren.

[Verwijderd]

Zonder copyright of gpl, bsd of whatever was het maar helemaal de vraag of men code zou openbaren.

In het pre GNU tijdperk was dat het geval.

Events leading to GNU

In the late 1970s and early 1980s, the hacker culture that Stallman thrived on began to fragment. To prevent software from being used on their competitors' computers, most manufacturers stopped distributing source code and began using copyright and restrictive software licenses to limit or prohibit copying and redistribution. Such proprietary software had existed before, and it became apparent that it would become the norm. This shift in the legal characteristics of software can be regarded as a consequence triggered by the U.S. Copyright Act of 1976, as stated by Stallman's MIT fellow Brewster Kahle.[18]

Of dat in deze egoïstische tijd geld en macht boven werknemers en gezondheid (medicijnen), en waar bedrijven puur handelsgoed verworden zijn, is de vraag.

[trogdor]

Kijk, er zijn 2 manieren om dingen te beschermen: door patenten/copyright, of door geheimhouding.
Was er geen copyright geweest dan was geheimhouding belangrijker geworden, bijvoorbeeld voor interfaces etc.

[Verwijderd]

Kijk, er zijn 2 manieren om dingen te beschermen: door patenten/copyright, of door geheimhouding.
Was er geen copyright geweest dan was geheimhouding belangrijker geworden, bijvoorbeeld voor interfaces etc.

In de huidige wereld wel. Dit is de kennis is macht wereld, je kunt ook op kwaliteit concurreren. Maar dat willen/kunnen veel bedrijven niet, want dat kost meer geld, waardoor de aandeelhouders niet meer blij zijn.

[trogdor]

Als dat helemaal niet zou gebeuren zouden er geen kwaliteitsmerken bestaan.

[Verwijderd]

Als dat helemaal niet zou gebeuren zouden er geen kwaliteitsmerken bestaan.

Het gaat hier over soft en niet hardware.
Volgens mij is binnen de software helemaal niet zo duidelijk wat kwaliteitsmerken zijn.
Tevens kopen binnen software IMO meer op prijs dan kwaliteit .
Veel bedrijven zijn bijna standaard een een vendor gebonden.

[OddesE]

Vraag: Heb jij een eigen bedrijf? En is dat een software bedrijf?
Je mag natuurlijk elke mening hebben die je wilt hoor. Maar de juridische consequenties van GPLv2 zij een objectief feit. I.i.g. voor zover we een rechter als objectief mogen beschouwen...

Je kunt er dus alle Wikipedia pagina's en lezingen van de wereld bijhalen, maar waarom? Om te weten wat de juridische consequenties zijn hoef je maar twee dingen te weten:

1) Hoe Copyright werkt (omdat dat het hele fundament van de GPL is zoals Maurits al correct opmerkte)
2) De tekst van de licentie zelf.

Ik zou zeggen lees die licentie eens.

[Verwijderd]

Vraag: Heb jij een eigen bedrijf? En is dat een software bedrijf?
Je mag natuurlijk elke mening hebben die je wilt hoor. Maar de juridische consequenties van GPLv2 zij een objectief feit. I.i.g. voor zover we een rechter als objectief mogen beschouwen...

Je kunt er dus alle Wikipedia pagina's en lezingen van de wereld bijhalen, maar waarom? Om te weten wat de juridische consequenties zijn hoef je maar twee dingen te weten:

1) Hoe Copyright werkt (omdat dat het hele fundament van de GPL is zoals Maurits al correct opmerkte)
2) De tekst van de licentie zelf.

Ik zou zeggen lees die licentie eens.

Ik zou zeggen lees mijn reactie eens.
Jouw opmerking heeft helemaal niet met mij n reactie te maken.
Mijn reactie gaat over de historie van GPL en of het al dan niet nodig zou zijn als de software niet gecommercialiseerd zou zijn.

[Hoopje]

Zonder copyright was de GPL niet mogelijk geweest. Maar hij was wel nodig geweest. Zonder copyright zouden bedrijven namelijk source code kunnen aanpassen en die aanpassingen niet openbaar maken, maar alleen de binaries publiceren. Het gaat Stallman om kennis, niet om geld, en gratis binaries helpen hem daarbij niet.

[Verwijderd]

Zonder copyright was de GPL niet mogelijk geweest. Maar hij was wel nodig geweest. Zonder copyright zouden bedrijven namelijk source code kunnen aanpassen en die aanpassingen niet openbaar maken, maar alleen de binaries publiceren. Het gaat Stallman om kennis, niet om geld, en gratis binaries helpen hem daarbij niet.

Nee het zou ook nodig geweest zijn.
Als de wereld niet veranderd was naar meer gesloten software zouden er geen GPL of andere OSS Licenties gestaan.

Zie het Wikipedia artikel over Richard Stallman.

In the late 1970s and early 1980s, the hacker culture that Stallman thrived on began to fragment. To prevent software from being used on their competitors' computers, most manufacturers stopped distributing source code and began using copyright and restrictive software licenses to limit or prohibit copying and redistribution. Such proprietary software had existed before, and it became apparent that it would become the norm. This shift in the legal characteristics of software can be regarded as a consequence triggered by the U.S. Copyright Act of 1976, as stated by Stallman's MIT fellow Brewster Kahle.[18]

When Brian Reid in 1979 placed time bombs in the Scribe markup language and word processing system to restrict unlicensed access to the software, Stallman proclaimed it "a crime against humanity."[11] During an interview in 2008, he clarified that it is blocking the user's freedom that he believes is a crime, not the issue of charging for the software.[19] Stallman's texinfo is a GPL replacement, loosely based on Scribe [1]; the original version was finished in 1986.[20]

In 1980, Stallman and some other hackers at the AI Lab were refused access to the source code for the software of a newly installed laser printer, the Xerox 9700. Stallman had modified the software for the Lab's previous laser printer (the XGP, Xerographic Printer), so it electronically messaged a user when the person's job was printed, and would message all logged-in users waiting for print jobs if the printer was jammed. Not being able to add these features to the new printer was a major inconvenience, as the printer was on a different floor from most of the users. This experience convinced Stallman of people's need to be able to freely modify the software they use.[21]

Zonder dit zou Richard Stallman niet aan GNU begonnen zijn c.q. als de situatie van 1970 zou zijn blijven bestaan.

[pe1dnn]

Ben wel benieuwd hoe sterk Christoph Hellwig in z'n schoenen staat.

Het gaat over de code die hij geschreven heeft en waar hij dus als de auteur de copyright houder voor is. En hij bepaald dus hoe het verspreid mag worden.

Allereerst is dat dus met een GPL V2 licentie. Degene die het onder die licentie verkrijgen hebben natuurlijk de in GLP V2 genoemde rechten en plichten.

Maar als copyright houder mag hij het natuurlijk ook nog gerust onder een andere licentie uitbrengen (en als copyright houder is hij de enige die dat mag). Als het beroerd uitpakt voor VMware zouden ze hem natuurlijk een grote zak geld kunnen geven om de code onder een andere licentie te mogen gebruiken.

Of dat haalbaar is weet ik niet. Als er natuurlijk andere auteurs ook aanpassingen hebben gedoneerd aan die code dan wordt het natuurlijk snel moeilijk want dan is het niet meer 100% zijn code en kan hij alleen een andere licentie geven op het deel wat wel van hem is.

Maar aan de andere kant gaat de klacht over de code van hem en dat zouden ze zo op kunnen lossen, als Christoph Hellwig daaraan meewerkt. Eventuele andere auteurs zouden dan zelf individueel ook hetzelfde moeten doen (als die code nog bestaat want kan ook al overscheven zijn door VMware specifieke code).

Hoe dan ook, ziet er niet goed uit voor VMware of het ziet er heel goed uit voor Christoph Hellwig...

@br men Is eigenlijk ook geen verrassing dat dat al gebeurt is. Bedankt voor de update, ben benieuwd hoe dit gaat aflopen.

[Reactie gewijzigd door pe1dnn op 23 juli 2024 23:40]

[acemoo]

"VMware's last offer was a proposal for a settlement agreement that VMware would only provide if Christoph signed an NDA, and Christoph chose (quite reasonably) not to sign an NDA merely to look at the settlement offer."

https://sfconservancy.org...e/vmware-lawsuit-faq.html

Ik denk dat VMware hem al een flinke zak geld aangeboden heeft.

[Venator]

Daarnaast is Duitsland een sterke bondgenoot en partner voor veel landen, waardoor een precedent binnen Europa en daarbuiten eerder gebruikt wordt door andere gerechtshoven. Met wat jij aangeeft inderdaad wel een hele logische keuze om een zo zwaar mogelijk precedent te verkrijgen, de kans op opvolging in andere landen wordt daarmee veel groter en de druk op EMC/VmWare daarmee ook.

[Atlantis1995]

Kan nog interessant worden, omdat er überhaupt maar heel weinig precedent over GPLv2 inbreuk bestaat en de meest belangrijke bepalingen in GPLv2 geen interpretatie kennen vanuit de meeste gerechtshoven.

Hoe zit dat met de rechtszaak uit 2004 van Sitecom over de GPL licentie. Welke GPL versie was dat? Die hebben gepoogd te schikken zonder succes. Die hebben de rechtszaak verloren en hebben de code openbaar moeten maken.

http://webwereld.nl/open-...ijd-wint-van-de-commercie

[Deem]

Ben benieuwd hoe dit gaat aflopen en of de broncode van o.a. ESXi openbaar gemaakt gaat worden. ESXi wordt enorm veel gebruikt in het bedrijfsleven en is echt een mooi en knap stukje software.

[mashell]

en of de broncode van o.a. ESXi openbaar gemaakt

Dta sowieso niet. Immers volgens de GPLv2 moeten alleen de aanpassingen openbaar gemaakt worden. Als VMware beweert helemaal geen aanpassingen aan de broncode gedaan te hebben en er alleen aan toegevoegd heeft kan dit nog een interessantie zaak worden.

[davasch]

Het toevoegen van code is toch ook een aanpassing? In de GPLv2 staat:

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
[...]

https://www.gnu.org/licenses/gpl-2.0.html

[mashell]

Als je dat toevoegen doet in de vorm van applicaties en modules die de API van het open source gedeelte gebruiken en het open source gedeelte ongewijzigd laat hoef je daarvan niets vrij te geven.

[dajero]

Zo eenvoudig is dat niet. Wanneer je jouw code linkt aan software die is vrijgegeven onder de GPL2, dan ben je verplicht om jouw software ook onder de GPL2 (of een latere versie) vrij te geven.

Zie: http://www.gnu.org/licens...0-faq.html#LinkingWithGPL
en: http://nl.wikipedia.org/wiki/Linken

[Reactie gewijzigd door dajero op 23 juli 2024 23:40]

[mashell]

Dat is de mening van GNU. De gangbare juridische interpretatie is anders. Zie deze post van "the_shadow" met bron hierboven.

[Verwijderd]

Die the_shadow heeft het over services. Zulke services draaien in een eigen process en hoeven dus niet te linken met GPL2 software.

Het is geen mening dat het linken met GPL2 software vereist dat de software die linked ook GPL2 software moet worden. Dat is de licentie.

Als je dat niet wil is er de LGPL licentie. Software die niet released wordt met als licentie LGPL , maar wel GPL2, mag niet mee gelinkt worden tenzij de software die er mee linked ook GPL2 wordt.

De Linux kernel is GPL2.

Dus (voor de Linux kernel zijn er wel bepaalde uitzonderingen wat betreft drivers)

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:40]

[davasch]

Dat is waar, dan heb je gewoon iets niets gecreeerd lijkt me. Dat lijkt hier niet geval, als er inderdaad GPL'ed code in de ESXi-kernel zit (en dus niet als aparte applicatie of module).

[K4F]

De beschuldigingen zullen hier dan ook niet ongegrond zijn. Hoewel de kernels standaard niet deterministic gecompileerd worden zal er een vrij betrouwbare aanname gemaakt kunnen worden door binaries te vergelijken.

[sspiff]

Dat is niet wat er in de GPL staat. De GPL spreekt over "afgeleid werk" ("derivative works" in de tekst). Wat dat inhoud, is aan advocaten en rechters om te bepalen.

De FSF is altijd duidelijk geweest dat voor hen alles wat gebruik maakt van niet standaard of niet publieke interfaces (zoals bvb het verbinden van functies met een linker, of een eigen netwerk protocol, of ...) vallen onder afgeleide werken.

[gammuts]

Het artikel rept slechts over "BusyBox" en de "kernel van de ESXi-software". Ik zie niet in waarom je over heel ESXi praat.

[trogdor]

Wat is ESXi zonder kernel ?

[i-chat]

esxi hoeft helemaal niet openbaar te worden, enkel de kernel maar, dat betekend hooguit dat het makkelijker wordt om esxi makkelijker op exotische hardware te laten draaien door drivers aan de bestaande kernel toe te voegen of dingen te patchen, verder veranderd er niets omdat er ook hele stukken software in esxi zitten die niet onder gpl vallen

skype draait ook onder linux maar is daarom nog niet gpl of opensource...

[Verwijderd]

Yep. Als dit betekent dat ESXi niet meer gratis is, dan gaat Hyper-V nog meer markt pakken.
Dat kon dan wel eens een 2de dip in het VMware beursaandeel betekenen.

Als VCPer moet ik zeggen dat mijn voorkeur inmiddels bij Hyper-V oplossingen ligt.
De overhead van vCenter met v5 icm met internet browser moeten gebruiken, doet mij als bloated software aan. Wat voelt Hyper-V management dan heerlijk snel aan. En wel standaard met vele handige features zoals live virtual machine en storage migration.

[Jurrian120]

Het mooie dan word dat er eventuele leveranciers die code gaan gebruiken om zo misschien een goedkopere ESXi te maken. Meer concurrentie is beter prijzen voor d consument.

[K4F]

Dit betekent niet dat de gehele broncode vrijgegeven moet worden. Het gaat hier om een busybox implementatie en een aangepaste kernel.
Gezien de gesloten tools van Vmware hier omheen lijkt het me vrij nutteloze code om te gebruiken voor een rip-off. Bovendien bestaan er projecten die volledig open-source zijn en meer dan een alternatief vormen.

[Verwijderd]

Nog goedkoper dan gratis?

[Jurrian120]

vSphere is niet gratis.

[robbl]

vSphere niet. ESXi is wel gratis te gebruiken.

[Jurrian120]

Ik kan het ook fout hebben, maar de eerste 30 kan je alles gratis doen maar daarna kan je op de ESXi dat niet meer totdat je het gekocht hebt.

[badnews.nl]

esxi kan je gewoon blijven gebruiken. Geheugen limiet van paar GB is met 5.5 verwijderd, dus je kan gewoon een 192gb server, met 2x16 cores op esxi 5.5+ gratis draaien, wel zonder support, dus minder interessant voor bedrijven.

[latka]

Na te maken te hebben gehad met VMWare support: daar mis je niks aan. Gratis versie en zelf denken is goedkoper.

[mkools24]

Ja maar je betaald voor vsphere en dus functies als clustering, vmotion, drs. Dat zijn dingen die je juist wilt en dat is vrij duur, 2500 euro per processor socket geloof ik voor de enterprise versie.

Wil je volledig open source gebruik dan xenserver daar betaal je alleen voor support.

[gertm]

Iemand die een server heeft met 2x16 cores en 192GB wilt vermoedelijk ook dat zijn virtual machines bij een probleem - of bij gepland onderhoud - gemakkelijk naar een andere server verplaatst kunnen worden. Probeer dat eens met de gratis ESXi. Als ik me niet vergis kun je zelfs bv de perl SDK niet gebruiken, en is het creëren van nieuwe virtual machines na 30 dagen al een probleem.

[doc]

Na 30 dagen (zijn er 60 dacht ik), moet je wel de hypervisor licentie hebben ingevuld, maar deze krijg je gratis.

Meer info: http://www.vmware.com/products/vsphere-hypervisor

[Verwijderd]

Iedereen lijkt ervan uit te gaan dat de kernel van ESXi gebouwd is OP Linux, en dat is helemaal niet het geval; ESXi is zijn eigen "ding". Vroeger was dat duidelijker, toen hadden we met ESX (dus niet ESXi) een aparte "privileged" VM die we de Service Console noemden. Die draaide Linux. De core zelf niet. Nu is alleen ESXi over gebleven, de "embedded versie". Nog steeds de core (de vmkernel) en een busybox ertegenaan "geschroefd". Dan komt natuurlijk de discussie hoe dicht beiden nu verweven zijn; wanneer word iets een uitbreiding op en niet een samenleven van?

Kijk maar eens naar een meer generieke SDDC aanpak (en dit is niets meer dan SDC); hier zie je eigenlijk altijd dat het control plane (hier busybox) word losgekoppeld van het dataplane (hier de vmkernel). De een praat met de ander, maar er is geen sprake van "bijgebouwd" of "opgebouwd", maar meer "naastgebouwd".

Ben benieuwd hoe de gemiddelde rechter dit technisch verhaal gaat vertalen en vooral beoordelen (daar hebben we al vaker leuke staaltjes van gezien).

[Verwijderd]

In dit geval is er echter wel degelijk "opgebouwd". Lwn.net heeft er een wat uitgebreider artikel over: http://lwn.net/Articles/635290/

Relevante gedeeltes:

It would seem that vmkernel loads and uses quite a bit of Linux kernel code, sometimes in heavily modified form. The primary purpose for this use appears to gain access to device drivers written by Linux, but supporting those drivers requires bringing in a fair amount of core code as well.

The picture that emerges suggests that vmkernel is not just another binary-only kernel module making use of the exported interface. Instead, VMware's developers appear to have taken a substantial amount of kernel code, adapted it heavily, and built it directly into vmkernel itself. It seems plausible that, in a situation like this, the case that vmkernel is a derived product of the Linux kernel would be relatively easy to make.

[CAPSLOCK2000]

Iedereen lijkt ervan uit te gaan dat de kernel van ESXi gebouwd is OP Linux, en dat is helemaal niet het geval; ESXi is zijn eigen "ding".

Hellwig beweert niet dat de hele kernel gebruikt wordt maar wel dat er flinke stukken code zijn overgenomen, met name veel drivers.
Een simpele aanwijzing zit in de namen van de drivers. Die komen heel vaak precies overeen met de namen van de overeenkomstige linux-drivers. Dat is geen hard bewijs en enige overeenkomst is niet meer dan logisch, maar het valt wel op.

Ze illustreren het met het volgende plaatje:
http://sfconservancy.org/.../linux-vs-vmkernel_en.png

Overigens ontkent VMWare niet dat ze heel wat GPL-software hebben gebruikt maar ze stellen dat het geen schending van het GPL is.

[Verwijderd]

Iedereen lijkt ervan uit te gaan dat de kernel van ESXi gebouwd is OP Linux, en dat is helemaal niet het geval; ESXi is zijn eigen "ding". Vroeger was dat duidelijker, toen hadden we met ESX (dus niet ESXi) een aparte "privileged" VM die we de Service Console noemden. Die draaide Linux. De core zelf niet. Nu is alleen ESXi over gebleven, de "embedded versie". Nog steeds de core (de vmkernel) en een busybox ertegenaan "geschroefd". Dan komt natuurlijk de discussie hoe dicht beiden nu verweven zijn; wanneer word iets een uitbreiding op en niet een samenleven van?

Kijk maar eens naar een meer generieke SDDC aanpak (en dit is niets meer dan SDC); hier zie je eigenlijk altijd dat het control plane (hier busybox) word losgekoppeld van het dataplane (hier de vmkernel). De een praat met de ander, maar er is geen sprake van "bijgebouwd" of "opgebouwd", maar meer "naastgebouwd".

Ben benieuwd hoe de gemiddelde rechter dit technisch verhaal gaat vertalen en vooral beoordelen (daar hebben we al vaker leuke staaltjes van gezien).

Volgens mij zijn VMware en Linux veel meer verworven dan gedacht wordt. Zoals in de post gezegd wordt dit probleem speelt als sinds 2007. Als VMware die probleem niet zou willen hebben hadden ze ook op *BSD of Windows kunnen overstappen.

Als ik de post goed lees heeft VMware aanpassingen aan de Linux kernel en Busybox gemaakt, deze aanpassingen moeten hoe dan ook teruggegeven worden als het een product is dat en derden geleverd wordt. Dit heeft er niets te maken met in hoeverre Linux en ESXi met elkaar verweven zijn, dat staat hier helemaal buiten.
Als het een intern product zou zijn geweest zou dit probleem niet gespeeld hebben.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:40]

[Verwijderd]

Hoe zit dit zelfde eigenlijk met play-services en android?
Die zijn ook niet openbaar, de code van play-services wordt ook niet gepubliceerd, toch wordt het icm android gebruikt en is android wel open source. Dat mag wel volgens de licentie?

[the_shadow]

Play services zijn precies dat: services die op Android draaien. Zodra er geen GPL code in de betreffende services gebruikt wordt hoeft de bron ook niet openbaar gemaakt worden. Zou wat zijn, dan moesten alle Android apps openbaar gemaakt moeten worden.

Zie ook deze blog post: Maakt linken van een GPL bibliotheek je software automatisch GPL?

Auteursrecht op software bestaat volgens de hoogste Europese rechter alleen op de broncode en de daarvan afgeleide uitvoerbare code. Men noemt dit de ‘uitdrukkingswijzen’ en daaronder wordt alleen datgeen verstaan dat tot “reproductie van het computerprogramma of tot het computerprogramma zelf kunnen leiden”. Je moet dus, kort gezegd, met wat er overgenomen of gebruikt is in het andere werk, het originele programma zelf althans gedeeltelijk kunnen terugvinden.

[Reactie gewijzigd door the_shadow op 23 juli 2024 23:40]

[Stoney3K]

Play services zijn precies dat: services die op Android draaien. Zodra er geen GPL code in de betreffende services gebruikt wordt hoeft de bron ook niet openbaar gemaakt worden. Zou wat zijn, dan moesten alle Android apps openbaar gemaakt moeten worden.

Zie ook deze blog post: Maakt linken van een GPL bibliotheek je software automatisch GPL?
[...]

Het vervelende is dat je niet kan aantonen dat er open-source broncode is gebruikt als je geen inzage hebt in die (gesloten) broncode. Dus ik ben benieuwd hoe ze dit in de rechtszaal aan denken te tonen, je kan niet bij VMWare binnen komen vallen met een huiszoekingsbevel en even een uitdraai van ESXi gaan eisen.

[the_shadow]

Wat ik uit het nieuwsbericht lees is dat er een versie van BusyBox door VMware werd geleverd die andere functionaliteit bood dan de originele versie. Van de nieuwe versie werd echter niet de broncode vrijgegeven, wat GPL technisch wel had gemoeten. Verder heeft VMware een kernel uitgebracht onder de naam vmkernel waar de code niet van vrijgegeven is.

Ik denk dat deze rechtzaak zal gaan draaien om definities. Wat mag GPL technisch wel gebruikt worden in gesloten software, en wat niet.

[Blokker_1999]

Over die definities valt niet veel te debateren. Dat staat allemaal netjes omschreven inde GPLv2. Van zodra je delen code opneemt die zijn vrijgegeven onder GPLv2 in een groter geheel dient heel dat groter geheel onder GPLv2 vrijgegeven te worden. Wanneer je een programma dat is uitegeven onder GPLv2 aanpast moet je heel de broncode, inclusief aanpassingen opnieuw ter beschikking stellen.

Kleine opmerking hierbij: het ter beschikking stellen van de code dient enkel te gebeuren aan de gebruikers van uw programma. Er is geen enkele verplichting om dit te verstrekken aan andere personen.

[the_shadow]

En wat als ik niet code opneem, maar gebruik maak van libaries, of gebruik maak van uitvoer van een GPL programma, wat dan? Ik maak geen kopie of aanpassing in de originele code, maar hetgeen waar de GPL licentie op berust is toch integraal onderdeel van mijn programma (als in: zonder werkt het niet).

Zoals blijkt uit de blogpost die ik linkte, levert het linken naar en gebruik van libaries (in ieder geval onder de Nederlandse auteurswet) in non-GPL software geen probleem op, terwijl dit toch echt gebruik maken van onder GPL geimplementeerde functies is.

[Verwijderd]

Als je het samen compileert en dus als 1 bron kan zien moet het ook opengegooid worden.

Can I link a GPL program with a proprietary system library?

Both versions of the GPL have an exception to their copyleft, commonly called the system library exception. If the GPL-incompatible libraries you want to use meet the criteria for a system library, then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them.

The criteria for what counts as a "system library" vary between different versions of the GPL. GPLv3 explicitly defines "System Libraries" in section 1, to exclude it from the definition of "Corresponding Source." GPLv2 deals with this issue slightly differently, near the end of section 3.

Uitvoer valt er trouwens niet onder, anders was GCC niet te gebruiken voor commerciële programma's.
@xrf weer wat bij geleert

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:40]

[xrf]

GCC maakt een explicite uitzondering op de GPL om dat mogelijk te maken: https://www.gnu.org/licenses/gcc-exception-3.1.html

[ATS]

Daar heb je de LGPL voor.

[CAPSLOCK2000]

Nee, deze rechtzaak gaat niet over busybox maar vooral over drivers en andere kernelcode.

[Quilt]

De rechtbank kan een expert aanstellen die de broncode van VMWare onderzoekt.

[Stoney3K]

De rechtbank kan een expert aanstellen die de broncode van VMWare onderzoekt.

Dat zal niet zo maar gebeuren in een civiele zaak, eerder in een strafrechtzaak waar zo iemand als getuige van het OM wordt opgeroepen.

In een civiele zaak is het een kwestie tussen twee (in principe gelijkwaardige) partijen, en de rechter kan alleen beslissen wie er gelijk heeft of dat het niet duidelijk genoeg is en er dus geen uitspraak over gedaan kan worden. Hij kan niet zo maar meer onderzoek gaan eisen.

[Quilt]

Ik denk dat je je vergist. Het aanstellen van experten in burgerlijke zaken is gebruikelijk.

[Stoney3K]

Ik denk dat je je vergist. Het aanstellen van experten in burgerlijke zaken is gebruikelijk.

Maar zijn dat dan ook experts die meer bevoegdheden hebben dan een gemiddelde burger? In een strafzaak mag de recherche in opdracht van het OM meer doen, zoals invallen of huiszoekingen, wat voor iemand normaal niet zou zijn toegestaan.

In dit soort zaken zou een deskundige dus de bevoegdheid moeten hebben om inzage in de broncode van BusyBox of ESXi af te dwingen, want dat geven ze niet vrijwillig prijs aan een civiele partij (die code bevat immers bedrijfsgeheimen).

[Quilt]

Neen, de experts hebben niet 'meer bevoegdheden', ze worden aangesteld door de rechter.

De eisende partij zal elementen aanbrengen, en de verwerende partij ook. Als de rechtbank vindt dat het haar aan competenties ontbreekt, zal ze een expert aanstellen. Het klopt natuurlijk dat geen van de partijen verplicht is om medewerking te verlenen aan de rechtbank, maar ik hoef er geen tekeningetje bij maken dat zoiets de positie van de partijen niet verbetert, wel integendeel.

Meer hier:
http://www.victoryadvies....en-civiele-procedure.html

Ik weet wel niet welk recht van toepassing is op deze rechtzaak. (Amerikaans, Duits, ... (?)).

[Maurits van Baerle]

De klagende partij is een Duitser die naar een Duits hof is gestapt (Amtsgerichte Hamburg) dus het zal onder Duits recht zijn.

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 23:40]

[Verwijderd]

Dat is eenvoudig, in een rechtzaak kan de rechter inzage toekennen aan de andere partij en of een rechter kan zo'n huiszoekinsbevel aanvragen. Als VMWare daar niet aan mee werkt dan wil dat zeggen dat ze de rechtsgang belemmeren. Dat gaat niet goed komen.

[Gomez12]

Het is echter over het algemeen wel een uitzonderlijk geval als de rechter dit doet.

Het is niet zo dat ik even kan schreeuwen dat MS mijn hello world code gejat heeft en MS dan maar inzage moet geven.

Het is een juridische mogelijkheid wat jij beschrijft, maar je mag als aanklager wel met een heel solide pak bewijzen aankomen om dit te krijgen.

[Verwijderd]

Ik denk dat dit in dit geval, het geval is.

[latka]

Strings draaien en de link symbols bekijken geven vaak al een hele goede richting of jouw code hergebruikt is. Heb je de source niet voor nodig.

[Gomez12]

Voor het aanspannen van een potentiele miljoenenrechtzaak (aan juridische kosten) zou ik het toch liever niet ophangen aan iets wat "een hele goede richting" geeft

[Olaf van der Spek]

Google is de eigenaar van die code..
Bovendien is Android niet een enkel programma.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 23:40]

[i-chat]

en nogveel belangrijker, android is NIET gpl, maar bsd, die licentie is veel vrijer,

gpl is = eerlijk zullen we alles delen, naai me niet anders vermoord ik je,

bsd = deze software is delen, doe er mee wat je wilt, ook als het mij niet bevalt, en mocht je ooit wat erug willen geven graag maar voel je niet verplicht...

de 2e licentie is vrijer, de eerste eerlijker, het is maar wat je kiest.

[Verwijderd]

en nogveel belangrijker, android is NIET gpl, maar bsd, die licentie is veel vrijer,

gpl is = eerlijk zullen we alles delen, naai me niet anders vermoord ik je,

bsd = deze software is delen, doe er mee wat je wilt, ook als het mij niet bevalt, en mocht je ooit wat erug willen geven graag maar voel je niet verplicht...

de 2e licentie is vrijer, de eerste eerlijker, het is maar wat je kiest.

Leuke uitleg. Als je het vanuit een bedrijf bekijkt dat de code wil (mis)(ge)bruiken.

Voor een niet commercieel persoon of iemand die de code niet wil misbruiken is GPL veel vrijer en eerlijker. Tevens draagt GPL vele meer bij aan verdere ontwikkeling omdat alle verbeteringen weer in de code komen, terwijl dat bij BSD Code niet is.

Android is heeft geen BSD maar een Apache Licentie.

License Apache License 2.0
Modified Linux kernel under GNU GPL v2

IMO een van de slechtere OSS licenties voor een ontwikkelaar.
Zie: Individual Contributor License Agreement

Via deze link: Contributor License Agreements

2. Grant of Copyright License. Subject to the terms and conditions of
this Agreement, You hereby grant to the Foundation and to
recipients of software distributed by the Foundation a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare derivative works of,
publicly display, publicly perform, sublicense, and distribute Your
Contributions and such derivative works.

Je geeft Apache alle rechten op jouw werk, waardoor ze ten alle tijde licentie kunnen wijzigen, zonder goedkeuring van ontwikkelaars.
Bij GPL Code blijft ontwikkelaar de eigenaar van de code. De Licentie kan en mag alleen gewijzigd worden met goedkeuring van de ontwikkelaars van de code.

In principe zou Google kunnen zeggen dat de Apache code vanaf 5.1 een commerciële licentie heeft en niet meer vrij toegankelijk is voor iedereen, dat betekend dat de voorgaande versies wel nog vrij toegankelijk zijn.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:40]

[Rutix]

Wat je zegt is niet waar. Die individual contributor license agreement is alleen voor projects onder de apache organisation, niet alle projecten die de apache 2.0 license gebruiken. Dus je blijft zeker wel de originele copyright houder en eigenaar.

Daarnaast mag je volgens de apache 2.0 license alleen sublicensen en moet je de originele copyright en originele license laten staan. Bron: http://www.apache.org/licenses/LICENSE-2.0

De volgende website is een goede website die je kunt checken voor korte summaries. tldr apache 2.0

[Reactie gewijzigd door Rutix op 23 juli 2024 23:40]

[Verwijderd]

Wat je zegt is niet waar. Die individual contributor license agreement is alleen voor projects onder de apache organisation, niet alle projecten die de apache 2.0 license gebruiken. Dus je blijft zeker wel de originele copyright houder en eigenaar.

Wat jij zegt is niet waar.
Niet alleen Apache projecten ook Android met de Apache 2.0. (Waar mijn voorgaande reactie betrekking op had).

Contributor License Agreement for Individuals

Een bedrijf kiest niet voor de Apache licentie als je de rechten bij de contributer wil laten. Dan kun je net zo goed een BSD of een GPL licentie nemen.

Daarnaast mag je volgens de apache 2.0 license alleen sublicensen en moet je de originele copyright en originele license laten staan. Bron: http://www.apache.org/licenses/LICENSE-2.0

De volgende website is een goede website die je kunt checken voor korte summaries. tldr apache 2.0

Deze opmerkingen zijn totaal niet relevant t.a.v. mijn opmerking.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:40]

[Rutix]

[...]


Wat jij zegt is niet waar.
Niet alleen Apache projecten ook Android met de Apache 2.0. (Waar mijn voorgaande reactie betrekking op had).

Contributor License Agreement for Individuals

Een bedrijf kiest niet voor de Apache licentie als je de rechten bij de contributer wil laten. Dan kun je net zo goed een BSD of een GPL licentie nemen.

I stand corrected maar je deed het wel overkomen als dat iedereen die gebruik maakt van de Apache 2.0 licentie ook meteen de CLA gebruikt en dat is niet waar. Een CLA is best gebruikelijk in gevallen zoals Android omdat ze niet het gezeik willen hebben zoals is gebeurt bij Minecraft modding waar iemand een change in de code heeft laten doen (zonder CLA) en daarna de licentie heeft veranderd en een DMCA heeft gestuurd naar de repository maintainers.

[...]


Deze opmerkingen zijn totaal niet relevant t.a.v. mijn opmerking.

Die zijn wel relevant. Jij maakte namelijk de volgende opmerking:

IMO een van de slechtere OSS licenties voor een ontwikkelaar.

Er is niks mis met de OSS licentie. Waar jij problemen mee hebt is de CLA en dat staat los van de Apache 2.0 licentie.

[Verwijderd]

[...]

I stand corrected maar je deed het wel overkomen als dat iedereen die gebruik maakt van de Apache 2.0 licentie ook meteen de CLA gebruikt en dat is niet waar. Een CLA is best gebruikelijk in gevallen zoals Android omdat ze niet het gezeik willen hebben zoals is gebeurt bij Minecraft modding waar iemand een change in de code heeft laten doen (zonder CLA) en daarna de licentie heeft veranderd en een DMCA heeft gestuurd naar de repository maintainers.

Als deze ontwikkelaar de enige ontwikkelaar is, dan heeft hij/zij het volledige recht om de licentie te wijzigen, of als de ontwikkelaars het eens zijn met een licentie verandering. Je kunt een licentie niet met terugwerkende kracht veranderen dat betekend dat de oude versie nog steeds gebruikt kunnen worden met de oude licentie. Als de licentie het toelaat kan het product geforked worden.
Denk bijvoorbeeld aan XFree86 met de xorg fork en Openoffice (nu apache 2.0) en de libreoffice fork.

Als het over het Bukkit project gaat, is dat een heel ander verhaal. Of een licentie die niet goed over de files verdeeld c.q. niet aangegeven welke files GPL zijn. Of een ontwikkelaar die zich niet aan de regels houd.
Dit zou alleen maar erger geweest zijn onder Apache 2.0 zeker niet beter dan GPL.

Ik zou onderzoeken hoe het zit als het een ontwikkelaar is die zich niet aan de regels houd zou ik het project forken, wat kan omdat het GPL is.

Er is niks mis met de OSS licentie. Waar jij problemen mee hebt is de CLA en dat staat los van de Apache 2.0 licentie.

Geef a.u.b. een voorbeeld van een product met Apache 2.0 licentie zonder CLA.
Geef me a.u.b. aan wat er goed is tav de Apache licentie in vergelijking met GPL of BSD. Ik ken geen enkele goede reden t.o.v. de ontwikkelaar om voor een Apache 2.0 licentie te kiezen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 23:40]

[latka]

Android kernel is Linux en die is en blijft GPL, wat google er ook van zou vinden.

[Olaf van der Spek]

de 2e licentie is vrijer, de eerste eerlijker, het is maar wat je kiest.

Daar ben ik het niet mee eens. GPL geeft de eindgebruiker opties (aanpassen van de source code), BSD geeft de ontwikkelaar opties..
BSD garandeert eindgebruikers helemaal niks.

[CAPSLOCK2000]

Wat GPL zo bijzonder maakt is dat het zich zorgen maakt om de rechten van de gebruiker. De meeste licenties richten zich op het beschermen van de rechten van de developers en doen dat ten koste van rechten van de gebruikers.
Ook BSD richt zich vooral op het beschermen van de rechten van de developers, al is het daar veel losser in dan andere licenties. Eindgebruikers komen er niet expliciet in voor.

GPL geeft rechten aan de eindgebruikers ten koste van de developers. Aangezien er veel meer gebruikers dan developers zijn en developers ook vooral software van anderen gebruiken is het een interessante gedachte om de rechten van de eindgebruikers voorop te stellen.

[iAR]

Maar de eerste is in enkele gevallen dus ook beperkender.

[wankel]

Maar de eerste is in enkele gevallen dus ook beperkender.

In het opzicht dat de ontwikkelaar de gebruiker niet mag beperken, is het beperkender ja...

Als je restricties verbied, is dat dan beperkend? Het is een beetje als een wet aannemen dat er niet gecensureerd mag worden.

[Reactie gewijzigd door wankel op 23 juli 2024 23:40]

[hackerhater]

Deel van Android moet GPL zijn gezien deze gebaseerd is op de Linux kernel.

[Zenety]

Gebruikt Google voor hun apps niet de Apache License?

Edit: Info http://developer.android.com/guide/faq/licensingandoss.html

[Reactie gewijzigd door Zenety op 23 juli 2024 23:40]

[djiwie]

Er is een verschil tussen een bestaand open-source programma aanpassen en dit aanbieden zonder je eigen aanpassingen open-source te maken, en een closed-source programma ontwikkelen op basis van een open-source platform. VMware wordt beschuldigd van het eerste (ze hebben de Linux kernel overgenomen, aangepast, en deze aanpassingen niet openbaar gemaakt), Google doet met Play Services het tweede. Het laatste is bijvoorbeeld een closed-source programma ontwikkelen voor een Linux OS, dat is geen enkel probleem.

[Johan9711]

Android zelf is Open Source. Play services is een in Java geschreven stukje software, dat dus niet onder deze GPL valt.

[Verwijderd]

Alsje een doorsnee android telefoon van bijvoorbeeld HTC koopt dan is misschien 10%-20% van de software nog open source.
De rest is closed source code van Google, HTC, Qualcomm, Broadwell en andere hardware onderdelen leveranciers en mogelijk nog aangevuld met software van andere 3rd party software leveranciers.

[Johan9711]

Het Linux gedeelte is 100% Open source.

[Loller1]

GPL is en blijft een rommel-licentie. De Free Software Foundation zegt dan wel te staan voor vrije software, maar hun GPL is een van de meest gesloten open source licentie die je op tafel kan gooien. Dat je de copyright van andere niet zomaar mag overschrijven is logisch, maar alle andere restricties in de GPL-licentie? Nee. GPLv3 maakt het alleen maar erger. Als je echt voor open source wilt gaan, dan pak je een MIT-licentie of andere gelijkaardige.

[Hellboy!]

Vmware gaat downhill de laatste jaren. Ze hebben geen os, geen duidelijke keuze voor cloud vcac (omgesmurfde dunes workflow pakket) en openstack, waarbij ze eigenlijk alles uitslopen en alleen hun platform ondersteund. Vroeger was esx rock solid, moet je zien hoeveel bugs ze introduceren de laatste jaren.

Ik ben zelf helemaal over op kvm.

[_Thanatos_]

Ik zou bijna zeggen "eigen schuld, moet je je code maar niet GPL licentieren". Want de GPL is de meest achterlijke licentie ooit. Het is zo onredelijk en onwerkelijk. Het forceert feitelijk dat alles dat gemaakt is waar ook maar een byte GPL-code in zit, zelf ook onder de GPL released wordt. Dat is niet realistisch, veel te geforceerd, en hoe mooi het ook allemaal omschreven is, het zou me niets verbazen als het in een rechtzaak omvalt.

[SirBlade]

Misschien heeft VMware een clean room design gedaan van de liniux kernel. Als dat kan met closed source software en zelfs firmware, dan moet dat zeker te doen zijn met open source software. En dankzij vele rechtszaken over dit onderwerp weten we dat dit een legale techniek is.

[chaoscontrol]

Goede zaak. Jammer dat het zo ver moest komen daar hij het al sinds 2007 probeert buiten de rechter om te regelen.

[Verwijderd]

A program is free software if the program's users have the four essential freedoms:

• The freedom to run the program as you wish, for any purpose (freedom 0).
• The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Bron: https://www.gnu.org/philosophy/free-sw.html

[batjes]

Echt vrije code ben je gewoon geheel vrij te doen wat je er mee wilt. En niet dat je een stukje van de code gebruikt in je module, je direct verplicht bent je hele module als gpl vrij te geven.

Dit geeft veel beperkingen die niet nodig zouden moeten zijn. Niet alles hoeft maar open source te worden om het FOSS te hebben.

[Verwijderd]

Nee, dat is waarom FOSS dan ook staat voor Free and Open Source Software. Free software is software die onder de definitie die ik net opsomde valt, valt. Open Source software gebruikt vaak andere licentievormen.

Linux is Free Software, zoals beschreven in de definitie die ik net opsomde en waarvan je de bron kan vinden (de website van GNU, vanwaar de GNU Public License vandaan komt, wat de licentie van de Linux kernel is).

De licentie van de Linux kernel maakt wel enkele uitzonderingen:

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it.

Bron: https://www.kernel.org/pub/linux/kernel/COPYING