Mag je licentie-incompatibele dependencies meeleveren met je software?

| AE 9144 | Open source, Software | 34 reacties

Een lezer vroeg me:

Bij veel opensourcepakketten heb je allerlei extra software nodig, zogeheten dependencies. Soms is deze extra software meegeleverd met het pakket, maar vaak niet. Je moet dan maar hopen dat het via de repository van je Linux-distributie beschikbaar is. Ik had vernomen dat dat soms een juridische keuze is, hoe zit dat?

Het lijkt zo logisch om, als je eigen software afhankelijk is van andermans open source, die open source mee te leveren. Het is immers gewoon toegestaan om open source software te verspreiden, dat is het hele punt van open source. Het doet dus wat raar aan dat je bepaalde open source niet mee mag leveren.

De reden dat het soms toch niet kan, zit hem in de licentievoorwaarden. Sommige opensourcelicenties (met name de GNU GPL) eisen dat zogeheten afgeleide werken alleen mogen worden gedistribueerd onder die licentie. Als de licentie van het andere werk dit niet toestaat – zogeheten licentie-incompatibiliteit – dan is het dus niet mogelijk die twee samen te verspreiden.

Wat precies een afgeleid werk is, is al decennia een lange discussie, maar goed verdedigbaar is dat gebruik van een dependency daaronder valt. Heb je een specifiek ander stuk software nodig, dan bouw je voort op dat andere stuk software en dus ben je daar een afgeleide van. Hoewel ook goed verdedigbaar is dat je dan alleen functionaliteit aanroept, en dat valt buiten het auteursrecht en dus ook buiten de licentiescope. Maar als je dus zegt dat inroepen van dependencies jouw software een afgeleid werk daarvan maakt, dan moeten de licenties van de software en de dependencies allemaal compatibel met elkaar zijn.

Het gekke is dat het wél toegestaan is – ongeacht compatibiliteit – om te melden welke dependencies er gelden en de gebruiker die zelf te laten downloaden en installeren. Dat mag je zelfs automatiseren met een handig installatiescript of package manager-functionaliteit. Opensourcelicenties zijn namelijk distributielicenties, oftewel de voorwaarden gelden pas bij distributie. Wie alleen downloadt en gebruikt, heeft dus niets te maken met compatibiliteit van eventuele licenties.

Arnoud

Wat is beter voor open source: rechtszaken of praten?

| AE 8911 | Open source | 16 reacties

gpl-sans-plombeOh oh, Linus Torvalds in de bocht in een discussie bij de Linuxfoundation over GPL handhaving. Dan weet je het wel. De stelling was: “we can all decide to give up on the GPL, or we can enforce it in Courts.” Torvalds, zeer karakteristiek: “this arguing for lawyering has become a nasty festering disease, and the SFC and Bradley Kuhn has been the Typhoid Mary spreading the disease.” De juristerij als builenpest, oké dan. Heeft hij een bult, eh punt?

Handhaving van de GPL bij de rechter komt zelden voor. Afgezien van een paar simpele kortgedingzaken in Duitsland is er niemand die daarover echt procedeert. Daardoor ontstaat er enige onzekerheid in de markt: hoe ver gaat die GPL nou, wat mag er wel of niet. Maar het omgekeerde komt ook voor: geen rechtszaken, dan geloof ik het wel en ga ik gewoon doen wat ik wil totdat ze piepen.

Dat piepen, dat gebeurt regelmatig. De Linux-mensen, maar ook vele anderen, steken een hoop energie in het aanspreken van bedrijven en instellingen die de GPL niet netjes naleven. Informeel en achter de schermen, joh er gaat iets niet helemaal lekker, mag ik je een tip geven? En vrijwel altijd heeft dat effect, zij het dat het enige tijd kan duren. (Ik spreek uit persoonlijke ervaring vanaf de ‘andere kant’ van die tips.)

Zie je een overtreding van de GPL op jouw code, dan kún je natuurlijk ook een blafbrief sturen en daarna naar de rechter. Dat heeft nog niemand gedaan, mogelijk vanwege de kosten en het gedoe. Ook de onbekende status van de GPL speelt een rol – ga je wel winnen, zegt de rechter niet bijvoorbeeld iets doms straks over afgeleide werken waarmee de GPL tandeloos zou worden.

Torvalds:

But quite apart from the risk of loss in a court, there real risk is something that happens whether you win or lose, and in fact whether you go to court or just threaten: the loss of community, and in particular exactly the kind of community that can (and does) help. You lose your friends.

En dat is natuurlijk waar. Als je iemand aanklaagt, verstoor je de relatie. Want welk bedrijf je ook dagvaardt, de reactie zal eigenlijk altijd hetzelfde zijn: de luiken gaan dicht, een externe advocaat doet de correspondentie en alle banden met het OSS-project in kwestie gaan de ijskast in want alles kan tegen je worden gebruikt. Van zo’n klap herstel je niet makkelijk. En als je dat als community doet, loop je ook de kans dat ánderen gaan denken, die club daar moeten we van wegblijven want die klagen je aan, raar spul dat open source. Dus het is zeker niet gezegd dat het een goede move is.

