Tag: Open source

About Open source

Subscribe Feeds

Verzoek om open source-certificering van Chicken Dance License; kans is klein

Geplaatst op in Intellectuele rechten, 10 reacties

Een nieuw voorgestelde opensourcelicentie zorgt voor de nodige beroering bij het Open Source Initiative, dat licenties van een officieel stempel voorziet. De Chicken Dance License bevat namelijk naast enkele typische juridische clausules ook de nodige humor. Net als de WTF Public License zorgt dat voor discussie: mag dat wel, humor in een licentie?

De licentie is een variant op de bekende BSD licentie, die eigenlijk alleen eist dat je de bronvermelding intact laat en de auteurs niet aanklaagt als er problemen zijn met de code. Maar wanneer iemand software onder deze licentie wil verspreiden zonder de broncode te delen, dan moet hij voor elke 1000 kopieën zijn personeel één keer naar de Ententanz (de Duitse versie inderdaad) laten luisteren. Wie meer dan 20.000 kopieën in binaire vorm wil verspreiden, moet zelf een video publiceren waarin de Ententanz wordt uitgevoerd. En verder is het licentienemers te allen tijde verboden het woord plinth (sokkel) te gebruiken.

De auteur van de motiveert deze beperkingen als volgt:

“The purpose of this license is to make intellectual property far more entertaining to deal with,” writes Andrew Harris, the author of the license. “Rather than boring old GPL violations or licensing agreements for GPL software, [an] entertaining video of people doing the chicken dance is produced. If this was taken to court, CDL violators may even have to perform the chicken dance retroactively!”

OSI heeft al laten weten dat officiële goedkeuring onwaarschijnlijk is: de licentie discrimineert mensen met een handicap, die immers de dans niet kunnen uitvoeren. Ook wordt de gehele sokkelindustrie uitgesloten van het gebruik, wat in strijd is met de OSI-regels dat open source in elke tak van de industrie gebruikt moet kunnen worden. Als de wapenindustrie Linux in een kruisraket mag stoppen, dan moet de sokkelindustrie toch ook gewoon deze software kunnen gebruiken.

Zelf vraag ik me nog af hoe het zit met de Buma/Stemra/Sena-rechten over de muziek. Indirect wordt er nu toch de eis gesteld van een financiële vergoeding, immers over de muziek moeten BUMA- en Sena-rechten worden betaald. En geld laten betalen om open source te mogen gebruiken is ook tegen de OSI-regels.

Arnoud

Mag je LGPL software subclassen?

Geplaatst op in Intellectuele rechten, 5 reacties

ketting-chain-link.pngEen lezer vroeg me:

Naar aanleiding van het softwareboek vroeg ik me af of je ook aandacht gaat besteden aan de kwestie over linken, met name bij de LGPL. Ik weet dat dat legaal is, maar hoe werkt dit bij talen waarbij het concept ‘linken’ niet bestaat? Denk aan objectgeorienteerde talen zoals Java of Objective-J. Daarbij maak je eerder gebruik van code door objecten te subclassen (vererven). Is een klasse die eigenschappen erft een afgeleid werk? En mag je die klasse dan onder een eigen licentie uitbrengen als hetgeen waar je van afleidt, LGPL is?

De GPL en LGPL zijn de twee bekendste opensourcelicenties. Ze zijn grotendeels hetzelfde in opzet. Het belangrijkste verschil zit hem in hoe wordt omgegaan met ‘afgeleide werken’ of wat we in Nederland ‘verveelvoudigingen in gewijzigde vorm’ zouden noemen. Daarvan is sprake als je eigen code op bepaalde manieren combineert om zo een nieuw stuk software te maken.

De GPL eist dat dergelijke afgeleide werken óók weer GPL worden gemaakt wanneer je ze verspreidt. De LGPL doet dat niet, in ieder geval niet als je je eigen code via linking combineert, zo staat in artikel 5 van de LGPL v 2.1. Je bent bij de LGPL alleen verplicht om daadwerkelijke wijzigingen aan de LGPL-code zelf beschikbaar te stellen in broncodevorm wanneer je deze distribueert.

