OpenSSL wil verder onder Apache 2.0-licentie, mag dat?

| AE 9339 | Open source | 13 reacties

Het OpenSSL-project wil overstappen van zijn eigen gebruikslicentie naar de Apache 2.0-licentie. Voor de overstap is de goedkeuring nodig van iedereen die als auteur mee heeft gewerkt aan de code van OpenSSL. Dat meldde Tweakers zaterdag. Het opensourceproject heeft een simpele BSD-achtige licentie maar met een irritante advertising-clausule, waar men nu vanaf wil. En overstappen naar de zeer standaard en breed gedragen Apache licentie ligt dan voor de hand. Alleen, krijgen ze dat voor elkaar?

OpenSSL is een veelgebruikte library voor het opzetten van beveiligde internetverbindingen. Het project is relatief oud: in 1998 verscheen de eerste versie van de software. Het concept open source was toen vrij nieuw, en daarom hanteerde men een eigen licentie die net even anders was dan andere. In principe is de licentie gelijk aan de BSD licentie, zij het ook wordt vereist dat alle advertenties voor afgeleide werken vermelden:

[T]his product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit

Dit is op zichzelf hooguit een tikje irritant maar de specifieke formulering van deze clausule maakte OpenSSL notoir GPL-incompatibel. En dat is vervelend als je bedenkt hoe veel GPL software er is die op zich best SSL-functionaliteit zou kunnen gebruiken. (Het GNU TLS project van later datum was er denk ik niet gekomen als OpenSSL deze bepaling niet had gehad.) Daarnaast is er nog een ambigue formulering in de licentie die de indruk wekt dat je de code niet mag integreren in een groter werk dat onder een andere licentie aangeboden wordt, wat volgens mij juridisch niet klopt maar goed discussie hou je altijd.

Het is dus méér dan de hoogste tijd voor het project om over te stappen naar iets moderns, en de Apache 2.0 is een prima keuze in dat verband.

Alleen, dat is een tikje ingewikkeld bij zo’n oud project want relicensing kan alleen als je van alle auteursrechthebbenden op de code toestemming hebt. En vind die maar eens na 20 jaar; het zou gaan om zo’n 1.000 mensen, volgens Tweakers.

Begrijpelijk dan ook dat het project heeft gekozen voor stilzwijgen is toestemming (als ik het goed lees, ik kan in het persbericht dit niet expliciet vinden). In theorie kan dat ook; vrijwel elk rechtsstelsel (ook Nederland) erkent dat rechtshandelingen door stilzwijgen kunnen worden verricht, zij het dat er vaak wel hoge eisen gelden aan duidelijkheid en intentie. Dat maakt het vaak lastig om (afgezien van zeer evidente situaties) je te beroepen op stilzwijgen als toestemming.

Hier zou die toestemming dan verkregen worden door naar het laatst bekende mailadres te mailen “Wij gaan uw code Apache 2.0 maken, graag reageren als u dat niet wilt”. Daar zit genoeg foutmarge in: het mailadres werkt niet meer, mail wordt stilletjes weggegooid, men wilde wel reageren maar de reactie kwam niet aan, de partij in kwestie ligt in het ziekenhuis en zijn mail stapelt zich op, en ga zo maar door. Dus of dat juridisch houdt, betwijfel ik.

Maar ja, wat moet je anders? De enige echte optie is dan om alle code te herschrijven waarvan geen expliciete toestemming is verkregen tot herlicentiëring. Dat lijkt me een hele bak werk, waar weinig eer aan te behalen valt.

Arnoud

