Ubuntu en de ‘dreiging’ van softwarepatenten (bij Livre)

8 juli 2008, 8:11 - Geplaatst onder: Open source, Octrooien - 5 reacties

De komende weken brengt Livre een serie artikelen rond Ubuntu, de meestgebruikte Linux-distributie van dit moment. Mark Shuttleworth, de initiatiefnemer van Ubuntu, heeft al meerdere malen aangegeven zich zorgen te maken over patentzaken die worden aangekaart door kleinere patenthouders die niets (meer) te verliezen hebben. Livre vroeg mij of ik dat ook deed, en het antwoord is nee. Daar zet ik zelfs een kratje vrij bier op:

‘Linux schendt honderden patenten van Microsoft’. Met die spierballentaal probeerde Microsoft-topman Steve Ballmer vorig jaar mei weer eens een staaltje FUD (Fear, uncertainty and doubt) de wereld in de helpen. Linux een enge ziekte toewensen hielp niet meer, dus dan maar een enge juridische claim. Nu werd dat getal later bijgesteld: Ballmer was een beetje in de war toen hij het over 235 Microsoft-octrooien had. Hij bedoelde namelijk 235 octrooien van Microsoft en anderen, iets dat vrijesoftwareadvocaat Dan Ravicher in 2004 had geconcludeerd na een diepgaande studie van honderden software-gerelateerde octrooien. Ravicher vond overigens 27 Microsoft-octrooien.

Maar het punt blijft: er zijn tientallen, zo niet honderden octrooien waar een gemiddelde Linux-distributie tegenaan kan lopen. Moeten Linux-distributeurs zich nu zorgen gaan maken? Misschien. Maar niet meer dan elke andere softwaredistributeur.

Lees verder in Ubuntu en de ‘dreiging’ van softwarepatenten bij Livre.

Arnoud

of lees de 5 reacties

Geldt de GPL ook voor (cross-)compilers? (bij FOSSBazaar)

23 juni 2008, 8:08 - Geplaatst onder: Open source - 6 reacties

Ik had zin weer eens iets in het Engels te schrijven, en toevallig ontdekte ik onlangs de Amerikaanse site FOSSBazaar (”open community that was launched by HP and our founding partners Coverity, DLA Piper, Google, the Linux Foundation, Novell, Olliance Group, OpenLogic and SourceForge”). Een heel nieuw onderwerp: geldt de GPL voor de gebruikte compiler om je open source mee te verwerken?

Access to the full source code is an essential aspect of open source software, perhaps even the most essential aspect of all. But what good is source code if it cannot be compiled into an executable? Fortunately this is rarely a problem. Most open source software is designed to compile with the well-known gcc compiler, a standard component of most Linux distributions. With dozens of supported platforms, it is rare to have open source that you can’t compile. But when you do, can you demand a copy of the compiler from the developer?

Lees verder in Does the GPL extend to (cross-)compilers? bij FOSSBazaar.

Arnoud

of lees de 6 reacties

Interview with Arnoud Engelfriet, IP counsel at Philips

18 juni 2008, 8:36 - Geplaatst onder: Open source - Geen reacties

logo_mysql_sun.gifVoor het CIO Corner magazine van MySQL gaf ik in maart een interview dat nu pas online staat:

Q: Mr. Engelfriet, in an article in the “Intellectual Asset Magazine” you recommend the use of open source software primarily for the commodity features of a product. Could you please expand on this recommendation?

Lees verder in MySQL :: Interview with Arnoud Engelfriet, IP counsel at Philips.

Dat artikel in IAM is het artikel Mixen van open en gesloten software.

Arnoud

als eerste

Plugins voor phpBB: verplicht GPL of toch niet?

12 mei 2008, 8:03 - Geplaatst onder: Open source, Auteursrecht - 12 reacties

Bij de phpBB-gemeenschap een interessante discussie over plugins voor deze forumsoftware. PhpBB is open source en beschikbaar onder de GPL (versie 2). De vraag is dan wat dat betekent voor uitbreidingen en plugins voor phpBB.