De LGPL is geschreven met C in het achterhoofd, vandaar de vrij specifieke bepalingen over linken. Het is dan ook erg moeilijk om te zeggen hoe de licentie uitpakt voor talen die niet linken maar juist subclassen of een framework bieden waar je mee ontwikkelt.

Er lijkt binnen de Java community een consensus te zijn dat LGPL klassen wél gesubclassed mogen worden maar GPL klassen niet. Maar dat is meer een informele afspraak tussen developers en niet echt een juridisch afdwingbaar iets – tenzij de rechter vindt dat die afspraak gezien mag worden als heersende mening oftewel gewoonterecht. De FSF schrijft “niets aan de hand, gewoon doorlopen”

The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.

Voor LGPLv2.1 wordt er dan aan toegevoegd dat “function signatures are checked against the library, creating a link”, wat me een beetje een gezochte interpretatie lijkt want dat is niet het soort ‘link’ dat LGPLv2.1 bedoelt. Maar goed.

De LGPLv3 lost het iets handiger op. Daar wordt in meer algemene zin gesproken van “combining or linking an Application with the Library.” Het lijkt mij dat subclassen of vererven van code ook wel onder die definitie valt.

Alles bij elkaar denk ik dat je met LGPL-code in een objectgeorienteerde taal mag subclassen of erven zonder dat je je eigen code LGPL zou moeten maken bij distributie. Wel moet je ervoor zorgen dat de LGPL code in een aparte JAR of ander soort bestand komt te staan. Ga je copypasten, dan val je buiten de uitzondering in de LGPL.

Arnoud

Waarom hebben licenties altijd zulk moeilijk taalgebruik?

Geplaatst op in Intellectuele rechten, 17 reacties

wtf-stempel.jpgEen lezer vroeg me:

Omdat ik gezeur met softwarelicenties vrij zat ben, ben ik van plan m’n eigen code te publiceren onder de WTFPL (Do What The Fuck You Want To Public License). Ik vraag me alleen af hoe serieus een rechter een licentie als deze zou nemen. Er staan immers geen juridische frases in, en bovendien is er sprake van grof taalgebruik. Loop ik dan een risico als ik die licentie gebruik?

Er is geen regel in de wet die zegt dat een licentiecontract moet voldoen aan welke taaleis dan ook. Zo ongeveer de enige eis is dat de partijen bij het contract kunnen bepalen wat hun rechten en plichten zijn. En je hebt ook niet per se een advocaat, notaris of jurist nodig om een licentiecontract “rechtsgeldig” te krijgen, behalve in een paar héél bijzondere gevallen zoals de koop van een huis.

Er is dus op zich niets tegen een licentie in gewone taal. Ik heb zelf ooit een standaardreglement voor forums gemaakt waar volgens mij ook nauwelijks jargon in staat. Als je echter ál te ludiek bent in je teksten, zou een rechter in theorie kunnen oordelen dat je licentie niet als serieus aanbod bedoeld was.

De Do What The Fuck You Want To Public License (WTFPL) komt neer op:

You just DO WHAT THE FUCK YOU WANT TO.

En inderdaad is dat wel erg kort – hoewel heel veel meer strikt gesproken niet nodig is. Misschien nog een “Don’t FUCKING SUE ME FOR ANYTHING” als disclaimer, maar verder lijkt me intentie en strekking vrij duidelijk: ga je gang met die software en ik wil er niets over horen.

Waarom dan toch vaak dat moeilijke taalgebruik? Tsja, dat is een goeie. Voor een deel is het vaak een kwestie van onbewust jargon gebruiken. In de wandelgangen met collega’s spreek je als jurist eerder van “exoneratie” dan van “beperking van aansprakelijkheid”, en als je niet uitkijkt komt dat ook in de documenten voor je klanten terecht.