Natuurlijk, het gevolg van de Linus-aanpak is wel dat sommige gebruikers wegkomen met licentieschendingen. Dat voelt oneerlijk; doe jij veel moeite netjes compliant te zijn, gaat je buurman je de pas afsnijden met in feite gejatte code. En dan zegt die Torvalds “heb geduld, we spreken ze nog wel een keer en over een jaar of twee draaien ze vast bij”. Logisch dat je daar juridisch van gaat dreigen. Maar dan kom ik weer bij het juridische punt: hoe groot acht je de kans dat je gaat winnen, en wat heeft jouw rechtszaak dan voor gevolgen voor de community?

Arnoud

Maakt die Google/Oracle-uitspraak de GPL krachteloos?

| AE 8683 | Open source, Software | 33 reacties

gpl-sans-plombeJe kunt je mooie GPL vaarwel kussen, las ik bij Ars Technica vorige week. Die Google/Oracle uitspraak die een API fair use verklaarde, gaat namelijk de GPL en consorten onderuit schoffelen. Oké, het was de advocaat van Oracle die dat schreef, maar er zit een argumentatie bij. Dus laten we die eens nader bekijken.

In het kort is het een typisch “de wereld stort in want ik kreeg ongelijk”-verhaal dat te reduceren is tot deze quote:

While we don’t know what ultimately swayed the jury, Google’s narrative boiled down to this: because the Java APIs have been open, any use of them was justified and all licensing restrictions should be disregarded. In other words, if you offer your software on an open and free basis, any use is fair use.

Volgens mij slaat advocate Hurst hier de plank stevig mis, want er is nogal een verschil tussen een API hergebruiken met je eigen code en het hergebruiken van code. En dát is waar de GPL voor geschreven is: copypasten van code, of het linken/combineren van die code in je eigen software. Bij dergelijke handelingen heb ik weinig twijfel dat sprake is van een auteursrechtelijk relevante handeling.

Inderdaad, als iemand een GPL header file of API zou hebben en jij zou een eigen implementatie daarvan schrijven, dan zou je waarschijnlijk in Amerika onder fair use daarmee vrij lopen zodat de GPL niet op jou van toepassing zou zijn. Maar is dat vervelend? Volgens mij is dat een behoorlijk uitzonderlijke situatie en zeker niet de normale wijze van hergebruiken van iemands GPL werk.

Dus nee, hier wordt uit de nek gekletst.

Arnoud

Hoe kan ik een opensourcemodule opnieuw implementeren?

| AE 8194 | Open source, Software | 18 reacties

Een lezer vroeg me: Ik werk aan een opensourceproject dat een kloon (fork) is van een groter project. Wij krijgen bij onze nieuwste module nu het verwijt hun auteursrechten geschonden te hebben omdat de code te veel lijkt. Maar wij hebben deze echt zelf geschreven, hoewel de module wel exact hetzelfde doet. Plegen wij nu… Lees verder

Maakt linken van een GPL bibliotheek je software automatisch GPL?

| AE 7290 | Open source, Software | 40 reacties

Intrigerende discussie in de comments vorige week: als je programma linkt tegen een GPL open source library, is je programma dan alleen onder de GPL te verspreiden? Immers, de GPL zegt dat je afgeleide werken alleen onder de GPL mag verspreiden. En wat is er nu meer afgeleid dan een programma dat noodzakelijkerwijs een library… Lees verder

Spionagemalware Duqu schendt GPL

| AE 3040 | Grappig, Open source | 25 reacties

Sjongejongejonge, wat zullen de Duqu-makers daar wakker van liggen: de beruchte spionagemalware Duqu bevat open source-code die onder de ‘virale’ licentie GPL vallen, las ik bij Webwereld. Duqu blijkt open source blokken te bevatten van derden en die licentie te negeren. Tsja, wat moet je met zo’n berichtje? Ik noem het maar ‘grappig’, wanthet is… Lees verder

Kun je als koper van een Tomtec tablet ze dwingen de Linuxbroncode vrij te geven?

| AE 2939 | Open source | 61 reacties

Een lezer wees me op een draadje bij Gathering of Tweakers over de broncodes van de Linuxkernel in een Tomtec tablet: als aanvulling ik ben afgelopen vrijdag in een mailwisseling met TOM-TEC er achter gekomen dat zij niet eens (willen) snappen wat gpl betekend als kernel licentie en dat zij eigenlijk hun source moeten openbaren…. Lees verder

Zijn WordPress themes GPL?

| AE 2785 | Open source | 10 reacties

Een lezer vroeg me: Alweer een tijdje geleden speelde een discussie over het Thesis theme voor WordPress. Dat is een systeem voor layouts en uitbreidingen op het WordPress blogsysteem, dat eerst onder een gesloten (niet-open source) licentie beschikbaar was. WordPress zelf is GPL, en de auteurs daarvan eisten dan ook dat Thesis ook GPL moest… Lees verder

Zitten fabrikanten Android zonder GPL-distributierecht voor Linux?

| AE 2659 | Open source | 19 reacties

Omdat de code van besturingssysteem Android niet (volledig) openbaar is en gepubliceerd wordt, vervalt het recht voor veel fabrikanten om Androidtoestellen te verkopen, meldde Nu.nl gisteren. Men baseert zich op Florian Mueller, die het weer uit de VS haalde. Het pijnpunt zit hem in artikel 4 van de GPL: You may not copy, modify, sublicense,… Lees verder