Tag: Open source

About Open source

Subscribe Feeds

Hoe kan ik een opensourcemodule opnieuw implementeren?

Geplaatst op in Intellectuele rechten, 18 reacties

software-disc-cd-dvd-dragerEen 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 inbreuk?

Auteursrecht rust alleen op code zelf. Op functionaliteit of ideeën kun je geen auteursrecht claimen. Als persoon A een module van persoon B opnieuw implementeert zonder naar B’s code te kijken, dan heeft hij geen auteursrecht geschonden. Dit bewijzen is natuurlijk erg ingewikkeld als B’s code vrij op internet staat. Bewijs maar eens dat je die niet gezien hebt.

Mogelijk is er een beter argument. Als het écht zo is dat er maar één manier is om deze code te schrijven, dan kan er geen auteursrecht op rusten. Auteursrecht vereist creativiteit, en die kan niet bestaan als er maar één route is. Ik twijfel wel of het echt zo werkt. Vrijwel altijd zijn er alternatieven waaruit je kunt kiezen bij het schrijven van software. Al is het maar of een while() lus handiger is dan for() of dat je beter iets in een functie kunt stoppen.

Terug bij af dus. Bewijs maar dat je B’s code niet gezien hebt en er dus niet uit gekopieerd. Dat zal niet meevallen. De standaardtruc is clean room reverse engineering, maar dat werkt niet bij open source.

De enige optie denk ik is dat je heel veel tussentijdse versies publiceert om zo te laten zien dat je van nul bent begonnen met die module. Zeg maar elke keer met tien regels code erbij. Dan bewijs je dat je van nul af zelf schreef en dan heb je dus niet gekopieerd. Het lijkt me wel een heel gedoe.

Arnoud

Open source als schild tegen patentaanvallen?

Geplaatst op in Intellectuele rechten, 35 reacties

hardware-software-computer-gollem-huh.jpgOpen source kan een schild zijn tegen patentaanvallen, las ik in deze Amerikaanse blog. Nu het zeker in de VS steeds populairder wordt om alles en iedereen aan te klagen met een octrooi, is het een goed idee eens na te gaan denken wat je kunt doen mocht zo’n claim op jouw bureau landen. En voor bedrijven die met open source actief zijn, is er een leuke truc: die patenthouder gebruikt ongetwijfeld open source, en schendt met grote waarschijnlijkheid de licentie. Want die uitspraak is namelijk voor vrijwel ieder bedrijf waar.

Mooie quote uit de blog:

Patent lawyers may be surprised to know that while today, most companies today use open source software, most of them struggle greatly with implementing the internal controls to coordinate their use of open source software with their patent portfolio management.

Dat is een héél nette manier van zeggen “de meeste bedrijven gebruiken gewoon open source, en niemand vraagt de bedrijfsjurist of patentafdeling of dat nog speciale consequenties heeft”. Wat overigens ook mijn ervaring is bij de meeste bedrijven die ik tegenkom en “iets met open source” zeggen te doen. (ADV: bent u nu een bezorgde bedrijfsjurist? Volg dan onze juristentraining Open source) Het leukste vind ik nog als er keihard bedrijfsbeleid is “wij gebruiken geen open source zonder schriftelijke toestemming van de CEO/bedrijfsjurist” en ondertussen de kernproducten of -diensten vrolijk op Linux draaien.

In het specifieke geval waar blogger Heather Meeker het over heeft, komt dit gerommel goed uit: de octrooihouder die bij jou een claim indiende, heeft er waarschijnlijk óók een potje van gemaakt. Dus ga even zoeken en je komt vast een opensourceinstallatie tegen in een van zijn producten. Met een beetje geluk betreft dat een regel code van jou, of van iemand die je kent en die best bereid is samen te werken met een tegenclaim op basis van auteursrechtschending.

Natuurlijk, het is een gok, maar een beredeneerde: over het algemeen zijn het concurrenten die elkaar beprocederen, en concurrenten die iets met open source doen, zullen al snel bij dezelfde categorie software uitkomen. Dus een goede kans dat de producten qua basissoftware overlappen.

Ook een mogelijkheid is om via de open source licentie van de software die zij gebruiken, een tegenclaim op tafel te leggen. Veel open source licenties vermelden namelijk expliciet dat je de software wel mag gebruiken, maar dan andere gebruikers niet meer lastig mag vallen met een patent waar die open source inbreuk op maakt. Wel vereist dit dat je als patentgedaagde inbreuk pleegt via die open source. Die patentlicentie uit de open source licentie geldt immers alleen bij gebruik van die open source zelf.