Deel dit artikel

    • Ik kan me haast niet voorstellen dat er auteursrecht zit op het corrigeren van spelfouten. Ook het veranderen van 0 naar null lijkt me niet iets waar auteursrecht op kan zitten. Verder wel een terechte vraag overigens want ergens is er een scheidslijn dat het wél beschermd wordt.

      Overigens is delen herschrijven vrijwel onmogelijk als je dat zou moeten doen zonder naar de oude code te mogen kijken. De nieuwe bugs die je gaat introduceren zullen zoveel kwaad doen aan de reputatie dat je het project wel kan opheffen.

      • Persoon 1 kijkt wat een stukje code doet: Neem een FQDN en haal hieruit de domeinextensie. Persoon 2 schrijft een paar regels code die dit puur uitvoert en geeft die aan persoon 1. Aangezien persoon 2 nooit de oorspronkelijke code gezien heeft, zit je toch veilig en kun je zeggen dat die code door Persoon 2 geschreven is? Ik geef toe: veel werk.

        Edit: In C(++/#) zit er best veel verschil tussen het getal 0 en de lege waarde null. (Alleen lijkt het in het Nederlands zo verrekte veel op elkaar)

    • Code is auteursrechtelijk beschermd als deze het resultaat is van een eigen creatieve keuze van de programmeur. Er moet dus ruimte zijn om creatief een invulling te geven aan de functionele eis. Corrigeren van een spelfout of tikfout levert daarom géén auteursrecht op, want een correctie kan maar op één manier. Een rewrite zou wel beschermd kunnen zijn omdat je dan op een eigen nieuwe manier het probleem op gaat lossen.

      Heel soms is ook het programmeren zelf niet beschermd. Denk aan een embedded omgeving waar maar zeer weinig instructies mogelijk zijn, en de invulling eigenlijk automatisch volgt uit de functionele eisen. Een lampje aan laten gaan als de temperatuur van de motor boven de 80 graden komt, dat kan maar op één manier worden geprogrammeerd.

    • Een wijziging moet creatief zijn om er auteursrecht op te laten gelden, een voor de hand liggende bugfix voldoet niet aan het criterium. Je kunt daarmee de kleinste bijdragen op de hoop gooien van “niet auteursrechtelijk beschermd, mening van de contributor is irrelevant voor de licentiewijziging.”

      Daarna komt een groep van auteurs met bijdragen die wel auteursrechtelijk beschermd zijn, maar die door een goede ontwikkelaar binnen een paar uur of dagen herschreven zijn. Je kunt als project het risico nemen dat een auteur (of erfgenaam) plotseling opduikt en gaat klagen en dan zijn code uit het project schrijven. Ik verwacht dat een redelijke schadevergoeding voor Open Source code die onder een incompatibele Open Source licentie verspreid wordt op nul uitkomt.

      Bij de auteurs die een grotere bijdrage gedaan hebben aan het project zou ik de nodige moeite doen om expliciete toestemming voor de licentiewijziging te krijgen; maar dat is een hele beperkte groep. (Minder dan 100 personen.)

    • Die hack was alleen mogelijk doordat je je werk vrijgaf onder ‘GFDL 1.2 of later’. Vervolgens is in een nieuwe versie van de GFDL (1.3) de mogelijkheid ingebouwd om van licentie te switchen, en zodoende kon ook de originele code van licentie switchen. In het geval van OpenSSL is er niet een dergelijke ‘X of later’ clause, en is deze truc niet mogelijk.

  1. De stilzwijgende tot stand gekomen rechtshandelingen die ik ken zijn allemaal vooraf afgesproken. Stel dat praktische bezwaren als het e-mail adres werkt niet meer doen zich niet voor en de mail komt in de inbox terecht, hoe zou zo iets hier werken?

    Stel twee programmeurs hebben samen een software pakket geschreven, waaruit blijkt dan de wil van de tweede programmeur als de eerste schrijft: “Ik ga uw code Apache 2.0 maken, graag reageren als u dat niet wilt”?

  2. Tsja. Voeg maar toe aan de lijst van foutmarge: wat als de ontwikkelaar overleden is? Er van uitgaan dat de nabestaanden de mail doorgestuurd krijgen???

    Maar ik kan me nog wel wat ergers bedenken dat die lijst van foutmarge. Als ik de “mens” een beetje begrijp, is het vrijwel uitgesloten dat werkelijk NIEMAND tegen is. There is always ‘that guy’.

  3. Bij de meeste open source projecten wordt de kar getrokken door één, of hooguit een paar personen; ik geloof dat dat bij OpenSSL ook zo is. De auteurs van 90% van de code moeten dan vrij makkelijk te vinden zijn, zeker als je al sinds dag 1 een versiebeheer-systeem gebruikt. Een deel van de code is wellicht gekopieerd uit andere free software projecten; daarbij moet je even uitzoeken of de oorspronkelijke licentie compatibel is (waarschijnlijk wel). Met wat mailen moet je waarschijnlijk expliciete toestemming kunnen krijgen van 90% van de rest, zodat je nog maar 1% over houdt. Die 1% moet je dan wat beter naar kijken; het meeste bestaat waarschijnlijk uit niet-beschermbare bugfixes op code die oorspronkelijk door het “core team” werd geschreven. Misschien houd je dan maar 0.5% o.i.d. over die herschreven of verwijderd moet worden.

  4. Ik ben wel nieuwsgierig naar wat men gaat doen indien diverse auteurs gewoon geen toestemming geven. (Behalve dan tegen een eventuele vergoeding.) Ook dan zou men grote delen moeten herschrijven waarbij het nog een grote klus kan worden om te bepalen wat iedere auteur uiteindelijk heeft geschreven… Ik ben dus wel benieuwd naar hoe men dat oplost.

  5. Mozilla heeft een ~10 jaar geleden ook eens een zeer ambiteuze relicensing uitgevoerd op de gehele codebase, en toen daadwerkelijk alle contributors opgespoord. Iirc zijn ze daarin geslaagd op een miniem aantal mensen na; de code van die mensen is vervolgens verwijderd/vervangen, danwel via het cleanroom principe opnieuw geïmplementeerd. Zie https://www-archive.mozilla.org/MPL/relicensing-faq.html voor meer details over dit alles.

  6. Een andere complicatie is dat de auteur niet altijd de rechthebbende is. De meeste patches die ik instuur naar opensourceprojecten zijn van mijn werkgever, niet van mij persoonlijk. Ook als er ik@github.com of zo iets als auteursnaam bijstaat. Misschien kun je aannemen dat door het insturen van die patch de ontvanger mag aannemen dat ik in zo’n geval dat blijkbaar namens mijn werkgever mag doen, dus ook blijkbaar namens mijn werkgever akkoord mag gaan met zo’n rechtenwijziging als ik dat vervolgens doe, maar als het gaat om een patch die gedaan is door iemand die intussen niet meer voor dezelfde werkgever werkt kan dat lastig worden. Ik ben benieuwd hoe Mozilla dat heeft opgelost.

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