De phpBB software is niet zo netjes opgezet als Joomla!, waardoor mijn redenering over plugins voor Joomla van afgelopen februari hier niet zomaar opgaat. Bij phpBB kun je een uitbreiding (een “mod”) alleen maken door regels code uit phpBB zelf te wijzigen en van uitbreidingen te voorzien. Dan zitten er in je mod dus stukken code die uit phpBB-bestanden komen. Dat is in principe een verveelvoudiging in gewijzigde vorm of een ‘afgeleid werk’ in de terminologie van de GPL.

Op de phpBB-site zelf wordt het zo uitgelegd:

Most modification require phpBB to work so most modifications need to be released under the GPL v2. … All modifications will have some part of it that needs to be released under GPL v2. These parts are usually what is in the install script or in other words, the part that integrates the script in to phpBB.

In de discussie zegt ene Alfatrion nog:

Copying several lines of could would fall under fair use for the states or the more limited European quoatation exemptions (art. 15a). This is true for most of the world because of the Berne Convention.

Wellicht is dit gebruik ‘fair use’ naar Amerikaans recht, maar ik betwijfel het. En gezien het feit dat deze persoon mijn blog citeert, is hij (zij?) waarschijnlijk Nederlander. En dan kan hij geen beroep doen op ‘fair use’. Wie in Nederland een beschermd werk wijzigt op een manier die schending van auteursrecht oplevert, kan in Nederland voor de rechter worden gedaagd. De zaak zal dan naar Nederlands recht worden beoordeeld.

Citaatrecht bij software is iets waar weinig juristen in geloven. Ik zou denken dat het opgaat als sprake is van een bug report, dan moet je regels citeren om te laten zien waar de fout zit. Maar jij bespreekt of bekritiseert deze regels niet, je breidt ze uit. En dat is een verveelvoudiging in gewijzigde vorm en geen citaat.

Afhankelijk van hoe veel je kopieert uit de originele bestanden, zou je wellicht aanspraak kunnen maken op artikel 18a Auteurswet:

Als inbreuk op het auteursrecht op een werk van letterkunde, wetenschap of kunst wordt niet beschouwd de incidentele verwerking ervan als onderdeel van ondergeschikte betekenis in een ander werk.

Een paar regeltjes uit phpBB in een groot eigen werk, met als enige doel aangeven waar in phpBB het eigen werk moet worden ingevoegd, zou onder deze uitzondering moeten vallen.

Ga je echter uitgebreid bestaande code aanpassen en niet zozeer eigen code toevoegen, dan ben je toch echt een afgeleid werk aan het maken.

Arnoud

of lees de 12 reacties

Waarom bedrijfsjuristen ‘nee’ zeggen tegen open source (bij Livre)

30 april 2008, 8:25 - Geplaatst onder: Open source - Geen reacties

Gisteren verscheen op Livre mijn column over waarom bedrijfsjuristen ‘nee’ zeggen tegen open source:

‘Onze bedrijfsjurist is er achter gekomen dat we open source gebruiken, en dat is nu verboden.’ Helaas nog steeds een veel voorkomende klacht bij software-ontwikkelaars en ICT-afdelingen. Bedrijven willen een stukje open source gebruiken, maar de licentie is niet helemaal duidelijk over deze specifieke situatie. En wat doe je als een licentie onduidelijk blijkt? Dan ga je naar de bedrijfsjurist. En wat doet die in zo’n geval? Die zegt ‘nee’.

Lees verder bij Livre. Al was het maar om erachter te komen of ik andijvie lust.

Arnoud

als eerste

De rechtsgeldigheid van software-EULA’s

5 april 2008, 10:26 - Geplaatst onder: Open source, Contracten - 40 reacties

Zijn EULA’s rechtsgeldig? Die vraag is altijd goed voor een flink debat wanneer er weer eens een EULA met rare bepalingen opduikt. “De rechtsgeldigheid van een EULA wordt door sommigen betwijfeld”, zo meldt bijvoorbeeld Wikipedia. Maar er is geen duidelijk “ja” of “nee” te geven op zo’n algemene uitspraak.