Helaas is dit middel geen remedie tegen de vele patenttrollen die er rondlopen. Een patenttrol is per definitie een partij die zelf niets doet (behalve procederen en geld eisen), dus daar zul je geen producten of diensten vinden waar open source in zit. Een tegenclaim is er dus niet te brouwen. Meer dan in de octrooiwet opnemen dat je alleen een verbod mag gaan halen bij de rechter als je zélf met een product op de markt bent, kan ik niet bedenken tegen dit fenomeen.

Arnoud

Een medewerker heeft onze software ge-opensourcet, wat nu?

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 38 reacties

Een lezer vroeg me:

Wij zijn een klein softwarebedrijf dat snel wil groeien, dus we hebben recent een aantal mensen aangenomen. Nu blijkt eentje daarvan in zijn vrije tijd aan een opensourceproject te werken. Op zich prima, alleen brengt hij code in dat project die hij voor zijn werk geschreven heeft. Hij zegt dat het standaardcode is en dat we er alleen maar baat bij hebben, maar volgens mij bepaal ik nog altijd wat wij hier open sourcen. Wat kan ik nu doen?

Een werknemer kan inderdaad niet zelfstandig besluiten dat software die eigendom is van de werkgever, onder een opensourcelicentie beschikbaar mag zijn voor derden. Dat is een bedrijfsbeslissing. En als het bedrijf daarin volgens de werknemer de verkeerde beslissing neemt, dan heb je dat als werknemer te accepteren.

Hier is het duidelijk dat de code van de werkgever is, de software is voor het werk geschreven. Maar er zijn genoeg situaties met twijfelgevallen: het is niet letterlijk dezelfde code, maar men schrijft gelijksoortige code in eigen tijd. Of men schrijft volledig eigen code maar wel aan een project dat werkgerelateerd is. Een webbouwer die in zijn vrije tijd PHP modules ontwikkelt bijvoorbeeld. Dan kom je in de discussie of het werk binnen het kader van het dienstverband valt of niet. En dat is geen kwestie van “het was na 17 uur gemaakt” of “ik gebruikte mijn privélaptop”.

Goed, dus de code is van de werkgever. In principe kan deze nu gewoon naar het opensourceproject stappen en eisen dat deze de code verwijdert. Het project gebruikt de code immers zonder toestemming van de rechthebbende, inbreuk op auteursrecht dus.

Of niet? Het project zou kunnen zeggen, wij mochten erop vertrouwen dat deze werknemer gemachtigd was dit te doen. De wet kent namelijk een beschermingsconstructie voor situaties als deze. Als de werkgever de indruk heeft gewekt bij het project dat de werknemer dit mocht, dan zegt 3:61 BW dat het bedrijf gebonden is aan de licentie, ook als in feite de werknemer niet gemachtigd was dat te doen.

Wat kan zo’n indruk nu opwekken? Enkel dat de werknemer het doet, lijkt me niet genoeg. Een verklaring op de site van het bedrijf dat men open source steunt en belangrijk vindt in combinatie met gebruik van het zakelijke mailadres van de werknemer, dat zou ik wel een moeilijke vinden om te weerleggen. Dat het bedrijf het opensourcepakket (met werknemersbijdragen) zelf in producten stopt, lijkt me ook wel een overtuigend verhaal.

Los daarvan kun je je afvragen of je echt een discussie moet starten bij het opensourceproject. Dat gaat een hoop gedoe en negatieve PR opleveren. Is dat je code echt waard?

Arnoud<br/> PS meer weten over open source? Volg ons webinar open source de 28e.

Spionagemalware Duqu schendt GPL

Geplaatst op in Intellectuele rechten, Iusmentis, 25 reacties

duqu-gpl.pngSjongejongejonge, 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 ergens wel grappig om te denken dat malwaremakers die economische spionage en mogelijk zelfs hardwarevernielingen gaan veroorzaken een opensourcelicentie zullen respecteren. Gelukkig dus maar dat er “This post is for fun, don’t take it too seriously,” bij staat.

En dan maar doorpakken op een stukje irritatie van mij: je kunt in situaties als deze de GPL niet schenden, want de GPL is niet bindend als je je er niet aan houdt. Je pleegt auteursrechtinbreuk, natuurlijk, maar eisen dat iemand de GPL naleeft is onmogelijk. Tenzij iemand gezégd heeft de GPL te willen naleven en vervolgens dat blijkt niet te doen.