Ook speelt mee dat je graag 100% correct wilt formuleren. Als je zegt “ik ga niet programmeren als jij me onbruikbare input geeft”, dan krijg je wellicht discussie over wat “onbruikbaar” is en hoe je dat meet. En wat is “input”? Elke onbegrijpelijke mail? De specificaties? Ook zou je je nu kunnen afvragen of dat niet-aan-de-slag-gaan een verplichting is of alleen maar een recht van de ontwikkelaar. Als je daar als jurist een correcte en dichtgetimmerde formulering van wilt maken, dan krijg je zoiets (artikel 2.3 van de ICT~Office voorwaarden, module Ontwikkeling van programmatuur):

Leverancier is gerechtigd, doch niet verplicht, de juistheid, volledigheid en consistentie van de aan hem ter beschikking gestelde gegevens, specificaties of ontwerpen te onderzoeken en bij constatering van eventuele onvolkomenheden de overeengekomen werkzaamheden op te schorten totdat cliënt de betreffende onvolkomenheden heeft weggenomen.

Ik geef toe, het is minder leesbaar dan “ik ga niet programmeren als jij me onbruikbare input geeft” maar het is wel minder vatbaar voor discussie.

Soms is het helaas meer een kwestie van niet duidelijk kunnen formuleren of niet genoeg weten van de business van de klant om een toegesneden clausule te maken. En dan copypasten we maar het vorige contract want dat zal dan wel goed genoeg zijn.

Arnoud<br/> Foto: mjaysplanet, Flickr.com CC-BY 2.0

Mag mijn school Windows eisen?

Geplaatst op in Intellectuele rechten, 51 reacties

windows-mac-linux.jpgEen lezer vroeg me:

De opleiding die ik momenteel volg maakt gebruik van een Flash applicatie voor de wiskundelessen. Ik gebruik Linux, en daar werkt die applicatie eigenlijk niet goed op. Ik heb verschillende distributies, van Gentoo tot Ubuntu, geprobeerd maar het probleem blijft. Mijn docent geeft echter aan dat ik dat maar te accepteren heb: “Moet je maar gewoon Windows gebruiken”. Dus nu vroeg ik me af, kan ik van de school eisen dat ze hun applicatie crossplatform maken, of kunnen ze mij verplichten een dure Windowslicentie aan te schaffen?

Ik ken geen regels die zeggen dat opleidingen OS-agnostisch moeten zijn. Heel misschien als je indirect benadeeld wordt in een handicap of zo (screenreader die het alleen doet onder MacOS, of braille-apparaat met Linux).

In het algemeen geldt voor zover ik weet dat een onderwijsinstelling zelf mag bepalen welke eisen zij willen stellen aan deelnemers, zolang het maar geen verboden discriminatie oplevert. Als zij eisen dat je een roze sweater draagt, dan zal dat moeten. Willen ze geen leren tassen, dan zul je een geweven rugzak moeten kopen.

Voor software geldt denk ik hetzelfde. Zij hebben bepaalde software, en als jij die vakken wilt volgen dan moet je hun software gebruiken. Dat is denk ik niet anders dan wanneer ze je boeken voorschrijven of een rekenmethode die jou misschien niet ligt (de moderne staartdeling, wtf?). Dat jij liever een ander boek hebt, of dat jouw boeken goedkoper zijn, is geen argument om af te mogen wijken van de verplichte literatuur. En daarom denk ik dat Windows ook voorgeschreven kan worden.

Arnoud

Open source code in patentaanvraag?

Geplaatst op in Intellectuele rechten, 9 reacties

x264.pngEen ontwikkelaar van de open-source video-encoder x264 beschuldigt het bedrijf Tandberg ervan dat zij open-sourcecode heeft gestolen en die nu wil patenteren. Tandberg ontkent. Dat meldde Webwereld gisteren, en Tweakers al zondag. In patentaanvraag WO2010077148 blijkt een algoritme beschreven te worden dat wel héél sterk lijkt op een in 2006 bedacht algoritme voor de open source video encoder x.264.