De term “EULA” staat voor “End-User License Agreement” en wordt gebruikt om softwarelicenties aan te duiden die een bedrijf aan een consument (eindgebruiker) geeft. Een licentie is een contract. Om dus te kijken of een EULA “rechtsgeldig” is, moet je deze langs de regels van het contractenrecht leggen. Daarbij zijn vier stappen te onderscheiden:

  1. Totstandkoming van een overeenkomst
  2. Terhandstelling van de EULA-voorwaarden
  3. Vernietigbaarheid van de EULA-voorwaarden
  4. Strijd met hoger recht

Totstandkoming van een overeenkomst
De eerste vraag bij elke overeenkomst is of er eigenlijk wel een overeenkomst is. Daarvoor is nodig dat de ene partij een aanbod doet dat de ander aanvaardt. Bij een EULA is het aanbod een gebruiksrecht voor de software. Wie software rechtmatig verkrijgt (koopt in de winkel of downloadt bij de fabrikant of een geautoriseerde verspreider), heeft echter strikt gesproken geen EULA nodig.

Praktisch punt is wel dat vrijwel alle software tijdens de installatieprocedure je verplicht de EULA te aanvaarden. Doe je dat niet, dan kan de installatie niet worden voltooid. Dat is op zich een geldige constructie. De leverancier is niet verplicht om je de keuze te geven tussen een EULA of het beperkte wettelijke gebruiksrecht.

Natuurlijk ben je vrij om de EULA vervolgens niet te aanvaarden. Je mag dan de software niet gebruiken, en dat is natuurlijk wel zuur als je voor de software betaald hebt. De winkel zal de software niet terugnemen, omdat de doos geopend is. En bij een betaalde download is het al helemaal praktisch onmogelijk om de software te retourneren. Daar wringt iets: de leverancier kan toch niet zomaar voorwaarden opleggen en het tegelijkertijd onmogelijk maken om die af te wijzen? Dat klopt, en om te kijken hoe dat uitpakt voor EULA’s, moeten we naar het recht van de algemene voorwaarden.

Terhandstelling van de EULA-voorwaarden
De voorwaarden uit de EULA zijn voor elke klant hetzelfde. Daarmee zijn ze juridisch aan te merken als algemene voorwaarden. De belangrijkste eis is dan dat ze voor of bij het sluiten van de overeenkomst ter hand gesteld zijn, en ook nog eens op de juiste manier.

Dat roept dus de vraag op wanneer de overeenkomst gesloten is. Bij een aankoop is goed te verdedigen dat je de overeenkomst sluit wanneer je het geld betaalt en de software verkrijgt (in een doos of als een download). In dat geval zijn de EULA-voorwaarden niet van toepassing, omdat ze pas na het sluiten van de overeenkomst worden getoond.

Sommige sites verplichten kopers dan ook om akkoord te gaan met de EULA voordat ze de software mogen downloaden. Bij verkoop van software in dozen kan de EULA dan in een heel klein lettertype worden afgedrukt op de achterkant van de doos. Dat mag, zolang het maar voor een redelijk mens leesbaar is. In die situaties is de EULA gewoon van toepassing.

Een EULA die pas na een betaalde download wordt getoond, of die pas te lezen is na het openen van de dichtgesealde doos, is dus niet tijdig ter hand gesteld. Tenzij je er vanuit gaat dat de EULA en de koopovereenkomst twee gescheiden overeenkomsten zijn.

Maar er is nog een tweede eis: de EULA moet op de juiste manier ter hand gesteld zijn. De hoofdregel is dat je een stuk papier moet krijgen waar de EULA op staat. Wanneer de EULA alleen op het beeldscherm in te zien is, is sprake van een overeenkomst langs elektronische weg. De wet zegt dan dat de EULA op een zodanige wijze moet worden getoond dat deze door de gebruiker kunnen worden opgeslagen en voor hem toegankelijk zijn ten behoeve van latere kennisneming. Met een PDF of Word-bestand in de zipfile is aan die eis voldaan.

Tekst in een venstertje voldoet in beginsel niet aan deze eis. Het kunnen opslaan en later inzien is een belangrijke eis bij elektronische overeenkomsten. Er is echter vaak geen manier om achteraf nog eens de EULA na te lezen (probeer het voor de grap eens te vinden bij uw gekochte software). Natuurlijk zou je zelf de tekst kunnen proberen op te slaan, bijvoorbeeld door de tekst via kopiëren en plakken in een Word-bestand te stoppen. Maar zo veel moeite doen is niet de bedoeling van dit wetsartikel. In sommige gevallen is het trouwens onmogelijk om tekst te kopiëren uit het EULA-venster.

