Hoe bewijs je dat je een app gemaakt hebt?

| AE 7279 | Intellectuele rechten | 34 reacties

hardware-software-computer-gollem-huh.jpgMet zeer, zeer grote regelmaat krijg ik vragen van mensen die hun idee willen beschermen, hun app willen vastleggen of op andere wijze bescherming willen voor een stuk software. Nu zegt de Auteurswet dat je automatisch bescherming krijgt als je een werk maakt (dus ook een app) en dat registratie, depot of wat dan ook niet nodig is. Maar hoe bewijs je dan dat het jouw app is?

In een recent vonnis stond die vraag centraal. De eiser had een app ontwikkeld voor de gedaagde, maar die claimde op zeker moment daar zélf auteursrechthebbende van te zijn. Nu had de gedaagde een redelijk argument: zijn naam stond vermeld bij de apps, preciezer gezegd in de appstore-publicatie daarvan.

De Auteurswet zegt dat je dan ‘vermoed’ wordt de rechthebbende te zijn. Het was dus aan de eiser om te bewijzen dat hij werkelijk het werk gemaakt had.

De broncodes van de app bevatten copyright-vermeldingen in de naam van de eiser. Ook die van een derde, maar die had verklaard de rechten af te hebben gestaan aan de eisende partij.

Wel zaten er ook “zogenoemde open source componenten” in de software. U voorziet nu wellicht gillende FUD over virale effecten en kwijtraken van eigen rechten, maar dat valt reuze mee. De rechter wijdt er eigenlijk maar één zin aan:

Naar het oordeel van de kantonrechter ondersteunen deze omstandigheden het standpunt van [eiser] dat hij de broncodes van de apps naar eigen inzicht en eigen ontwerp tot stand heeft gebracht (al dan niet met hulp van medewerkers van Sveak). Dit wordt niet anders, doordat [eiser], zoals hij ook erkent, bij het schrijven van de broncodes op bepaalde onderdelen (‘open source’) programmatuur van derden heeft gebruikt, aangezien de wijze waarop hij die programmatuur heeft gerangschikt (telkens) een nieuw werk oplevert.

Oftewel, ook al gebruik je software van derden en ook al gebruik je open source, je hebt de auteursrechten op het eindresultaat als je creatief programmeerde of zelfs maar dingen aan elkaar knoopte.

(Het zou kunnen dat de opensourcelicenties van die componenten vereisen dat de eiser de app open source maakt als hij die wil distribueren. Dat komt niet aan de orde want dat is irrelevant bij de vraag wie de maker van de app was. Dat is immers hooguit een geschil tussen de opensourceauteur en zijn afnemer.)

Als laatste argument blijkt de app data te sturen naar een server van de eiser en niet van de gedaagde. Ook dat is natuurlijk best wel een aanwijzing dat die eiser gewerkt heeft aan de app. Alles bij elkaar is daarmee het bewijs geleverd.

Bewijs leveren van makerschap mag dus op elke manier, zolang het totaalplaatje maar de rechter overtuigt dat de app jouw werk was. Een depot of registratie was hier niet nodig, en zelfs het feit dat de naam van een ander bij de app stond, bleek niet onoverkomelijk.

Punt is en blijft alleen: dit helpt enkel tegen mensen die er met jouw broncode vandoor gaan of jouw app letterlijk kopiëren (oké, eventueel met aanpassingen). Wie het achterliggende idee opnieuw implementeert, mag dat doen ondanks het auteursrecht. Ook al deponeer je het honderd keer en zet je er duizend copyright-tekens op.

Maar omdat die uitkomst té frustrerend is voor mensen, zal die vraag “hoe bescherm ik mijn idee” nog héél vaak langs blijven komen.

Arnoud<br/> PS oh en natuurlijk nog de beste wensen voor 2015!