In maart hadden we nog een discussie over GPL bij tablets, waarbij de discussie was of je als koper de GPL kon afdwingen. Dat kan (via een derde-begunstigde discussie) maar wél moet dan eerst vaststaan dat de verkoper zich aan de GPL heeft gebonden.

Het enkele feit dat iemand GPL-licensed code verspreidt, is nog geen bewijs dat hij zich aan de GPL heeft geconformeerd.

Arnoud

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

Geplaatst op in Intellectuele rechten, 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. Hun antwoord :dat geld niet voor onze producten en nu doen we geen verdere mededelingen…. dus misschien moet iedereen in het bezit van een tomtec of xiron tablet eens gaan mailen met de vraag of ze de source van kernel mogen hebben.

De TomTec tablet draait Android, oftewel Linux. Linux valt onder de GPL, en in die opensourcelicentie staat de eis dat ontvangers van de software de broncode erbij moeten krijgen. Wie de broncode niet meteen kan of wil leveren, mag ook een schriftelijk aanbod tot nazending bijsluiten, maar je moet de broncode kunnen krijgen.

Tomtec lijkt dit niet te doen, en of het nu uit onwetendheid, koppigheid of een taalprobleem is: het is een schending van de licentie. De Linux-kernelcopyrighthouders kunnen dus Tomtec aanspreken op schending van de GPL, en op grond van hun auteursrecht al deze apparaten van de markt laten halen. Want volgens artikel 28 Auteurswet mag de rechthebbende roerende zaken (zoals tablets) die het auteursrecht schenden (Linux aan boord hebben zonder de GPL na te leven) als zijn eigendom opeisen dan wel onttrekking aan het verkeer, vernietiging of onbruikbaarmaking daarvan vorderen. Dat is nogal een paardenmiddel, en ik zie de Linuxkerneljongens ook niet snel zo’n actie starten.

Interessanter is de vraag: kun je als ontvanger iets juridisch doen om de broncode te krijgen?

De GPL is een licentie, en daarmee een contract (ja echt) tussen de auteursrechthebbenden en de verspreider, de Linuxkerneljongens en Tomtec dus in dit geval. (Of de Bart Smit? Die is immers de directe leverancier van de koper van het apparaat.) De ontvanger van de code is geen partij bij dit contract. Wanneer hij de code heeft ontvangen, geldt voor hem dit artikel:

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.

De ontvanger sluit dus op dat moment een eigen contract met de rechthebbende, en kan op die grond de software gebruiken, aanpassen en/of verspreiden. Maar dat contract staat los van het contract dat zijn toeleverancier heeft met de auteursrechthebbende.

We hebben in Nederland een regel over “derde-begunstigden”: mensen die geen partij zijn bij een contract maar er wel profijt van trekken. Artikel 6:253 BW zegt daarover:

Een overeenkomst schept voor een derde het recht een prestatie van een der partijen te vorderen of op andere wijze jegens een van hen een beroep op de overeenkomst te doen, indien de overeenkomst een beding van die strekking inhoudt en de derde dit beding aanvaardt.

Professor Hijma noemt het voorbeeld van de koper die TNT Post kan aanspreken op levering, hoewel TNT Post formeel alleen een contract met de verkoper heeft. De koper is een derde, maar omdat de contractuele afspraak tot levering hem raakt, kan hij er een beroep op doen. Wel moet de koper dan formeel eerst tegen de post zeggen dat hij zich wil beroepen op dit beding.

De ontvanger van de Tomtec tablet is de derde in de zin van dit wetsartikel. En er stáát in de GPL een verplichting voor een der partijen om een prestatie te leveren naar de derde toe, namelijk het (na)leveren van de broncode. Dus als de ontvanger nu tegen zijn leverancier zegt “ik accepteer bij deze de GPL zoals van toepassing op de Linuxkernel in uw apparaat en ik sommeer bij deze meteen uw nakoming van artikel 3 GPL” dan wordt de ontvanger daarmee partij bij de overeenkomst (de GPL)

De ontvanger kan vervolgens naar de rechter om die nakoming af te dwingen, graag op straffe van een dwangsom zodat het ook echt gebeurt. Maar de ontvanger kan géén auteursrechtelijke bevoegdheden uitoefenen, hij heeft uitsluitend en alleen contractuele rechten richting de leverancier.