Vernietigbaarheid van de EULA-voorwaarden
Omdat EULA’s algemene voorwaarden zijn, mogen ze niet onredelijk bezwarend zijn. Bij consumenten als eindgebruikers geldt er bovendien een zwarte en grijze lijst met ‘verboden’ bepalingen. Een EULA-bepaling die daarmee in strijd is, kan dus worden vernietigd. Denk hierbij bijvoorbeeld aan de uitsluiting van aansprakelijkheid of een beding dat een Californische arbiter de enige is die mag beslissen over een geschil.

EULA’s zijn vaak erg streng: de software mag maar op één PC worden geïnstalleerd, en niet worden gekopieerd laat staan verspreid. Maar “streng” is nog niet hetzelfde als “onredelijk bezwarend”. Je zult als gebruiker moeten bewijzen dat de leverancier deze eis redelijkerwijs niet mag opleggen, of dat hij in een concrete situatie niet werkbaar voor jou is. De zwarte en grijze lijst draaien voor een aantal situaties die bewijslast om.

Strijd met hoger recht
In contracten mag je veel met elkaar afspreken. Op sommige plekken heeft de wetgever een grens getrokken: dit zijn de wetsbepalingen van dwingend recht. Hiervan mag je niet in je EULA afwijken. Zo heeft de verkrijger van een stuk software het recht om daarvan een backup te maken, ongeacht wat in de overeenkomst staat. Maar zulke bepalingen zijn wel de uitzondering.

Naast zo’n keihard, specifiek verbod zijn er ook nog meer algemene normen waaraan je een EULA zou kunnen toetsen. Zo mogen contractsbepalingen niet in strijd zijn met de redelijkheid en billijkheid, en zou je zelfs kunnen betogen dat een bepaalde bepaling uit een EULA in strijd is met een grondrecht zoals privacy of vrije meningsuiting. Sommige EULA’s verbieden bijvoorbeeld het publiceren van resultaten van benchmarks van de software zonder toestemming van de maker.

Aantonen dat sprake is van een inbreuk op een grondrecht zal niet meevallen. Een EULA mag best beperkingen stellen aan grondrechten, zolang die beperkingen maar niet verder gaan dan noodzakelijk is voor het doel. Die benchmarkbepaling zou bijvoorbeeld best gerechtvaardigd kunnen zijn bij een testversie die bij een select publiek verspreid wordt.

Samenvattend: EULA’s zijn in beginsel een rechtsgeldige manier om gebruikers van software bepaalde voorwaarden op te leggen. Wel moet de gebruiker ze tijdig hebben kunnen inzien, en bij elektronische teksten ze ook hebben kunnen opslaan. Bepalingen uit een EULA zijn te vernietigen als ze onredelijk bezwarend zijn, of als de gebruiker kan aantonen dat ze botsen met een hoger recht. Maar dat zal eerder de uitzondering dan de regel zijn.

Arnoud
De foto van de CD uit de envelop is gemaakt door Wellington Grey en is beschikbaar onder de Creative Commons 3.0 BY-SA licentie.

of lees de 40 reacties

Belastingdienst schendt open source licenties

2 april 2008, 8:18 - Geplaatst onder: Open source - 15 reacties

De Belastingdienst overtreedt volgens een open source-deskundige meerdere open-sourcelicenties met de aangiftesoftware, meldt Webwereld. Softwareontwikkelaar en -auditor Peter Roozemaal heeft de Belastingaangiftesoftware voor Linux uitgeplozen. In zijn rapport meldt hij dat de OpenSSL en GTK+ licenties niet zijn nageleefd.

De OpenSSL licentie vereist namelijk dat je in de documentatie bij het product de licentievoorwaarden vermeldt. De Belastingdienst volstaat met een link naar de licentievoorwaarden zoals die op internet te vinden zijn. Slordig.