Deel dit artikel

  1. Ik lees hier dat er dus iemand op de juridische afdeling bij de gedaagde heeft zitten slapen en het over gaan van auteursrecht van de maker naar de betaler niet was geregeld. Vervolgens hebben ze nog een keer lopen slapen als ze de eiser een “phone home” laten inbouwen die dus upload naar de verkeerde…

  2. Dat is altijd een beetje het lastige met een idee, als het eenvoudig kopieerbaar is zodra het idee eenmaal op de markt is, dan is het wellicht niet zo’n goed idee. Tenminste, dat geldt voor de meeste particulieren die ideeën hebben. De implementatie en uitvoering van een idee is wat de waarde creëert, niet het idee zelf. In mijn kennisenkring heb ik ook een drietal individuen die allen een ‘idee’ hebben voor een app en een product, waar niemand iets vanaf mag weten totdat ze miljonair zijn geworden. Dat is natuurlijk machtig interessant op feestjes, je bent in het geheim aan het werk aan iets waarvan jij overtuigd bent dat je er de volgende Mark Zuckerberg of Steve Jobs mee gaat worden. Terwijl het idee vertellen aan een paar kritische vrienden je vaak met beide benen op de grond kan zetten, óf alleen maar beter en scherper kan maken.

  3. Als je een svn/git repository hebt waarbij de ontwikkelhistorie duidelijk wordt bijgehouden, lijkt het mij duidelijk dat de eigenaar/admin van die repository of het gebruikersaccount dat de commits heeft uitgevoerd ook de ontwikkelaar en daarmee auteursrechthebbende van de software is. Over het algemeen lever je als ontwikkelaar hooguit demoversies en een eindresultaat, al dan niet met code, op aan de opdrachtgever. Als ontwikkelaar beschik je dankzij een versiebeheersysteem zoals git of svn over veel meer versies van de broncode.

  4. (Het zou kunnen dat de opensourcelicenties van die componenten vereisen dat de eiser de app open source maakt als hij die wil distribueren. Dat komt niet aan de orde want dat is irrelevant bij de vraag wie de maker van de app was. Dat is immers hooguit een geschil tussen de opensourceauteur en zijn afnemer.)

    Zijn er licenties die zoiets afdwingen? Ik ben op de hoogte van GPL-like licenties, waar je wanneer je aanpassingen maakt, die aanpassingen ook moet verspreiden, maar daarmee hoef je toch niet alle code die een GPL licensed bibliotheek aanspreekt te open-sourcen (laat staan de hele app)?

    Kan dit trouwens zelfs afgedwongen worden? Ik roep gewoon je code aan zonder er aanpassingen aan te maken, hoe kan je dan zeggen dat ik de rest van mijn code verplicht moet open sourcen? Dat is immers mijn eigen werk. Over de creativiteit van het aanroepen van jou API kan er nu nog discussie zijn.

    • De GPL vraagt dat je jouw broncode beschikbaar maakt aan de ontvangers van de applicatie, wanneer jij gebruik maakt van GPL componenten in jouw applicatie. Dat is heel makkelijk af te dwingen via het auteursrecht als jij die componenten wil verspreiden… en zonder die componenten draait jouw applicatie niet!

      Wanneer de GPL componenten onderdeel uit maken van de standaard omgeving van het platform waarvoor je programmeert en dat platform door een derde onderhouden en gedistribueerd wordt, dan hoef je de GPL componenten niet zelf te verspreiden en wordt het afdwingen van die eis lastiger.

  5. Volgens de FSF ben je in zo’n geval verplicht om de gehele applicatie (met broncode dus) onder de voorwaarden van de GPL te leveren aan de ontvangers. Wil je dat niet, mag je de GPL-library dus niet gebruiken. Doe je het toch, ben je ofwel akkoord gegaan met die voorwaarde, of maak je inbreuk op auteursrechten.

    Naast de GPL is er ook de Lesser GPL (LGPL), die het mogelijk maakt om een library te gebruiken zonder dat je verplicht bent de hele applicatie te ‘bevrijden’.

    Wat MathFox precies bedoelt met componenten uit een standaard-omgeving is me niet geheel duidelijk, maar het klinkt mij een beetje dubieus in de oren.

    • Een voorbeeld: Ik schrijf een script in Python en de standaard python interpreter is gelinkt met de (GPL) readline bibliotheek. Ik lever mijn applicatie als (binair) .deb of .rpm pakket. Leg mij maar uit waarom (juridisch) de FSF het recht zou hebben om mij te verplichten de applicatie onder de GPL te verspreiden… (of vergelijkbaar: Linus Torvalds mij kan verplichten een willekeurige Linux applicatie te open sourcen.)

      • Een applicatie linkt niet met een kernel maar met de GNU C library (glibc), dus als die GPL zou zijn, zou je gelijk hebben. Maar de licentie van glibc is (niet heel toevallig) LGPL. Overigens heeft de licentie van Linux een programma-exceptie, waarmee we dus sowieso niet automatisch gebonden zijn aan de GPL voor programma’s.

        Wat betreft Python ken ik de situatie niet zo goed, maar in principe vormt jouw applicatie samen met de (core) Python libraries een afgeleid werk, en moet je je dus aan de licentievereisten van Python houden, wat deze ook mogen zijn. Zie ook: antwoord van FSF.

        • Bij Python is het niet zo duidelijk wat “de licentievereisten van Python” zijn: De referentie-implementatie van python wordt onder een BSD-achtige licentie verspreid, maar kan optioneel gelinkt worden tegen de GPL readline bibliotheek. Daarnaast zijn er nog minstens drie alternatieve implementaties van de taal, met mogelijk verschillende licenties…

          Een abstractieniveau hoger: Een programmeur schrijft zijn programma tegen een interface. Het is mogelijk om verschillende implementaties voor een interface te hebben. Ieder van deze implementaties kan eigen licentievoorwaarden hebben, maar ik betoog dat de licentie van de implementaties niet van belang is voor de licentie van de interface. (Auteurswet lid 45m.)

          Daar de programmeur tegen de interface programmeert, is de licentie van de implementatie voor hem van minder belang. Q.E.D.

          • Mathfox snijdt nu een onderwerp aan waar ik ook zo mijn twijfels bij heb. Hoe ‘viraal’ is de GPL. RMS claimt dat als je GPL bibliotheken gebruikt in de software jouw code ook onder de GPL moet vallen. In het geval van het hard linken van de bibliotheek in jouw programma is dat ook onbetwist. Immers in jouw binary zit GPL code meegelinkt.

            Maar wat nu als je GPL code een DLL is (laten we even windows nemen) en je roept de functies aan uit die DLL. Je kan de DLL en jouw code separaat verspreiden. Je kan de mensen zelfs de DLL zelf laten instaleren. Je verspreid in jouw binary geen enkele GPL code, hoe is dit een afgeleid werk? Dat is hetzelfde als zeggen dat een screenprotector voor een iPhone een afgeleid werk is van de iPhone omdat de vorm overeenkomt met het scherm.

            Het is ook precies waar de Oracle vs Google rechtzaak om gaat. En iedere programmeur die goed bij zijn hoofd is wil dat daar uitkomt dat APIs niet onder het auteursrecht vallen als zijnde functioneel ipv creatief.

            Daarnaast zit je internationaal met alerlei verschillende auteurswetten, waarbij in Nederland we lid 45m hebben. Mijn inziens is het standpunt van rms inzake de GPL dan ook niet houdbaar in Nederland. Voor zover bekend bij mij is dat nog nooit door de rechter getoetst. De zaken waar ik over gehoord heb zijn eigenlijk allemaal het verspreiden van aangepaste GPL software en bibliotheken zonder de source vrij te geven.

            Ik vermoed dan ook dat je GPL bibliotheken gewoon aan mag roepen vanuit closed source of wat voor incompatible license dan ook in Nederland. Maar wie heeft zin om daar een rechtzaak over te gaan voeren?

            • Elroy, voor ontwikkelaars die ook de GPL DLL verspreiden kan ik een juridische argumentatie bedenken die er toe leidt dat zij hun applicatiecode onder de voorwaarden van de GPL moeten verspreiden:  – Om de DLL te mogen verspreiden heb je een licentie nodig.  – De GPL is de aangeboden distributielicentie van de DLL.  – Met het distribueren van de DLL accepteer je impliciet de GPL.  – De GPL is een overeenkomst met rechten en verplichtingen.  – Je hoort overeengekomen verplichtingen na te komen.  – Maak dus de gelinkte broncode beschikbaar onder de GPL. Doe je dat niet:  – Dan vervalt het distributierecht van de DLL (art 4 GPLv2)  – En bega je auteursrechtinbreuk bij verspreiding van de DLL

              Dit betekent niet dat de applicatiecode automatisch Open Source wordt, maar het wordt wel interessant welke schadevergoeding de rechter voor de contractbreuk respectievelijk auteursrechtinbreuk toekent.

              • Ik was mij bewust van deze redenatie, wat mij irriteert is de stelligheid van de FSF en rms waarmee ze alles beweren.

                afgeleid werk? Of iets een afgeleid werk is voor de auteurswet wordt bepaald door de wet en niet door wat in een licentie staat. In de GPL en de toelichting wordt gewoon keihard gestelt dat als je linkt naar een GPL programma, jouw programma een afgeleid werk is. Sinds wanneer schrijft de FSF de wet voor? Ik heb de auteurswet van voor tot achter gelezen en ik zie geen enkele onderbouwing voor deze stelling. Je zit dus alleen met een probleem bij het verspreiden van de GPL DLL, omdat dat recht inderdaad vervalt omdat je niet aan hun voorwaarden voldoet. Alleen zie ik niet in waarom je dat niet net als het ‘mp3 probleem’ op kan lossen: Hier heb je onze software, daar bij een derde kan je een DLL halen die je nodig hebt.

                Op dat moment zie ik echt niet wat de auteur van de DLL gaat doen, jij verspreid niets van zijn werk en voor zover ik kan zien in de auteurswet is jouw programma geen afgeleid werk.

                Programmeren met een ‘shim’ Volgens de FSF kan jij geen ‘shim’ tussen een GPL library en jouw niet GPL programma zetten, omdat jouw programma zonder de GPL bibliotheek niet werkt. Maar is dat wel zo?

                Een voorbeeld: Er zijn verschillende libraries beschikbaar om video te decoderen, allen onder een andere licenties. Je kan verschillende shims leveren voor deze libraries zodat jouw programma met allemaal kan wekren terwijl jij tegen één API programmeert, die van je shim. Het is voor mij evident dat het programma dan geen afgeleide is van de GPL bibliotheek, immers het functioneert ook met een andere bibliotheek. (bijvoorbeeld ffmpeg en divx voor mp4). Waarom zou het dan wel een afgeleide zijn als – op dit moment – een GPL bibliotheek de enige optie is? Dit is volkomen onlogisch.

                Wie maakt er dan eigenlijk inbreuk bij dynamisch linken Ik zie in de wet geen enkel handvast waarom dynamisch linken tot een afgeleid werk zou leiden. Als er al inbreuk is, dan zou dat pas op het moment van linken moeten zijn, immers pas dan worden de library en jouw programma samengevoegd. En als je zoals in bovenstaande voorbeeld kan kiezen voor een decoder, dan maakt de gebruiker inbreuk, maar aleen als die ervoor kiest om de GPL bibliotheek te gebruiken.

                Bij meer niche producten zie ik het nog gebeuren dat je .obj files aanlevert en je klant uiteindelijk de boel linkt tot een executable. De klant downloadt de GPL bibliotheek en compileert en linkt die met jouw software. Hij kan zelfs statisch linken en hij heeft volkomen het recht om dat te doen! Immers hij zal de software niet verder verspreiden en je heft je code alleen maar onder de gpl te verspreiden als je de software verspreid.

                Ik mag een klant ook de source onder een strikte licentie dat hij die niet verder verspreid maar wel mag aanpassen verkopen. De klant mag dan (expliciet toegestaan!) voor eigen gebruik deze code linken aan gpl code (of er zelfs gpl code direct in opnemen) zolang hij het maar niet buiten zijn onderneming verspreid. Wat hij weer niet doet door de licentie op de niet gpl code.

                Hoe je het ook wendt of keert de redenatie linken=>afgeleid werk loopt vast op een inconsistentie. Dynamisch linken met GPL bibliotheek lijkt mij sowieso niet tot een afgeleid werk te kunnen leiden. En voor bepaalde technischere markten kan je zelfs statisch linken zonder in de problemen te komen met de GPL.

                De FSF heeft echter een berg advocaten en juristen en ik zie ze dus niet anders dan andere grote partijen in de markt die de regels interpreteren zoals ze wilen en roepen so what, als je gelijk wil kom het maar halen. Bullies dus…

                Voor mij is het echter duidelijk, ik zal nooit software onder de GPL of vergelijkbare licentie uitbrengen. BSD is de echte ‘vrije’ optie. GPL is de wil van rms en heeft niets met vrijheid te maken, maar met dwang.

                Schadevergoeding? Welke schadevergoeding de rechter toewijst? In het verlengde van Adam Curry en de facebook fotos … geen. Immers je stelt je werk gratis beschikbaar, dus is je werkelijke schade per definitie nihil.

                • Elroy, ik ben het eens met de essentie van jouw analyse, maar naast “afgeleide werken” kent de auteurswet ook nog “verzamelwerken”, die bestaan uit combinaties van meerdere originele werken. Bij het (statisch) linken met een library zou ik eerder naar de regels voor verzamelwerken kijken.

                  Een leuke case om eens over na te denken: Er is een gepubliceerde, vrij herbruikbare interface. Er bestaan vier componenten die deze interface implementeren, twee commerciële, een GPL en een BSD gelicenseerd. Jouw applicatie kan dynamisch linken tegen ieder van deze componenten…

                  Nee, de FSF is niet zo rijk dat ze een heel leger juristen in dienst heeft… ten tijde van het opstellen van de GPLv1 en 2 draaide de FSF op Stallman die samen met Eben Moglen de GPL opgesteld heeft. Tegenwoordig is de FSF wat rijker en kan zich een huisjurist veroorloven.

              • Er is een wezenlijk verschil tussen Oracle v. Google en ik-wil-GPL-libraries-linken. In Oracle gaat het namelijk om een library die Google volledig zelf heeft geimplementeerd, met uitzondering van de API definities die gekopieerd werden.

                Wil je een GPL library linken, gaat het je niet zozeer om de API (definities), maar om de reeds geimplementeerde functionaliteit die je hergebruikt. Dat is ook het argument van de FSF: link je een library, dan gebruik je daarvan functionaliteit, dus maak je een afgeleid werk.

                In Oracle gaat het met name om of Google de header-files onder het kopieerapparaat mocht leggen, en niet of ergens een afgeleid werk zou ontstaan.

                • Het enige wat je hergebruikt in jouw code zijn de header files. Als daarop geen auteursrecht rust, heb je bij dynamisch linken geen enkele auteursrechtelijk beschermde code opgenomen in jouw programma. En jouw programma is geen afgeleid werk precies om de reden die jij aangeeft. Als je een zelf geschreven implementatie van de interface in die headerfiles maakt dan werkt jouw programma ongewijzigd.

                  Of als je geen header files hebt/wil gebruiken kan je een DLL openen en functies aanroepen in c++ met load library, getprocaddress, function pointers en freelibrary. Ik kan niet bedenken hoe dit zou verschillen van in je programma op de achtergrond een executable starten de data kopieren en de executable beeindigen. In beide gevallen laad je een binary in het geheugen, je geeft het de gevraagde input en neemt de gegenereerde output en je sluit de binary. Maar volgens de FSF is het laden en aanroepen van een bibliotheek een afgeleid werk en het aanroepen van een executable niet. Dat is een gekunsteld verschil waar in de wet geen basis voor is te vinden.

                  Overigens jij hebt het over ‘hergebruik’ van de implementatie. Een normale definitie van hergebruik in deze is dat je de code van de library neemt en in je programma kopieert. Het aanroepen van een bibliotheek is geen hergebruik, maar gebruik. Bibliotheek functies zijn bedoeld om aangeroepen te worden. Een DLL is niets meer dan een verzameling uitvoerbarecode met als enig verschil met een uitvoerbaar programma, dat deze laatste een verzameling uitvoerbare code is met een begin punt heeft waar hij begint uit te voeren en bij een library je moet aangeven welk stukje code je uit wil voeren.

                  En om nog maar eens een voorbeeld te noemen van het absurde standpunt van de FSF: Als de bibliotheek nodig is om het programma te kunnen gebruiken, dan is het programma een afgeleid werk. Ider Linux programma heeft linux nodig om te kunnen werken en ieder windows programma heeft windows nodig. Dus alle software voor deze platforms zijn nu afgeleide werken? De FSF wil ons doen geloven van wel en heeft daarom de system library exception opgenomen.

                  Als ik een schilderij heb van 2×4 meter en ik laat een frame maken van 2×4 meter, is dat dan een afgeleid werk van het schilderij? Immers, de maat wordt bepaald door de maat van het schilderij? En als het schilderij een afwijkende vorm heeft die onderdeel is van het creatieve, mag iker dan opeens geen lijst meer voor laten maken voor ik het ophang? Waarom moeten digitaal toch altijd dingen normaal zijn, die we in ieder ander werk onacceptabel zouden vinden?

                • link je een library, dan gebruik je daarvan functionaliteit, dus maak je een afgeleid werk.

                  Dat gaat me te ver. Het zou betekenen dat als ik een programma schrijf in een taal waarvan slechts één implementatie bestaat, het programma een afgeleid werk is van de taal en daarmee onderworpen aan het auteursrecht van de taalmaker. (Voorbeeld: Visual Basic of proprietaire macrotalen zoals bij SAS). En dat gaat keihard in tegen de SAS/WPL-uitspraak van het Hof: op talen en functionaliteit kan geen auteursrecht worden geclaimd.

                  Bovendien krijg je dan de gekke situatie dat de latere introductie van een tweede implementatie van de library (zoals editline bij readline) de afgeleidwerkstatus zou aantasten. Of dat het ineens een ISO standaard worden van de taal alle programma’s ineens zou ontslaan van afgeleidwerkzijn.

                  Nee. De enige redelijke uitleg is volgens mij die van het Hof: roep je slechts functionaliteit aan, dan maak je géén verveelvoudiging in gewijzigde vorm (“afgeleid werk”) van de software. Je leunt op de software, maar dat is nog geen auteursrechtinbreuk. Pas als de library in enige wijze opduikt in jouw software, heb je een verveelvoudiging en pas dan kan er sprake zijn van inbreuk.

                  • De verveelvoudiging van een library zit ‘m erin dat de library fysiek aanwezig moet zijn, ofwel in de vorm van een gedeelde bibliotheek (.dll of .so) ofwel statisch gelinkt is waarmee feitelijk de binaire code gekopieerd wordt in de binaire code van het programma. De binaire code is een directe vertaling van de broncode waar het auteursrecht op rust, dus mag niet zomaar gekopieerd worden (net zoals een fan-vertaling van een ondertiteling van een film ook nog inbreuk maakt op het auteursrecht van het origineel). MathFox stipt een interessant punt aan, namelijk wat als die bibliotheek al aanwezig is op het platform (via legale weg omdat het platform zelf Open Source / GPL is)? Als je het aan mij vraagt maak je dan nog steeds inbreuk omdat de platformbibliotheken als soort van dienst aanwezig zijn om te voorkomen dat je ze zelf moet verspreiden maar de verspreiding (en daarmee de verveelvuldiging) nog steeds nodig is geweest voor de werking van jouw programma. De GPL geeft je daarvoor alleen toestemming als jouw code ook GPL is (of compatibel daarmee).

                    • WTF? De gebruiker heeft volgens de GPL het recht die bibliotheek te installeren en fysiek aanwezig te hebben en zelfs te verveelvoudigen. Sterker nog niet accepteren/overtreden van de GPL (v2) heeft expliciet niet tot gevolg dat je het gebruiksrecht verliest. Je verliest slechts het recht op aanpassen en verspreiden al dan niet met aanpassingen!

                      De hele casus gaat er nu juist om dat je de GPL bibliotheek niet verspreid met jouw programma, maar dat je er vanuit gaat dat die al aanwezig is.

                      De binaire code wordt gekopieerd in het programma? Ja bij statisch linken, maar bij dynamisch linken wordt een bibliotheek in het geheugen geladen en wordt aangeroepen. De juiste bibliotheek wordt bij dynamisch linken bij het laden van het programma of zelfs pas op het moment van uitvoeren in het geheugen geladen. Zo’n beetje iedere dll /.so van enige functie heeft zijn eigen heap, separaat van die de aanroepende executable. Dus jouw claim dat de code in jouw programma gekopieerd wordt is ook niet waar.

                      De GPL kan wel leuk claimen dat je inbreuk pleegt, maar dat moet wel in de wet onderbouwd zijn. Als dat niet zo is, ben je alleen je rechten op basis van de GPL voor de bibliotheek kwijt. En zoals gezegd de gpl betreft slechts het recht te modificeren en distibueren, je mag de bibliotheek gewoon blijven gebruiken, dus ook op je dev machine, zolang je hem maar niet aanpast. (En dat laatste is ook dubieus, want je mag op basis van de auteurswet bepaalde zaken ter leeringh ende vermaack zonder dat je daar toestemming voor nodig hebt)

                      • We hebben het alleen even over dynamisch linken, bij statisch linken is het argument duidelijk lijkt me.

                        In het geval dat een bibliotheek nog niet aanwezig is op het platform (ik vermoed dat dat bij deze app het geval is) dan moet je die bibliotheek dus meeleveren. Dat mag alleen onder de licentievoorwaarden van die bibliotheek en het argument van de FSF is dat je de bibliotheek alleen mee mag leveren met een programma dat linkt naar die bibliotheek als dat programma compatibel is met de GPL. Daar kun je natuurlijk tegenin brengen dat je de bibliotheek ook mag verspreiden afzonderlijk van het programma, en daarnaast (toevallig tegelijkertijd) je programma levert dat met die bibliotheek linkt. Als je dat okee vindt dan hoeven we het al niet eens meer te hebben over bibliotheken die op het platform voorgeïnstalleerd zijn. Persoonlijk vind ik dat valsspelen omdat het niet de bedoeling is van de licentie. Die licentie maakt voor jou speciaal een uitzondering op de auteursrechten die het anders zou hebben, dus vind ik dat je je aan de intentie van de licentie moet houden, ook al is het in principe mogelijk is door de mazen van die licentie te wurmen en het toch te doen.

                        Dat de FSF en RMS persoonlijk heel stellig zijn vind ik niet meer dan logisch. Het is hun licentie, dus zij kunnen precies vertellen wat ze ermee bedoelen. Geeft ze misschien niet automatisch het recht om ook zo stellig te zijn bij software die ze niet zelf maken maar wel de GPL gebruiken, maar ik vind het wel verdedigbaar aangezien een minder strikte interpretatie ook gevolgen kan hebben voor de software die ze wel zelf maken.

                        Als je het niet erg vind dat je bibliotheek ook verspreid mag worden samen met niet-GPL software dan kun je voor de LGPL kiezen. Die afweging moet bij de auteur van de bibliotheek liggen, niet bij de gebruiker van de bibliotheek.

                        PS. Je rant over statisch linken staat letterlijk ook in mijn reactie.

                        • Mea Culpa: Ik had jouw reactie gelezen als (ofwel in de vorm van een gedeelde bibliotheek (.dll of .so) ofwel statisch gelinkt is) (waarmee feitelijk de binaire code gekopieerd wordt in de binaire code van het programma.) in plaats van (ofwel in de vorm van een gedeelde bibliotheek (.dll of .so)) (ofwel statisch gelinkt is (waarmee feitelijk de binaire code gekopieerd wordt in de binaire code van het programma.)

                          Jij gaat er vanuit dat de dynamisch gelinkte bibliotheek wordt meegeleverd. Dan loop je inderdaad tegen de GPL aan. Immers je verliest het distributie recht op de library door deze conform auteurs wet, maar tegen de GPL wens te gebruiken.

                          Jouw klant kan echter die library van dezelfde plek halen al waar jij hem vandaan haalt. Stel dat die library wordt geleverd met versie X van GIMP, dan zeg je bij jouw software gewoon ‘systeem vereiste: GIMP versie X) en laat de gebruiker de bibliotheek installeren en de maker van GIMP die zich volledig aan de GPL houdt is de verspreider van de bibliotheek.

                          Is dit in de geest van de GPL? Nee, zeker niet; dat moge duidelijk zijn. Maar iedere beperking die een GPL wil opleggen zal toch echt een basis in de wet moeten hebben, aangezien het geen contract is maar een licentie.

                            • Jouw leestekens staan goed, ik had het verkeerd gelezen.

                              Voor het merendeel ben ik het met je eens dat de GPL toestemming geeft.

                              Echter geeft de GPL een eigen interpretatie van wat een afgeleid werk is, die af kan wijken van wat er in de wet staat. Vervolgens zegt men: deze afgeleide werken obv deze definitie moet je onder de GPL uitbrengen, anders vervalt jouw recht om te modificeren en distribueren op basis van deze licentie. Naast toestemming geven probeert men dus ook termen te definieren. Op zich logisch aangezien de definitie van afgeleid werk in de US nogal vaag is.

                              Ik kies er vervolgens voor om mijn software die dynamisch linkt naar een GPL bibliotheek niet onder de GPL uit te brengen. De auteur van de bibliotheek kan niet afdwingen dat mijn software onder de GPL uitgebracht moet worden, omdat het wettelijk gezien geen afgeleid werk is.

                              Echter ik kan de bibliotheek nu niet meer met mijn software verspreiden, omdat ik niet aan de voorwaarden van de GPL op de bibliotheek voldoe. Mijn gebruikers zullen zelf een kopie van de bibliotheek moeten verwerven. Deze mogen zij – onder de GPL – combineren met mijn proprietaire software. Zolang ze deze combinatie maar niet verder distribueren.

                              Dus: de GPL kan niet afdwingen dat ik mijn source code release onder de GPL in dit geval duur een verschil in definitie van afgeleid werk in de GPL en de nederlandse wet. Om dezelfde reden kunnen ze niet voorkomen dat ik de binary van mijn werk verspreid. En ze kunnen op basis van de wet en hun eigen GPL niet voorkomen dat mijn klanten daar alsnog hun bibliotheek aan toevoegen.

                              Daarbij moet ik wel zeggen dat ik alleen de tekst van GPLv2 goed ken, wellicht dat GPLv3 gebruiks beperkingen oplegt aan de software bij non-compliance, v2 doet dat niet.

                              • Met zo’n constructie wordt het dan wel heel gemakkelijk om de vereisten van de GPL te omzeilen. Ik kan bijvoorbeeld een RPM bakken waarin een GPL-dependency gedefinieerd is. Pas op het moment dat de gebruiker de RPM installeert, downloadt de package manager de dependency. Dan heb ik mijn software niet samen met de GPL-library geleverd, en ben ik niet aan de GPL gebonden.

                                Als dit juridisch houdbaar zou zijn dan is de GPL als licentie eigenlijk waardeloos geworden. Maar ik moet nog zien of het voor de rechter echt wezenlijk anders is als wanneer je de library wel meelevert.

                                • Interessant punt! Onder windows is(was?) het gebruikelijk al je software in één installer te gooien en die te verspreiden, zodat men niet verder hoeft te zoeken naar dependencies. Onder Linux is het eigenlijk sinds dag 1 gewoon om alleen jouw deel te verspreiden en dan te verwijzen naar dependencies. Die software zit in repositories en verspreid je dus technisch gezien niet zelf.

                                  Overigens is het niet zo dat de GPL nuttteloos is als je er vrij dynamisch naar mag linken. Je mag nog steeds geen code je programma in kopieren en als je een library zelf verbeterd zal je die verbeteringen nog altijd openbaar moeten maken onder de GPL op het moment dat je die verbeterde library gaat verspreiden. Men kan dus niet jouw bibliotheek nemen en aanpassen/verbeteren en dan de verbeteringen voor zichzelf houden; iets wat met een BSD licentie bijvoorbeeld wel kan.

                                  Wat niet meer kan is een praktijk waar ik laatst over las: Men heeft proprietaire software en releast nuttige bibliotheken onder de GPL ipv de LGPL. Een nieuwe concurrent kan zo geen gebruik maken van jouw code als ze een proprietair programma willen verkopen, maar zal wel last hebben van eventuele vrije concurrentie gebaseerd op die GPL bibliotheken om voet in de markt te krijgen. Het is dus een strategie geworden voor gevestigde markt partijen om concurrentie dwars te zitten door software onder de GPL ipv LGPL uit te brengen.

                                  • @Elroy: ik bedoel waardeloos in de zin van dat er geen toegevoegde waarde is ten opzichte van de Lesser GPL (LGPL).

                                    Overigens is deze truc natuurlijk ook simpel op andere besturingssystemen los te laten. Je kunt bijvoorbeeld de installer voor je Windows-programma componenten laten downloaden met hetzelfde effect. Of zelfs enkel de gebruiker instrueren om iets te downloaden.

                              • Goed punt. Ik ben het met je eens dat niet de GPL maar de wet bepaalt wat een afgeleid werk is. Ik vraag me af of het mogelijk is om in een licentieovereenkomst te stellen dat er niet naar deze bibliotheek gelinkt mag worden tenzij de software ofwel voor eigen gebruik is ofwel gedistribueerd wordt met een GPL-compatibele licentie. Op die manier bepaalt de bibliotheek dus niet of je al dan niet mag verspreiden (want daar mogen ze wettelijk niets over zeggen, zoals je stelt), maar of je al dan niet mag linken. Maar dan kom je een klein beetje in Oracle-land, want waarom zou je niet mogen linken (onredelijk bezwarende eis)? Ik geloof dat je me min of meer overtuigd hebt.

                                • Ik vraag me af of het mogelijk is om in een licentieovereenkomst te stellen dat er niet naar deze bibliotheek gelinkt mag worden tenzij de software ofwel voor eigen gebruik is ofwel gedistribueerd wordt met een GPL-compatibele licentie.

                                  Als ik zie wat er in commerciële EULA’s staat denk ik dat het mogelijk is om zoiets in een licentieovereenkomst te zetten (en ook of te dwingen). Maar dan moet je deze (algemene) voorwaarde wel laten accepteren voor het downloaden van de bibliotheek en/of bij installatie. (Downloaden is een kopie maken en de auteur mag daaraan voorwaarden verbinden.)

                                • Dat kan zeker, alleen vinden de opstellers van de GPL dat zij geen overeenkomst schrijven maar een eenzijdige verklaring die puur op het auteursrecht gebaseerd moet zijn. Alle eisen die men stelt, moeten aan een auteursrechtelijk relevante handeling gekoppeld zijn. Vandaar de koppeling met het afgeleide werk.

                                  Als de FSF er echt een overeenkomst van maakt, dan kunnen ze ook zeggen “Alle software die u ooit nog uit gaat brengen, moet onder de GPL geplaatst worden ongeacht of het afgeleid is van onze software of niet”. Dat is dan gewoon een vrije invulling van de contractsvrijheid. Maar die insteek willen zij niet.

  6. “Dat komt niet aan de orde want dat is irrelevant bij de vraag wie de maker van de app was. Dat is immers hooguit een geschil tussen de opensourceauteur en zijn afnemer.” – Ik zou niet uitsluiten dat het een onherroepelijk derdenbeding is ex 6:253 BW om het open source te maken (dus om gratis licenties te geven). Het klopt dat je nog steeds maker bent en auteursrechthebbende, maar de opdrachtgever had er een beroep op kunnen doen. Uberhaupt heeft de opdrachtgever hier een steek laten vallen door geen (stilzwijgende) licentie aan te voeren.

    • Zo te lezen wilde de gedaagde de auteursrechten hebben om zelf onderhoud te kunnen doen (zie r.o. 8, “Tussen partijen staat, als niet door EverywhereIM weersproken, vast dat EverywhereIM de apps sinds een zeker moment niet meer door [eiser] maar door derden laat updaten”). Dan snap ik dat je niet gaat zitten op de eis een licentie te krijgen.

      Bovendien heeft dat tot gevolg dat de gedaagde de software niet meer zelf kan verkopen als gesloten software, wat vermoed ik toch wel hun businessmodel zou zijn. Als je klanten de software gratis mogen verspreiden dan ondermijnt dat je afrekenmodel van per kopie betalen.

  7. Altijd lastig, code of software auteursmatig beschermen. Wat ik al vaak heb gezien is dat men code jat, een klein beetje herschrijft en vervolgen publiceert. Ja, wat begin je dan nog? Ik heb zelfs gezien dat andere meer geld eraan verdiende dan de originele auteur. Een mooier verhaal, mooiere foto, ander design, maar precies dezelfde motor. Maar omdat mensen het meer vertrouwen kopen ze de gejatte app wel maar het originele niet. komt vaak voor bij bijvoorbeeld Magento of WordPress plugins waarbij gratis plugins worden gecloned naar betaalde premium plugins. Gelukkig is onze uren app gebaseerd op een framework waarbij kopieëren feitelijk onmogelijk en ook totaal onzinnig is.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS