Mag je licentie-incompatibele dependencies meeleveren met je software?

| AE 9144 | Open source, Software | 34 reacties

Een lezer vroeg me:

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

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

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

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

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

Arnoud

Deel dit artikel

  1. Stel dat het om boeken zou gaan. De auteur van het eerste boek heeft het boek uitgebracht onder GPL. Je schrijft vervolgens zelf ook een boek. In dat boek verwijs je steeds naar het eerste boek, maar de licentie is niet compatibel met het eerste boek. Waarom zou je die twee boeken wel los, maar niet samen mogen verzenden?

    • In jouw voorbeeld moet de lezer zelf in het tweede boek kijken. Bij software kan het eerste boek stukken uit het tweede boek invoegen zonder dat de gebruiker daar erg in heeft.

      De vraag is of je bij GPL-software spitsvondig kunt roepen: “ja maar het is een library hoor”. Praktisch zit er geen enkel verschil tussen het aanroepen van een library en het meecompileren met je eigen code.

      • Zoals ik in de in het artikel aangehaald thread al zei praktisch is er ook geen verschil tussen aanroepen van een dynamisch gelinkte library en het aanroepen van een executable.

        Maar die weg hoef je niet eens te bewandelen in de EU: Als je een dynamische gelinkte GPL bibliotheek functie aanroept in niet GPL software en jouw software distribueert voldoe je niet aan de GPL licentie. Je overtreedt tevens ook niet de auteurswet. Je accepteert de GPL licentie niet; je verliest daarmee enkel het recht om de GPL bibliotheek te distribueren (expliciet verlies je niet het gebruiksrecht van die bibliotheek, lees de GPL maar na)

        Het probleem is dat je een robuuste manier moet vinden om jouw gebruikers aan de missende bibliotheek te helpen, daarvoor kan je mooi packagemanagers gebruiken.

      • Je wijst er op dat in mijn voorbeeld de lezer zelf handelingen moet verrichten, terwijl bij software de computer dat voor de gebruiker doet. Wat je niet uitlegt is waarom dit verschil auteursrechtelijk uitmaakt voor de vraag of er sprake is van een afgeleid werkt. Het lijkt mij dat er in beide situaties geen sprake is van een afgeleid werkt, omdat alleen naar het andere werk wordt verwezen.

      • Er is een juridisch verschil tussen het (statisch) linken van een library in jouw code en het dynamisch aanroepen van dezelfde code in een extern bibliotheekbestand. Bij statisch linken combineer je de code van meer auteurs tot een “gezamelijk werk” en heb je toestemming nodig van alle auteurs van het gecombineerde werk om het te mogen verspreiden. Bij dynamisch linken blijft het bibliotheekbestand een apart werk, dat onafhankelijk van jouw werk verspreid kan worden.

        P.S. Er zijn gevallen denkbaar (inline functies, templates, C macro’s) waar toch bibliotheekcode in objectfiles die door de compiler uit jouw eigen broncode gegenereerd worden terecht komt.

        • Er zijn verschilllen: – je neemt bestaande code en past die aan. In de meeste gevallen zul je het resultaat onder de oude licentie moeten verspreiden. – je neemt een software library en gaat die linken aan jouw programma (statisch of dynamisch). Als de library onder de GPL is verspreid, zul je die op jouw werk moeten toepassen, maar als ze onder de LGPL valt, niet. – je bouwt een aparte executable die onder een vrije licentie valt en die op een andere manier met je hoofdprogramma valt. Dat mag doorgaan. – je neemt bestaaande programma’s met verschillende licenties en verspreidt ze tezamen, bijvoorbeeld in een Linux distributie. Dat zal mogen als aan alle licenties voldaan wordt.

    • Ik vermoed dat een refererend boek dat niet zinvol te lezen is zonder het gerefereerde boek ook een afgeleid werk is, en dat auteur daar dus ook een licentie voor nodig heeft om het te kunnen verveelvuldigen (zonder auteursrechten te schenden). Als het gerefereerde boek een GPL licentie zou hebben, zou die wellicht ook af kunnen dwingen dat het referende boek een vergelijkbare licentie moet hebben.

        • Dat is niet direct op een artikel gebaseerd; meest in de buurt komt m.i. 13 Aw over de “afgeleide werken”: Onder de verveelvoudiging van een werk van letterkunde, wetenschap of kunst wordt mede verstaan …. en in het algemeen iedere geheele of gedeeltelijke bewerking of nabootsing in gewijzigden vorm, welke niet als een nieuw, oorspronkelijk werk moet worden aangemerkt.

          Ik zou daar zelf inderdaad niet direct uithalen dat het voorbeeld hieronder zou vallen. Dus misschien is afgeleid werk niet terecht. Maar als je zoveel verwijst dat je boek zonder dat andere boek onleesbaar wordt kun je je boek misschien toch niet meer als oorspronkelijk werk beschouwen.

          Op welk artikel beroepen de software makers zich als ze claimen dat het gebruik van de interface van hun library een afgeleid werk is?

          Ik bedenk nu ineens ook: je mag een creatieve zin niet zomaar overnemen. Dat geldt dus eigenlijk ook voor boektitels in een referentielijst (en interface elementen van een software library). Zijn daar ook uitzonderingen voor (waarop je je dan ook bij software kunt beroepen)?

          Maar goed: als een rechter in staat is om links naar andere radiostations te zien als inbreuk (zie last FM), waarom zou dat bij links van het ene boek naar het andere niet zo gezien kunnen worden, zeker als het referende boek zonder die links niet bruikbaar zou zijn….

  2. Ik heb zelf een hekel aan de GPL licenties en wil daar als ontwikkelaar ook eigenlijk niets mee te maken hebben. Maar dat maakt het soms best lastig om goede software te ontwikkelen. Vooral als je daarbij de keuze hebt tussen een goede library doe onder de GPL valt, of een wat slechtere library die een andere licentie heeft. Het probleem is namelijk dat de GPL erg besmettelijk is als een licentievorm en er zijn al veel bedrijven die hun broncode hebben moeten openbaren omdat ze GPL’ed code hebben gebruikt.

    En deze discussie toont weer eens aan hoe beperkend de GPL eigenlijk kan zijn, omdat het ontwikkelaars eigenlijk tegenhoudt om bepaalde, goede oplossingen te gebruiken simpelweg omdat ze dan licentieproblemen krijgen. De wetgeving houdt wat mij betreft te weinig rekening met samenwerkende producten en kijkt alleen naar afgeleide producten. Ik wil een library kunnen gebruiken waarbij ik geen code afleid van die library maar alleen gebruik vanuit mijn eigen code. Dan is het niet een afgeleid werk maar een samenwerking. De GPL code is dan nog steeds GPL, maar mijn eigen werk heeft mijn eigen licentie. (Die b.v. meer open of gesloten kan zijn…)

    Alleen, met de huidige wetgeving lijkt dit niet mogelijk.

    • Dat is ook een bewuste implementatiekeuze in een ‘copyleft’ licentie zoals de GPL. Als je één onderdeel gebruikt wat een GPL-licentie heeft, dan zul je op basis van de voorwaarden van die GPL alle werk wat je ermee maakt ook onder de GPL uit moeten brengen. Zo krijg je een kettingreactie van afgeleide werken die steeds meer en meer een GPL-licentie hebben, met als effect dat meer software ‘open source’ wordt uitgebracht.

      Die keuze is een politieke en ideologische keuze, niet eentje die bedoeld is als juridische implementatie. Alleen schiet het nu zijn doel voorbij omdat steeds meer ontwikkelaars (vooral met nieuwe versies van de GPL) de GPL als licentievorm gaan mijden omdat er te veel verplichtingen aan hun eigen werken komen te zitten.

      Net zo goed als ik het er niet mee eens zou zijn als de EULA van een softwarepakket af zou dwingen wat ik wel en niet mag met wat ik met dat softwarepakket maak, zou ik dat ook niet accepteren van een ‘vrije’ licentie voor libraries zoals de GPL. Dat gaat ook tegen “free as in speech” in, als een vrije licentie van toekomstige werken gaat verplichten dat ze ook een vrije licentie gaan nemen, dan is die vrijheid weg.

  3. ‘hoe beperkend de GPL kan zijn’. Prima, maar is dat de fout van de ‘wetgeving’? Is dat niet eerder de ‘fout’ van de bouwer van de library? Die heeft, bewust of per ongeluk, voor de GPL gekozen.

    Als het bewust is heb je gewoon pech. De bouwer verbindt gewoon consequenties aan het gebruik van zijn library. Daar ben je mee akkoord of niet, indien niet, tja, dan niet inbouwen.

    Als het per ongeluk is… dat is dan maar zo. De bouwer heeft consequenties georganiseerd die hij niet wilde, maar is dat de fout van het systeem?

    Ik ga er vanuit dat iemand die iets onder GPL beschikbaar maakt, dit bewust en weloverwogen doet, en inderdaad uit idealisme wil dat afgeleide werken onder dezelfde licentie vallen. Dat dat lastig is is, dat zal best, dat je dat niet leuk vindt, dat zal ook best.

    Maar niemand dwingt je die library te gebruiken, dat is een soort gemakszucht.

    • Bewust of onbewust ervoor kiezen om de GPL te gebruiken maakt in principe niet uit. Je hebt dan een library die niet door iedereen te gebruiken is en dat is niet de bedoeling van Open Source. Op zich is het inbouwen van GPL code niet het grootste probleem want die code en eventuele aanpassingen op die code zijn verder niet het probleem. Het probleem is dat er vanuit de GPL gemeenschap geredeneerd wordt dat een project dat GPL code gebruikt in het geheel onder de GPL komt te vallen, en dus niet alleen het beetje wat van GPL gebruik maakt.

      Een voorbeeld is b.v. een GPL library waarmee je PNG en JPG bestanden mee kunt manipuleren vanuit C++. Een hele mooie, object-georiënteerde bibliotheek met een hoge performance en zeer goed gedocumenteerd en onderhouden. Een mooi product, alleen valt het onder de GPL. Als je dan vervolgens een mail-applicatie bouwt die bij uitgaande emails ook even de afbeeldingen optimaliseert en bij inkomende emails de plaatjes mooi weergeeft dan heb je door die GPL al snel een probleem! Je gebruikt dan die specifieke library en daarmee wordt je gehele product meteen GPL. En moet de broncode ervan gedeeld worden en kun je er b.v. geen commercieel product van maken.

      Dat zou dus betekenen dat je als ontwikkelaar naar een andere oplossing moet zoeken, als je al op tijd beseft dat je de betreffende library niet zomaar mag gebruiken. Er zijn al vele bedrijven onbewust in deze val getrapt die vervolgens hun broncode moeten vrijgeven omdat ze onbewust GPL code hebben gebruikt. Dat vind ik eigenlijk op de zwarte lijst van voorwaarden staan. Ja, mijn aanpassingen op GPL code moet ik gewoon weer vrijgeven. Nee, mijn eigen code die ik naast de GPL heb gebruikt voor mijn project blijft mijn eigen code en kan dus niet onder de GPL vallen. Ik ben immers de auteur en dus kan mijn eigen werk niet zomaar onder de GPL vallen simpelweg omdat mijn project een GPL library gebruikt.

      • Beste Wim, Een verplichting om jouw code onder de GPL te distribueren betekent nog niet meteen dat jij geen eigenaar van de code meer bent. Ook met GPL code kun je goed geld verdienen, kijk maar naar Red Hat!

        Ik ken de filosofie van de FSF en weet welke ideeen er achter de GPL zitten. Ik weet ook dat ontwikkelaars met enige kennis van zaken een goede motivatie hebben om een bepaalde licentie te kiezen voor hun software. Waar het bibliotheken en framewoks betreft kan er een goede reden zijn om in specifieke gevallen voor de GPL te kiezen. Een van de ideeen achter de GPL is het maken van Vrije Software te bevorderen.

        • Beste Wim, Een verplichting om jouw code onder de GPL te distribueren betekent nog niet meteen dat jij geen eigenaar van de code meer bent. Ook met GPL code kun je goed geld verdienen, kijk maar naar Red Hat!

          Het heeft wel als effect dat GPL-licenties in heel veel werkomgevingen niet meer te doen zijn. Als je een in een project werkt waar je met bedrijfsgeheimen in de code bezig bent, dan staat dat lijnrecht op de GPL. Immers door de GPL word je verplicht om je broncode (en dus je bedrijfsgeheimen) te publiceren, wat dus de NDA van je bedrijf zelf zou schenden.

          Vrije software betekent ook dat er vrijheid moet zijn in of iemand anders meedoet aan die vrije software. Dat moet immers uit vrije wil gebeuren omdat de ideologie die de FSF uitdraagt aansluit bij de ontwikkelaar en bij de software die op dat moment wordt gemaakt. Als je vrije software gaat afdwingen via juridische clausules dan is het geen vrije software meer, maar hooguit een gemaakte schijnvrijheid.

          De uitspraak “free as in speech” komt dan een beetje over als de vrijheid van meningsuiting die stand houdt als iemand het met jouw mening eens is, maar als iemand er anders over denkt (en bijvoorbeeld zijn broncode niet wil openbaren) dat het dan geoorloofd is om die mening keihard aan te vallen.

          • De verplichting in de GPL om broncode openbaar te maken treedt alleen in werking als je de (met GPL componenten) gemaakte applicatie verspreidt. Voor applicaties die alleen binnen het bedrijf gebruikt worden is er geen probleem.

            Als je commerciële software wil maken en daarbij niet met de GPL wil meedoen kan dat ook, dan moet je ook geen GPL componenten gebruiken, je hebt daar zelf de keus in. (Je hoort het auteursrecht van de ontwikkelaars die expliciet voor de GPL kiezen te respecteren.)

            Er zijn tijden geweest dat de licenties van commerciele standaardbibliotheken die bij een compiler geleverd werden juridische discussies veroorzaakten… Er was geen expliciete toestemming gegeven om de met de compiler gebouwde executable (waar code van de compilerbouwer in zat) te verspreiden.

            • Als je commerciële software wil maken en daarbij niet met de GPL wil meedoen kan dat ook, dan moet je ook geen GPL componenten gebruiken, je hebt daar zelf de keus in. (Je hoort het auteursrecht van de ontwikkelaars die expliciet voor de GPL kiezen te respecteren.)

              Wat mijns inziens vooral tegen het principe van ‘vrijheid’ in gaat is dat een licentie van een externe component je gaat verplichten om alle onderdelen van je software, die je nu hebt en ook die je ooit in de toekomst nog gaat maken, ook onder die GPL te publiceren en daardoor dus ook alle denkbare software-oplossingen die daar weer op gebaseerd zijn hetzelfde te laten doen.

              Dat is natuurlijk binnen een bedrijfsomgeving niet houdbaar. Vooral als je met zaken als R&D bezig bent waarbij proprietary techniek wordt ontwikkeld, dan zou je dat als bedrijf verhinderen om óóit nog proprietary software uit te brengen als één onderdeel in de geschiedenis ooit onder de GPL is gebruikt. Daarom kiezen veel bedrijven niet voor software die onder de GPL is gelicenseerd.

              Dat staat natuurlijk even los van het feit dat veel open-source ontwikkelaars de juridische slagkracht missen om het tegen zo’n bedrijf op te nemen als er een inbreuk op de GPL plaatsvindt.

              • Ik hoor bij jou het “GPL=viral” argument, wat niet correct is. Je mag als auteur zelf kiezen onder welke licentie jij jouw eigen code verspreidt, en niets verbiedt je om een gebruiker van je code meerdere licentiekeuzes te bieden, of jouw code afhankelijk van de context onder verschillende licenties aan te bieden.

                Wanneer je een applicatie verspreidt met daarin GPL componenten van anderen, moet het geheel onder de GPL verspreid worden; maar jij mag de zelfgemaakte componenten uit die applicatie combineren tot een andere applicatie en verspreiden onder een licentie naar jouw keuze (rekening houdend met wat de licenties voor gebruikte third party code zeggen).

                • Dat gaat dus niet op. De GPL schrijft toch voor dat je, wanneer een code-component gebruikt wordt die een GPL licentie draagt, de hele applicatie moet publiceren met broncode? Zolang je dus die component (of een afgeleide daarvan) gebruikt, moet je de hele broncode publiceren van de applicatie die je aan wil bieden. Dat staat haaks op een bedrijf wat zijn werknemers een NDA wil afdwingen, immers, als je bedrijfsgeheimen code bevatten, mag je die niet publiceren. Ook als de GPL niet viral is (volgens mij ligt dat aan de versie van de GPL), is het een licentie die vrijheid af wil dwingen. En dat is per definitie al niet mogelijk.

                  • Ik ben het eens dat de GPL niet samengaat met “closed source” softwareontwikkeling. En de GPL heeft nooit “absolute vrijheid” (als dat al bestaat) geprobeerd af te dwingen, het probeert de ontvangers van de software aanzienlijke vrijheden te geven, ten koste van wat van de vrijheden van de auteursrechthebbenden. Een gekozen balans, waar sommige ontwikkelaars zich achter scharen, terwijl anderen kiezen voor het uitbrengen van software onder een andere (BSD-stijl) licentie.

                    • Ja, op zich is die balans er wel, mits het maar betrekking blijft houden op de aanpassingen die gemaakt worden op GPL code. Alleen gaat de GPL licentie verder dan dat en daar zit het probleem! Ik kan een project maken waarvan nog geen 1% uit GPL afkomstig is maar word daardoor wel gedwongen om het gehele project als GPL te publiceren. En dat is juist wat ik niet wil!

                      Als ik GPL code aanpas dan is het op zich prima als ik die aanpassingen vrij moet geven. Maar niet mijn totale project waar ik hard voor heb gewerkt! Dat is mijn code en niemand heeft het recht om de licentie van mijn code aan te passen! De GPL probeert dit min of meer wel af te dwingen. Vandaar ook dat dit op de zwarte lijst van voorwaarden behoort. Daarmee wordt de GPL meteen ook beter bruikbaar.

        • Een van de ideeen achter de GPL is het maken van Vrije Software te bevorderen.
          Bij de GPL heb ik meer het idee dat men Vrije Software probeert te verplichten ten koste van commerciële software. Eigenlijk is het vergelijkbaar met het afschaffen van copyright om zo al het auteursrechtelijke materiaal te bevrijden. Op zich prima, maar het zorgt er juist voor dat ontwikkelaars (en artiesten, auteurs, etc.) hun motivatie verliezen om goede producten te maken simpelweg omdat ze niet op een andere manier voordeel kunnen behalen uit hun werk.

          De BSD licentie is in dat opzicht vele malen beter omdat deze vrije software mogelijk maakt en desondanks toch bedrijven de mogelijkheid geeft om hun code geheim te houden en dus om code op commerciële wijze te gebruiken.

          En ja, Red Hat weet als een der weinige bedrijven winst te maken met behulp van GPL software. Dit doen ze niet met behulp van software maar die winst komt uit support die wordt geleverd bij de vele producten die ze ondersteunen. En daarmee hebben ze zelfs een beetje een monopolie-positie gekregen, samen met een paar andere distributeurs van Linux systemen. Het probleem is vooral dat de support-markt relatief klein is en weinig plek heeft voor kleine spelers. Het enige alternatief zijn weer de diverse Q&A sites zoals Quora en de StackExchange sites waar men gratis vragen kan stellen en (hopelijk) snel antwoord krijgt. Maar management gaat liever voor professioneel support dan ondersteuning vanuit deze gratis communities.

          Red Hat lijkt dan wel mooi, maar is feitelijk een valstrik omdat deze kleine organisaties de middelen ontneemt om hun werk goed te doen. Immers, die kleine bedrijven zijn vaak te klein om alleen via support winst te maken en kunnen daarnaast niet software verkopen omdat deze gebaseerd is op GPL code.

          Het enige wat ontwikkelaars dan kunnen doen is code ontwikkelen die geen GPL gebruikt. En er zijn hiervoor genoeg alternatieven maar het is tevens tijdrovend omdat je voor ieder stuk code dat je gebruikt ook moet uitzoeken of er geen enkel deel afkomstig is uit de GPL, omdat een stukje GPL code een compleet project kan besmetten. Dan liever wetgeving die eindelijk iets doet aan deze oneerlijke praktijk van de GPL licentie.

          Zoals ik al aangeef, het is onacceptabel dat het gebruik van een beetje GPL al meteen ervoor zorgt dat de rest van mijn werk ook opeens onder dezelfde licentie komt te vallen. Dat is wat mij betreft een voorwaarde die op de Zwarte Lijst behoort en dus niet afgedwongen kan worden.

      • En moet de broncode ervan gedeeld worden en kun je er b.v. geen commercieel product van maken.

        Ik ben geen fan van de GPL, maar dit is simpelweg onzin. Er staat niets in de GPL dat je ervan weerhoudt om een commercieel product ervan te maken. Wat het wel doet, is je ervan weerhouden om het closed-source te maken – maar dat is iets heel anders dan “commercieel”.

          • Dat is zeker niet “de enige inkomstenbron”, en je gaat er hier vanuit dat het standaard business model is om licenties op software te verkopen. Dit is al enkele jaren niet meer het geval, en is uberhaupt geen gezond business model, open-source of niet.

            Als jij graag licenties wilt verkopen, prima. Maar dat maakt niet dat je er door de GPL dus geen commercieel product van kunt maken; dat is enkel een gevolg van het business model dat je najaagt, niet van de licentie.

            • Da’s wel makkelijk gezegd maar het moet gewoon mijn keuze zijn en niet worden opgelegd door een licentie voor een klein stukje code dat toevallig onderdeel is van mijn project. Ook al is dit al t het geval”, het blijft nog steeds mijn keuze om mijn werk onder mijn licentie aan te bieden. En daarmee hoeft het niet eens om commerciële redenen te gaan! Als ik mijn project onder de originele BSD licentie wil publiceren dan kan dat eigenlijk ook niet, omdat de GPL daar niet mee compatible is. (Zegt GNU zelf!) En de BSD is best een populaire licentie. Net als de Apache licentie, overigens!

              De GPL is niet eens compatible met de JSON licentie, omdat de JSON licentie als extra conditie aangeeft dat je JSON niet misbruikt voor kwaadaardige doeleinden. En daar gaat de GPL niet mee akkoord…

              Het is mijn werk en ik bepaal onder welke licentie ik mijn werk vrijgeef. Het moet niet mogelijk zijn dat ik, omdat ik b.v. een GPL library gebruik om thumbnails van plaatjes te maken, mijn gehele project opeens vrij moet geven onder de GPL. In dat opzicht is de GPL dus incompatible met mijn werk. Het gaat er dus niet om dat ik licenties wil verkopen maar dat ik wil bepalen welke licentie van toepassing is op mijn werk!

              • Dat is echter een heel andere discussie dan het punt dat ik probeerde aan te stippen. Ik ben zelf ook absoluut geen fan van de GPL of gelijksoortige “virale” licenties, ik wilde enkel verduidelijken dat de GPL geen commercieel gebruik tegengaat (omdat dit een veelvoorkomende misvatting is).

                Wat betreft de JSON-licentie, dat is een beetje een verhaal apart. De JSON-licentie is sowieso helemaal geen open-source licentie, omdat het tegen punt 6 van de Open Source Definition aanloopt.

                Mijn voorkeurslicentie is nog altijd de WTFPL, welke ongeveer gelijk staat aan publiek domein. Ik beschouw copyright uberhaupt niet als een sociaal wenselijk iets.

                • Hoe dan ook, al die verschillende licenties doen me denken aan deze XKCD strip

                  Overigens mag OpenSource.org dan wel denken dat ze OpenSource kunnen definieren maar met hun definitie hoeft niemand het mee eens te zijn. Het enige is dat OSI wel of niet een licentievorm als Open Source kan bestempelen, maar iedereen kan hun eigen licentie gewoon open source noemen als ze de broncode ervan delen, ongeacht welke voorwaarden eraan zijn verbonden. De OSI probeert gewoon de definitie van Open Source te kapen om hun regels eraan op te leggen. En daarmee is het net als GNU bezig met een machtspel over welke licenties nu wel en niet acceptabel zijn.

                  En het gaat mij er niet om of het nu wel of niet commercieel is. Het gaat mij erom dat mijn werk onder mijn licentie behoort en dat niemand anders een andere licentie erop kan forceren.

                  • Iedereen is vrij om de licentie te kiezen die hij of zij wilt. Dat betekent dus ook dat de makers van GPL software vrij zijn om aan die software een GPL licentie te hangen. Niemand is natuurlijk verplicht om GPL software te gebruiken.

                    Je geeft aan (4 januari 2017 @ 19:01) dat graag GPL software wilt gebruiken, maar zonder dat jij verplicht bent om jouw software ook onder een GPL licentie uit te brengen en dat je wilt dat wetgeving hiervoor zorgt. Maar daarmee geef je wel aan dat je wilt dat anderen licentie voorwaarden krijgen opgelegd. En laat dat nu eens precies zijn wat je niet bevalt aan de GPL licentie.

  4. Het specifieke voorbeeld waardoor deze discussie is ontstaan komt door het volgfende voorbeeld: Ik ben actief geweest in de Chamilo community. Chamilo is een opensource Electronische Leer Omgeving en leunt sterk op PHP. Voor het indexeren van de content van leerobjecten wordt gebruik gemaakt van de php-xapian module. Nu bijt de licentie van PHP met de licentie van Xapian en daarom zit de php-xapian module dus niet in de repository van bijvoorbeeld Ubuntu. Nu ben ik voor een andere community (NethServer) bezig om een aantal educatieve modules te creëren. En om niet tegen problemen als bij php-xapian aan te lopen heb ik gevraagd ‘hoe het nu zit’.

    Dank voor de post Arnoud!

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