Voor GTK+ ligt het iets gecompliceerder. Deze bibliotheek is beschikbaar onder de LGPL versie 2. De Belastingdienst heeft de software statisch gelinkt met haar applicatie. De LGPL eist dan dat je de gebruiker in staat stelt de GTK+ onderdelen te vervangen. Wat je daarvoor precies moet uitleveren, hangt af van de situatie, maar omdat de Belastingdienst simpelweg niets heeft uitgeleverd, is het wel duidelijk dat de licentie op dit punt niet is nagekomen.

Pijnlijk. Maar wat is de consequentie? Roozemaal schrijft namelijk:

Zolang de Belastingdienst niet aan alle van toepassing zijnde licentievoorwaarden voldoet, is er sprake van auteursrechtinbreuk en verspreiding van de Aangifteprogramma’s behoort gestaakt te worden totdat aan alle licentievoorwaarden voldaan kan worden.

Niet helemaal.

De OpenSSL licentie bepaalt nergens dat de licentie automatisch vervalt als je hem schendt. Daarvoor zal dus een rechtshandeling van de makers nodig zijn. In Nederland zijn softwarelicenties contracten. Wie een bepaling uit een contract niet naleeft, schendt het contract. Op grond daarvan mag de licentiegever het contract ontbinden. Maar dat gaat niet automatisch.

De GTK+ licentie heeft wel een bepaling over ontbinding bij schending:

You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

Die laatste zin beperkt het effect tot wat de Belastingdienst zelf doet. De ontvangers/downloaders van de software mogen deze gewoon blijven gebruiken. Alleen verdere verspreiding van de software door de Belastingdienst of anderen is niet toegestaan.

En ik vraag me nog af in hoeverre toepassing van een dergelijke algemene voorwaarde niet als onredelijk bezwarend te zien is in situaties als deze. Naar Nederlands recht mag je een contract bij een tekortkoming niet ontbinden als “de tekortkoming, gezien haar bijzondere aard of geringe betekenis, deze ontbinding met haar gevolgen niet rechtvaardigt.” Dit is geen dwingend recht (zo te zien) maar of je zó ver kunt gaan in algemene voorwaarden, betwijfel ik.

Het is voor mij dus geen uitgemaakte zaak dat de Belastingdienst haar licentie op GTK+ kwijt is en de software niet meer mag verspreiden. Maar ze moeten wel als de wiedeweerga aan de slag om deze problemen te repareren. Want uitermate slordig is het wel.

Heeft iemand dit al aan het GTK+ team gemeld eigenlijk?

Arnoud

of lees de 15 reacties

Over open code, vrijheid en er beter van worden (bij Livre)

16 maart 2008, 11:08 - Geplaatst onder: Open source - 2 reacties

Voor Livre schreef ik een column over motivaties om mee te doen aan open source:

‘Jullie gebruiken open source alleen maar omdat je daar zelf beter van wordt!’ Dat verwijt kreeg ik een tijd geleden bij een lezing over open source. De ‘jullie’ was het bedrijf waar ik werk, en inderdaad gebruikt dat bedrijf open source in producten. Dat scheelt ontwikkeltijd en kosten, terwijl het product er alleen maar beter van wordt. Da’s mooi voor de koper en daarmee weer mooi voor ons. En daar had deze persoon moeite mee: zelf profiteren van open source in plaats van, net als de hele open source gemeenschap, alles gratis doen. Het is echter inherent aan open source dat anderen ‘zomaar’ rijk zouden kunnen worden van jouw werk.

Lees verder in Over open code, vrijheid en er beter van worden bij Livre - Open, Vrij en Duurzaam.

Arnoud

of lees de 2 reacties

Veilig gebruik van open source - de verkeerde vraag

7 maart 2008, 9:00 - Geplaatst onder: Open source, Innovatie - 6 reacties

Hoe gebruik ik op een veilige manier open source in mijn product of bedrijf? Dat is een van de meest gestelde vragen aan juristen. Er bestaan veel mythes en onduidelijkheden over open source licenties. Kun je nou wel of niet dynamisch linken met GPL software zonder je eigen software GPL te maken? Mag je open source verkopen of alleen een onkostenvergoeding vragen?