De overeenkomsten zijn inderdaad zeer opmerkelijk. De indieningsdatum is 2 maanden na de publicatie van de broncode uit de encoder. Er ontbreekt een niet onbelangrijk onderdeeltje in de patentaanvraag – en precies dat onderdeeltje was pas een tijdje later aan de encoder toegevoegd. En volgens de ontwikkelaars was bekend dat Tandberg-mensen meelezen bij hun project. Bij Slashdot zien ze dan ook meteen een complot om heel open source te patenteren. /aluhoedje

Tandberg ontkent alle beschuldigingen en wijst erop dat hun aanvraag toch echt anders is dan de encoder, en dat ze zeker niet meelezen of code overtypen. (Er staat ook geen broncode in de patentaanvraag.) En de ontwikkelaars reageren daar weer op dat dat best zou kunnen; het algoritme uit de patentaanvraag is volgens hen zó triviaal dat je er toch geen patent op moet kunnen krijgen.

Hoe nu verder? Het literatuuronderzoek van WIPO noemt deze prior art niet, maar na al deze heisa een mogelijke octrooiverlenende instantie mogelijk wel. Of Tandberg besluit zelf de aanvraag in te trekken, dat kan ook altijd.

Webwereld meldt nog deze aperte onzin:

De x264 projectgroep kan overigens nog wel bezwaar indienen tegen het patent bij de World Intellectual Property Organization. Die organisatie kan de patentaanvraag ongeldig verklaren als blijkt dat het algoritme van Tandberg inderdaad te veel overeenkomt met het open-source algoritme.

Die mogelijkheid bestaat juridisch eenvoudigweg niet. Het WIPO publiceert internationale octrooiaanvragen en publiceert een literatuuronderzoek, meer niet. Wie echt een octrooi wil, moet daarna naar de octrooiraden van de landen waar hij dat octrooi wil. En die kunnen eventueel de bezwaren van de x.264 groep in behandeling nemen.

Arnoud

Waarom zou je willen dat opensourcelicenties niet rechtsgeldig zijn?

Geplaatst op in Intellectuele rechten, 25 reacties

Naar aanleiding van mijn bericht over die Belgische Creativecommonsrechtszaak kreeg ik de volgende vraag van een lezer:

Waarom maken jullie juristen er eigenlijk altijd zo’n punt van of die licenties wel rechtsgeldig zijn? Als ze niet rechtsgeldig zouden zijn, dan mag je op grond van het auteursrecht helemaal niets met het werk. Dus waarom zou iemand in vredesnaam willen betogen dat open source of Creative Commons geen geldige licenties zijn?

Tsja, sommige juristen vinden het nu eenmaal leuk om gaten te schieten in juridische documenten, puur omdat het kan. En vanuit academisch oogpunt is het ook wel een leuke vraag: kan dat eigenlijk wel, aansprakelijkheid uitsluiten in een licentieovereenkomst die door een consument-wederpartij wordt gesloten? En mag in België of Frans-Canada een Engelstalige licentie worden gesloten, of moet er een Franse vertaling bij zitten?

In de praktijk zie ik het niet gebeuren dat iemand gaat betogen dat de GPL of een andere opensource- dan wel Creativecommonslicentie als zodanig niet rechtsgeldig is en dus in zijn geheel vernietigd moet worden. Daar schiet je inderdaad bar weinig mee op, want dan heb je geen licentie meer en dan kan de rechthebbende het hele auteursrechtelijk arsenaal loslaten: van volledige proceskostenvergoeding tot beslaglegging en ex parte verboden.

Wat wél in de praktijk relevant kan zijn, is een betoog dat een specifieke clausule ongeldig is. Als dat namelijk geaccepteerd wordt, dan is er de mogelijkheid dat de rechter die specifieke clausule vernietigt. De licentie als geheel blijft bestaan, maar die clausule moet je dan wegdenken uit de tekst. Je ziet dit vaak bij algemene voorwaarden. Een voorwaarde die “onredelijk bezwarend” is, kan worden vernietigd, maar daarmee is niet het hele contract ongeldig verklaard.

En dat biedt perspectieven. Je zou bijvoorbeeld de aansprakelijkheidsclausule kunnen aanvechten, en daarna de leverancier van de opensourcesoftware aansprakelijk stellen voor schade door bugs in zijn software. Of, nog leuker: de “GelijkDelen” of copyleftclausule aanvechten en daarmee voorkomen dat je je eigen werk ook open source (of Creative Commons) zou moeten maken. Dus niet een discussie over of iets nu wel of niet een bewerking (“afgeleid werk”) is, maar een discussie dat het onredelijk of tegen de wet is dat men überhaupt mag eisen mag stellen aan bewerkingen.

Of dat laatste succesvol is, betwijfel ik ten zeerste. Ik kan eigenlijk geen reden bedenken waarom het onredelijk zou zijn dat een leverancier eist dat bewerkte versies van zijn software onder dezelfde licentie geplaatst moeten worden. Ok, intellectueel eigendom is heilig, maar dat argument geldt net zo hard voor de software wiens licentie je aanvecht. Er zijn wel een paar pogingen geweest, maar die zijn nauwelijks serieus te noemen.

Het zal dus wel nieuwigheid zijn: we kennen dat Creative Commons niet, dus het zal mogelijk niet rechtsgeldig zijn.

Arnoud

Creative Commons ook in België rechtsgeldig

Geplaatst op in Intellectuele rechten, 13 reacties

dogmazic-logo.pngOok Belgische rechters hebben weinig moeite met Creative Commons, meldde TechnoLlama gisteren. Een groep muzikanten had hun werk op de vrijemuzieksite dogmazic gezet onder de Creative-Commonslicentie Naamsvermelding-Geen Afgeleide Werken-Niet Commercieel. Enige tijd later bleek dat een commercieel festival deze muziek had gebruikt in een reclame. Men stapte naar de Nijvelse rechter, en die gaf de band gelijk.

In het Franstalige vonnis wordt geen seconde getwijfeld of Creative-Commonslicenties wel rechtsgeldig zijn: het is een licentie, daar staan voorwaarden in en daar moet je je aan houden. (Wel lijkt de rechtbank een beetje verbaasd te zijn dat de muzikanten niet bij Sabam zitten.)

Men verwijst expliciet naar het vonnis dat Adam Curry ooit tegen de Weekend kreeg, plus naar Spaanse en Amerikaanse rechtbanken die ook de rechtsgeldigheid van Creative Commons zouden hebben erkend. Ik vermoed dat het Amerikaanse vonnis stiekem gaat over open source (Jacobsen/Katzer), maar ik heb geen idee om welk Spaans vonnis het zou gaan. Wie helpt?

De licentievoorwaarden waren duidelijk op de website vermeld, dus de organisator had moeten weten dat ze gelden, aldus de rechtbank. Men had nog als verweer opgeworpen dat er een foutje was gemaakt: de hoofdpagina van die site vermeldt “Naamsvermelding-GelijkDelen” dus men was er vanuit gegaan dat dit ook voor alle content geldt. Maar daar gaat de rechtbank niet in mee. Een professionele organisatie heeft de plicht te onderzoeken welke voorwaarden precies gelden, oftewel die had moeten doorklikken. (Precies zoals ook Weekend te horen kreeg bij Curry.)

De rechtbank worstelt -wederom net als bij Curry/Weekend- met de vraag welke schadevergoeding moet worden toegekend. Immers wie zijn muziek gratis weggeeft, kan achteraf moeilijk zeggen dat hij licentievergoedingen heeft gemist. Hoewel je in het geval van een “NietCommercieel”-licentie zou kunnen zeggen dat er ruimte moet zijn voor betaalde licenties voor commercieel gebruik. Men schat de schade dan maar op 1500 euro per geschonden voorwaarde, oftewel 4500 euro. Dit onder het motto “we moeten iets”.

Oh ja, en dit is het betreffende nummer. Veel luisterplezier!

Arnoud

Schendt HTC de GPL door broncode vertraagd te publiceren?

Geplaatst op in Intellectuele rechten, 29 reacties

Een lezer wees me (dank!) op een bericht bij Freedom to Tinker waar werd gesignaleerd dat de Android-gebaseerde HTC smartphone Linux draait, maar de broncode maar moeizaam beschikbaar komt. Linux is open source (GPL versie 2) en de broncode moet dus meegeleverd worden (of er moet een schriftelijk aanbod bij zitten waar staat waar je de broncode kunt bestellen). Ene “vladyman” had HTC gevraagd hoe dit zit, en kreeg als antwoord:

Thank you for contacting HTC Technical Assistance Center. HTC will typically publish on developer.htc.com the Kernel open source code for recently released devices as soon as possible. HTC will normally publish this within 90 to 120 days. This time frame is within the requirements of the open source community.

Nou, dat lijkt me niet. Ik heb nog nooit gehoord van een tijdsbestek van 90 tot 120 dagen voordat broncodes beschikbaar komen. De GPL zelf bevat zo’n vertragingsmechanisme al helemaal niet: de broncode moet gewoon bij het product zitten.

Er zijn verschillende verklaringen waarom HTC zo reageert: ze hebben de juiste broncodes niet paraat, er zitten codes van derden in die (nog) geen GPL mogen worden, men is naar de verkeerde cursus open source compliance geweest of men werkt gewoon altijd al zo en dus nu ook, want wetten en regels kunnen natuurlijk niet het bedrijfsbeleid in de weg zitten. Of, en dan wordt het wat meer aluhoedje: men is bang dat afgifte van de broncode zal leiden tot een succesvolle jailbreak van de telefoon.

Het blijkt namelijk dat de HTC G2 wel te jailbreaken is, maar tot nu toe levert dat slechts beperkte resultaten op. De meeste hacks worden bij de eerstvolgende reset ongedaan gemaakt door een speciaal stukje firmware. Vanuit Linux zou dat stukje firmware aan te sturen moeten zijn, maar daarvoor is wel de broncode van de Linux-kernel in het apparaat nodig. En die komt “normaliter” pas na 90 tot 120 dagen beschikbaar.

Frustrerend is wel dat eigenlijk alleen de auteursrechthebbenden op de Linuxkernel hier wat tegen kunnen doen. Als ontvanger van de code kun je je niet op de GPL beroepen tegenover HTC (of T-Mobile, die het toestel uiteindelijk aan je levert) want de GPL is een licentie tussen jou en de auteursrechthebbende, niet tussen jou en T-Mobile. Ik heb me wel eens afgevraagd of het geen goed idee zou zijn om juist wél toe te staan dat jij mag procederen uit naam van Linus over jouw exemplaar van Linux.

Update (15 oktober) in de comments wijst Piet erop dat HTC de code ruim binnen die 90 dagen heeft vrijgegeven.

Arnoud

Opensourcebibliotheek Glibc nu eindelijk open source

Geplaatst op in Intellectuele rechten, 15 reacties

gnu-c-library-glibc-software-library-bibliotheek-linken.pngOpmerkelijk: de basisbouwsteen van vrijwel alle open source blijkt nooit 100% open source te zijn geweest. Pas vorige week is de GNU C Library (glibc), de standaardbibliotheek voor Linuxapplicaties, ontdaan van een stukje antieke code die voorzien was van een licentie die niet voldeed aan de definitie van open source.

Glibc is een onderdeel van Linux dat door vrijwel elke applicatie wordt gebruikt. Deze bibliotheek implementeert alle standaardfuncties uit de programmeertaal C. De licentie is de Lesser GPL, die toestaat om applicaties te maken zonder dat die zelf ook weer open source moeten worden. Maar enkele jaren terug werd ontdekt dat er code in zat die stiekem eigenlijk niet open source was.