Arnoud

Zijn WordPress themes GPL?

Geplaatst op in Intellectuele rechten, 10 reacties

wordpress-bible.pngEen 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 worden. Eerst wilde Thesis dat niet, maar na na flink wat discussie hebben ze het uiteindelijk toch GPL gemaakt. Maar had dat nou echt gemoeten?

De open source licentie GPL eist dat “afgeleide werken”, bij ons “verveelvoudigingen in gewijzigde vorm” van hun code alleen maar verspreid mag worden onder diezelfde GPL. Je kunt geen afgeleid werk verspreiden onder een andere licentie. (Maar je hóeft je code niet te distribueren als je dat niet wil; wie dus voor zichzelf GPL code aanpast hoeft niets te delen.)

De vraag wat een afgeleid werk precies is, is al zo oud als de GPL zelf. De discussie over plugins op GPL code hebben we al een paar keer gehad, maar die voor themes nog niet.

Een theme is voor mij net wat anders dan een plugin. Een plugin is nieuwe code die inhaakt op de originele code, en de functionaliteit daarvan uitbreidt. Ik denk dat je een plugin dan ook wel als een afgeleid werk kunt zien, hoewel er in de GPL een uitzondering staat voor

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.

WordPress vindt dat dit een uitgemaakte zaak is: WordPress extensies en themes zijn altijd afgeleid van WordPress zelf, hoewel ze qua onderbouwing niet verder komen dan “Drupal zegt het veel beter dan wij” en Drupal niet meer zegt dan “Ja dat is zo”.

Als je kijkt naar hoe themes gebouwd worden, dan zie je dat ze een vrij standaard structuur volgen om de layout te definiëren en op bepaalde punten routines uit WordPress aanroepen (“plak hier de titel van de blog”, “doe dit voor tien blogberichten”, “zet hier de datum, in formaat mm-dd-jj”) zodat de bezoeker de juiste informatie in de juiste layout te zien krijgt. Ik zie niet hoe je dat kunt zien als een verveelvoudiging van de WordPress-code zelf. Het aanroepen van een functie maakt je code nog niet “afgeleid”.

Daar komt bij dat eind vorig jaar het Europese Hof van Justitie bepaalde dat user interfaces géén deel zijn van de copyright op de software zelf (en een theme is de realisatie van een interface). Toegegeven, dat ging over de vraag of het kopiëren van de interface een auteursrechtschending was, maar als het auteursrecht op de software zich niet uitstrekt tot de interface, waarom zou het dan wél gelden voor andermans interface?

Ik denk dan ook dat je pas van een afgeleid werk kunt spreken als de theme code kopieert of diep ingrijpt in WordPress zelf, bijvoorbeeld door het vervangen van core code. Een ‘gewoon’ theme is geen afgeleid werk.

Arnoud

Hoe kan ik sommig commercieel gebruik toestaan bij Creative-Commonslicenties?

Geplaatst op in Intellectuele rechten, 10 reacties

Een lezer vroeg me:

Ik ben fotograaf en maak portretfoto’s. Nu had ik het idee om een dienst aan te bieden waarbij je gratis een portretfoto kunt maken, onder de Creative-Commonslicentie Naamsvermelding-NietCommercieel-GeenAfgeleideWerken (BY-NC-ND). Zo kunnen mensen als privépersoon een mooie foto publiceren op hun Facebookpagina en krijg ik naamsbekendheid. Willen mensen die foto commercieel gebruiken, dan moeten ze apart komen betalen.

Nu liep ik tegen één probleem aan: wat nu als mensen die foto op een bedrijfswebsite zetten of aan hun Linkedin- of Plaxo-profiel koppelen? Dat zijn immers zakelijke netwerken. Is dan sprake van ‘commercieel gebruik’? Hoe kan ik aangeven dat dat wel mag (met mijn naamsvermelding natuurlijk) zonder meteen ál het commercieel gebruik toe te staan?

Creative Commons is een set standaardlicenties waarmee je kunt aangeven dat mensen je werk mogen gebruiken, behoudens enkele uitzonderingen Auteursrecht zoals het zou moeten werken dus. Omdat het standaardlicenties zijn, zijn de regels zwartwit en is het niet mogelijk om eigen uitzonderingen toe te voegen.