Ik denk alleen dat het de verkeerde vraag is.

“Veilig” betekent in deze context namelijk meestal “zonder dat ik mee hoef te doen aan al die rare open source voorwaarden”. Vaak wordt open source gebruikt als goedkoop alternatief voor een bestaande proprietaire oplossing. Het staat op internet, er zijn geen licentiekosten en het werkt nog beter ook. Mooi zo, in het product er mee. En dan blijkt dat open source wel degelijk licentievoorwaarden stelt. Vaak moet je broncode meeleveren, en soms nog je eigen wijzigingen of uitbreidingen ook. Maar dat was niet de bedoeling! Wat nu, hoe voorkom ik dat mijn harde werk nu gepubliceerd moet worden?

En wie zich die vragen stelt, is fout bezig. Je beschouwt software dan nog steeds als je eigendom, iets waar je zeggenschap en controle over wilt houden. Open source is in die optiek niet meer dan een toeleverancier die gekke voorwaarden stelt.

Open source is veel meer. Open source gaat om samenwerken, om samen innoveren. En samenwerken doe je niet achteraf. Dat is iets dat je plant vanaf het eerste moment. Je moet vooraf bedenken waarover je wilt samenwerken, wat je gezamenlijk wilt ontwikkelen en wat je liever voor jezelf houdt zodat je je product uniek kunt maken of houden.

Kortom, weet waarom je open en gesloten software mixt, en zorg ervoor dat je weet wat je open of gesloten wilt houden.

Arnoud

of lees de 6 reacties

Plugins voor Joomla: verplicht GPL of toch niet?

26 februari 2008, 8:28 - Geplaatst onder: Open source - 3 reacties

Een lezer had een plugin voor het open source content management system Joomla! gemaakt, en vroeg zich af of hij die mocht verkopen zonder de broncode open source te maken. Joomla! is beschikbaar onder de GPL. Een afgeleid werk, dat wil zeggen een aanpassing of uitbreiding, mag je dus alleen ook weer onder de GPL verspreiden. Je mag er best geld voor vragen, maar je moet de broncode meeleveren. Geld vragen heeft niet zo veel zin, want iedereen mag de software weer verspreiden, zelfs gratis.

Maar hoe zit dat met een plugin? De FSF, auteurs van de GPL, vinden niet verrassend dat elke plugin GPL moet worden. De tekst van GPL (v2) zegt echter:

If identifiable sections of [the modified] work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

Een plugin die uitsluitend gebruik maakt van de gewone plugin API zou ik beschouwen als een apart werk. Er zitten geen auteursrechtelijk beschermde stukjes van Joomla zelf in zo’n plugin. Het aanroepen van API calls is technisch noodzakelijk en daarom niet auteursrechtelijk relevant. En in die situatie mag je de plugin los van Joomla! verspreiden op elke manier en onder elke licentie die je goeddunkt.

Wat niet mag, is Joomla! in combinatie met de plugin verspreiden. Maar dat komt niet zo vaak voor, omdat Joomla! een webapplicatie is. Plugins worden eigenlijk altijd los gedownload door mensen die Joomla! al geïnstalleerd hebben. Joomla! zelf heeft hierover nagedacht en concludeert dat :

We’ve also decided that we do not have the authority to publish Joomla! under a version of the GPL that gives exceptions for proprietary extensions. It’s difficult to relicense a GPL’d project, and there is no indication that OSM currently has that ability. Our current understanding is that extensions that aren’t released under the GPL or compatible licenses are non-compliant, and that view is based on the guidance of both the Free Software Foundation and the Software Freedom Law Center.

Op zijn minst zul je dus enige weerstand vanuit de Joomla!-gemeenschap ondervinden als je plugins uitbrengt onder een andere licentie dan de GPL. Echter, gezien het feit dat er heel veel plugins onder een “commercial license” bij Joomla! zelf te vinden zijn, zou ik me daar geen al te grote zorgen over maken.

Zie ook de recente discussie bij Joomla! zelf.

Arnoud

of lees de 3 reacties
« Vorige PaginaVolgende Pagina »

Copyright Arnoud Engelfriet - Some rights reserved - Powered by WordPress