Nu was die code uit 1984, toen het hele idee van open source nog niet bestond. De bedrijfsjuristen van Sun Microsystems, die de code had uitgebracht, hadden dan ook hun eigen tekst verzonnen die op zich best liberaal en netjes was:

Sun RPC is a product of Sun Microsystems, Inc. and is provided for unrestricted use provided that this legend is included on all tape media and as a part of the software program in whole or part. Users may copy or modify Sun RPC without charge, but are not authorized to license or distribute it to anyone else except as part of a product or program developed by the user.

(inderdaad, tape media)

Het stukje in italics leverde het pijnpunt op: open source moet op elke mogelijke manier kunnen worden hergebruikt, niet alleen als onderdeel van een groter product. Omdat je dit stukje code van Sun niet op zichzelf mag doorverkopen, is het geen open source, en het kan dan dus ook niet opgenomen worden in glibc.

Dat is best wel een probleem voor zo’n belangrijk en essentieel stuk software. Oplossen is echter lastiger dan je zou denken, zoals Simon Phipps aangeeft, want:

  1. Waar komt de code vandaan?
  2. Wie heeft deze geschreven, en was die persoon in dienst bij het bedrijf of een leverancier of inhuurkracht?
  3. Wie is tegenwoordig verantwoordelijk voor deze code en mag beslissen dat deze open source wordt?

In dit specifieke geval was de uploader Sun nog wel te vinden, maar moest er in een papieren archief worden gedoken om te achterhalen waar de rechten lagen. En dat werd nog eens extra moeilijk omdat de nieuwe eigenaar van Sun (Oracle) druk bezig was met afhandelen van de aankoop en alle juristen in de “geen commentaar”-modus zaten.

Alles bij elkaar duurde het meer dan een jaar om de wijziging door te voeren. Maar het ís gelukt, en dat is wel een complimentje waard.

Arnoud<br/> Foto: GNU C Library handleiding, Free Software Foundation.

Apple App Store voorwaarden botsen met GNU GPL

Geplaatst op in Intellectuele rechten, 20 reacties

apple-app-store.pngApple weigert een GPL-gelicentieerde app voor het spel Go in haar App Store op te nemen. De Free Software Foundation heeft met Apple overlegd over hoe GPL-software kan worden gedistribueerd via de App Store van Apple, las ik bij Webwereld. De GPL-voorwaarden zouden incompatibel zijn met de eisen die Apple oplegt. Het nieuws is al wat ouder, maar vakantie is er om oud nieuws in te halen, niet?

Het gaat volgens de vrijesoftwarejongens vooral om het artikel uit de App Store-voorwaarden dat zegt dat je de software op maximaal vijf apparaten mag installeren. Dat is een probleem voor de GPL: die eist dat iedere ontvanger het recht krijgt om de software zo veel & vaak als men wil te installeren en verder te verspreiden.

Ars Technica wijst er echter op dat de EULA van Apple een specifieke uitzondering voor open source bevat:

You may not copy (except as expressly permitted by this license and the Usage Rules), decompile, reverse engineer, disassemble, attempt to derive the source code of, modify, or create derivative works of the Licensed Application, any updates, or any part thereof (except as and only to the extent any foregoing restriction is prohibited by applicable law or to the extent as may be permitted by the licensing terms governing use of any open sourced components included with the Licensed Application).

Vertaling: er mag niets tenzij wij zeggen van wel – behalve als er een opensourcelicentie op de software zet, want dan moet u daar lezen wat er mag.

Maar daar zet de FSF weer tegenover dat elders staat

The Usage Rules shall govern your rights with respect to the Products, in addition to any other terms or rules that may have been established between you and another party.

Oftewel: oh ja, maar ondanks dat gelden onze gewone regels toch boven alles.

Persoonlijk lijkt dit me een al te strikte lezing van de Apple EULA, maar goed, formeel staat het er inderdaad.

Arnoud