Speciaal voor commercieel gebruik betekent dat dat je alleen mag kiezen of dat wél of niet mag, maar niet welke vormen van commercieel wel of niet mogen. Je mag bijvoorbeeld niet zeggen dat een goed doel je foto wél mag gebruiken voor een wervingscampagne maar een bedrijf niet in zijn advertentiecampagnes. Beide campagnes zijn gericht op “financieel gewin” en dat is de definitie van “commercieel”. Dus of beiden mogen, of geen van beiden.

Een oplossing die soms werkt, is toelichten hoe je een bepaald twijfelgeval interpreteert. Zo’n toelichting is formeel geen deel van de licentie, maar hij kan wel tegen je worden gebruikt want hij bewijst hoe jij het licentiecontract interpreteerde. En daar mag de wederpartij je dan aan houden.

Je zou dus kunnen zeggen “Ik vind het gebruik van een portretfoto op een profielpagina geen ‘gebruik voor direct of indirect geldelijk gewin’ zolang geen geld wordt gevraagd voor het bekijken, publiceren of kopiëren van de foto.” Dit is een verduidelijking van het verbod, en deze gaat niet in tegen de tekst van het verbod zelf. Dat is dus prima.

Natuurlijk zitten hier grenzen. Een uitzondering als “ik vind het maximaal 50 euro vragen voor een kopie geen commercieel gebruik” gaat natuurlijk niet werken, want die tekst spreekt de definitie van ‘commercieel’ tegen. Geld vragen voor een kopie is zó evident commercieel dat je dat niet met een uitzondering opzij kunt zetten.

Arnoud

Is de export van sterke cryptografie nog steeds verboden?

Geplaatst op in Intellectuele rechten, Security, 9 reacties

one-team-jabber-chat1.pngEen lezer stelde me een vraag over chatclient Jabber. Hij gebruikt deze op het werk inclusief de feature van end-to-end encryptie: OTR. Voor de iPad en iPhone is ook een Jabber-client beschikbaar, OneTeam geheten. Deze had echter geen encryptie. Op zijn verzoek of dat binnenkort dan opgenomen zou worden, reageerde het bedrijf met:

Chances to get encryption in OneTeam on iOS are very low, as we would have to ask permission to US government (as requested by Apple). This is a hassle we would like to avoid.

De vraag is natuurlijk, wat heeft de Amerikaanse regering te maken met encryptie op je iPhone?

In eerste instantie niet per se heel veel, maar Apple voelt zich als Amerikaans bedrijf geroepen de Amerikaanse wet te handhaven. Daarom staat in de voorwaarden voor app-developers dat zij bij gebruik van encryptie moeten bewijzen dat het Ministerie van Handel de export van deze technologie heeft goedgekeurd. Dat proces is een heel gedoe, maar het kan wel.

Deze regels gelden ook voor andere besturingssystemen en software, alleen wordt daar niet heel hard op gelet. Maar reken maar dat Microsoft keurig toestemming heeft gevraagd alvorens Windows met encryptie aan boord uit te leveren.

Vroeger waren er heel strenge regels over encryptie: je mocht als Amerikaan geen sterke encryptie naar buiten het land exporteren, wat inhield dat een sleutel bijvoorbeeld maar 40 bits lang mocht zijn (en niet de 128 bits die het zou moeten zijn om veilig te zijn). Dat geldt niet meer, er is alleen nog een verbod op export naar Libië, Iran en die landen. Voor de rest geldt een meldingsplicht en een paar beperkingen.

Voor open source is ook dat nog een probleem, want je hebt geen idee waar je software naartoe gaat dus je kunt niet garanderen dat de software niet naar Iran zal gaan. Daarom is er een uitzondering in de export control wetgeving opgenomen (art. 740.13 e-CFR), die zegt dat software in broncodevorm die publiek op internet downloadbaar is niet onder de strenge wetgeving valt.

Dat is volstrekt onlogisch gezien doel van de wet maar wel handig voor open source: wie producten met encryptie verkoopt, moet nagaan wie de klanten zijn en goedkeuring voor export hebben, maar wie het gratis op internet zet hoeft dat allemaal niet. Je moet alleen melden dat je cryptografische open source op internet hebt gezet.

In Europa geldt geen eis van melding. Wel is het verboden encryptie opzettelijk te exporteren naar landen als Libië, Noord-Korea of Iran. Want ja, encryptietechnologie wordt nog steeds gelijkgeschakeld met wapens en munitie.

Arnoud

Zitten fabrikanten Android zonder GPL-distributierecht voor Linux?

Geplaatst op in Intellectuele rechten, 19 reacties

android-open-source.pngOmdat 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, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.

Op zich geen gekke clausule: je moet je aan de licentie houden, en doe je dat niet dan vervalt de licentie en mag je helemaal niks meer.

Mueller’s zorg is gebaseerd op de boude statement dat “virtually every Android OEM … was out of compliance at some point”, oftewel iedereen die Android uitlevert heeft ooit wel een keer een hoekje van de GPL geschonden en is daarmee zijn licentie kwijtgeraakt. Waar hij dit op baseert, weet ik niet. Het gaat me wat ver om te zeggen “iedereen zal wel een keer de licentie geschonden hebben”, hoewel het me zou verbazen als de meerderheid van Android-leveranciers zich perfect aan de GPL houdt.

De lastige consequentie van de GPL schenden is wel dat je het distributierecht kwijt bent totdat je van alle relevante auteursrechthebbenden hernieuwde toestemming hebt gekregen. Dat zegt in ieder geval de Sofware Freedom Law Center, de handhaver van de GPL. En bij Linux is het zo goed als onmogelijk die toestemming te vragen, want er zijn honderden zo niet duizenden auteurs met minstens één regel creativiteit in de Linuxkernel.

Dit principe is echter nog nooit bij de rechter getest, en eerlijk gezegd gaat het me wel érg ver. Volgens mij kun je gewoon opnieuw de Linuxkernel downloaden, en dan krijg je daar een nieuwe licentie bij. Die nieuwe licentieverlening staat los van je eerdere schending. En als dat al te bijdehand klinkt: wacht dan eventjes tot er een nieuwe major release uit is en ga dan netjes daarmee werken. Ik kan me níet voorstellen dat een rechter zal zeggen “u had de licentie op versie 2.3.12 geschonden, dus versie 2.6 mag u niet gebruiken”. Die twee licenties zijn weliswaar inhoudelijk identiek maar gaan over duidelijk verschillende programma’s.

Oh, en open source is nu echt mainstream: GPL-licentieruzies halen Nu.nl.

Arnoud

Open source licenties in de codering

Geplaatst op in Intellectuele rechten, 10 reacties

plaatje-it-purple-pigeon.jpgAls je afspreekt dat je software alleen mag verspreiden in versleutelde vorm, maar er zit open source in, schend je dan de licentie door toch broncode vrij te geven? Jaja, het lijkt er zowaar op dat we een vonnis hebben over de ‘virale’ werking van open source. Maar dat valt vies tegen: de rechtbank doet geen uitspraak (via) over de bindendheid van de ‘open licenties’ omdat de licentienemer deze er eenvoudig uit had kunnen slopen.

Het bedrijf Purple Pigeon had software (‘Eigen Chatbox’, ‘WebAgenda Multi-User’, ‘WebEnquete PRO’, ‘Web to Go Personal’ en ‘Web To Go Professional’) ontwikkeld, en met Quinarx een exclusieve distributieovereenkomst gesloten. Die werd later omgezet in een nieuwe overeenkomst, waarbij afgesproken werd dat de broncode te allen tijde gecodeerd (versleuteld) zou moeten worden met een pakket als SourceCop. Ook moest altijd het copyright van Purple Pigeon worden vermeld.

In 2010 constateerde Purple Pigeon dat de software nog steeds werd verkocht, en ook nog eens met vrij beschikbare broncode en zónder auteursvermelding van PP. Volgens Quinarx was daar geen sprake van, waarop Purple Pigeon naar de rechter stapte en een terughaalactie (recall) eiste plus een schadevergoeding.

Eén van de verweren van Quinarx was dat het programma open source bevatte, en dat het daarom niet zomaar versleuteld verspreid mocht worden. Op zich een terecht verweer: de GPL bijvoorbeeld verbiedt zulke distributie, de broncode moet er echt bij zitten (of op verzoek nageleverd worden). Maar de rechter oordeelt dat je als licentienemer niet zomaar eenzijdig mag besluiten om dan de broncode maar openbaar te maken. Als je zo’n compliance probleem signaleert, moet je de rechthebbende benaderen en ze daarop wijzen.

Terecht, maar jammer dat dit punt niet nader is uitgewerkt. Ik had wel eens willen zien wat de rechter zou zeggen van het verweer dat Quinarx (en ook Purple Pigeon) gewoon gebonden was aan de GPL en daarom wel moest handelen op deze manier.

Arnoud