Opmerkelijk: de basisbouwsteen van vrijwel alle open source blijkt nooit 100% open source te zijn geweest. Pas vorige week is de GNU C Library (glibc), de standaardbibliotheek voor Linuxapplicaties, ontdaan van een stukje antieke code die voorzien was van een licentie die niet voldeed aan de definitie van open source.
Glibc is een onderdeel van Linux dat door vrijwel elke applicatie wordt gebruikt. Deze bibliotheek implementeert alle standaardfuncties uit de programmeertaal C. De licentie is de Lesser GPL, die toestaat om applicaties te maken zonder dat die zelf ook weer open source moeten worden. Maar enkele jaren terug werd ontdekt dat er code in zat die stiekem eigenlijk niet open source was.
Nu was die code uit 1984, toen het hele idee van open source nog niet bestond. De bedrijfsjuristen van Sun Microsystems, die de code had uitgebracht, hadden dan ook hun eigen tekst verzonnen die op zich best liberaal en netjes was:
Sun RPC is a product of Sun Microsystems, Inc. and is provided for unrestricted use provided that this legend is included on all tape media and as a part of the software program in whole or part. Users may copy or modify Sun RPC without charge, but are not authorized to license or distribute it to anyone else except as part of a product or program developed by the user.
(inderdaad, tape media)
Het stukje in italics leverde het pijnpunt op: open source moet op elke mogelijke manier kunnen worden hergebruikt, niet alleen als onderdeel van een groter product. Omdat je dit stukje code van Sun niet op zichzelf mag doorverkopen, is het geen open source, en het kan dan dus ook niet opgenomen worden in glibc.
Dat is best wel een probleem voor zo’n belangrijk en essentieel stuk software. Oplossen is echter lastiger dan je zou denken, zoals Simon Phipps aangeeft, want:
- Waar komt de code vandaan?
- Wie heeft deze geschreven, en was die persoon in dienst bij het bedrijf of een leverancier of inhuurkracht?
- Wie is tegenwoordig verantwoordelijk voor deze code en mag beslissen dat deze open source wordt?
In dit specifieke geval was de uploader Sun nog wel te vinden, maar moest er in een papieren archief worden gedoken om te achterhalen waar de rechten lagen. En dat werd nog eens extra moeilijk omdat de nieuwe eigenaar van Sun (Oracle) druk bezig was met afhandelen van de aankoop en alle juristen in de “geen commentaar”-modus zaten.
Alles bij elkaar duurde het meer dan een jaar om de wijziging door te voeren. Maar het ís gelukt, en dat is wel een complimentje waard.
Arnoud<br/> Foto: GNU C Library handleiding, Free Software Foundation.
Ben zeer te spreken over Open Source. Kwaliteit is zeer hoog. Gebruikersgemak doet niet onder aan andere wijze van distributie. Toegankelijkheid is groot. Bevordert innovatie en creativiteit. Bevordert productie. Bespaart kosten. Open Source is in mijn ogen de basis voor de dynamische kenniseconomie die Europa ambieert. Open Source hoort standaard te zijn in het onderwijs, thuis en elders.
@jdk Helemaal mee eens, en officieel is het allang overheids beleid om waar mogelijk open source toe te passen. Maaar ik werk al jaren voor RWS en ik ben nog nergens een Linux machine tegen gekomen.
Maar, als Arnoud het er niet meteen af haalt, wil ik hier graag even een beetje reclame maken.
Komt allen naar de Software Freedom Day op 18 september in de Koninklijke Bibliotheek in Den Haag! http://www.sfd2010.nl/
In de Open Source Definition van OSI lees ik:
Het lijkt mij dat de RPC license en de Open Source Definition op dit punt niet strijdig zijn.Tenzij men aanstoot geeft aan “as part of a product or program developed by the user,” wat je strikt genomen zou kunnen interpreteren als een vereiste dat je de RPC code alleen op kunt nemen in een programma wat je 100% zelf ontwikkeld hebt. Maar die interpretatie lijkt me wat onwaarschijnlijk.
De OSI definitie #1 zegt dat het niet verboden mag zijn om de software te bundelen. De Sun RPC voorwaarden zeggen dat je de software alleen gebundeld mag verspreiden. Er is dus geen tegenspraak hier, maar wat ontbreekt is het recht om de software zonder bundel te verspreiden.
Arnoud: waar lees je dan in de OSI definitie dat het verspreiden van de software zonder bundel toegestaan moet zijn?
Het is een interpretatie van punt 8 van de OSD: http://www.opensource.org/docs/osd
Je mag het eens of oneens zijn met de interpretatie die debian-legal aan dit punt geeft, maar zij zijn al jaren de hoeders van de DFSG, de voorloper van de OSD.MathFox: de DFSG staan wat mij betreft los van de vraag of de RPC licentie strijdig is met de definitie van Open Source. Ik twijfel er niet aan dat RPC geen vrije software in de zin van de Free Software Definition en de DFSG is.
De gehele tekst van de Open Source Definition punt 8 luidt:
Als je de eerste zin op zichzelf leest dan kun je inderdaad beargumenteren dat het vereiste dat je de RPC bundelt strijd oplevert met punt 8. Overigens kun je twisten over de betekenis van het woord ‘particular’, dat m.i. bedoeld is om te voorkomen dat een auteur zegt: je mag mijn bewerkte RPC code alleen verspreiden met de officiele release op mijn website.Maar het lijkt mij dat de tweede zin van punt 8 als verduidelijking dient van de eerste zin. De RPC licentie lijkt mij te voldoen aan het vereiste van die zin.
bastiaan, we kunnen een discussie aangaan over hoe de OSD in de context van de RPC libraries gelezen moet worden. Jouw opvatting is naar mijn mening meer valide dan die van degenen die om de licentiewijziging gevraagd hebben; ik rapporteerde slechts hun mening in deze.
MathFox: in de referenties van Arnouds post zie ik alleen Phipps’ artikel dat vermeldt dat de RPC licentie strijd oplevert met de OSD, maar hij legt niet uit waarom. Is er ergens anders nog een aparte discussie over de OSD gevoerd?
@bastiaan: ik vermoed eerlijk gezegd dat de problemen meer kwamen doordat deze licentie niet LGPL-compatible is. Immers LGPL software mag je als zodanig doorverkopen en -leveren, en deze licentie zegt van niet. Dat kan dus niet in een project dat LGPL is.
Arnoud: de term LGPL-compatible heb je hier denk ik wat ongelukkig gekozen, want de LGPL staat juist toe dat je de LGPL-code bundelt met andere niet-LGPL code. In die zin is (vrijwel?) elke licentie LGPL-compatible. De LGPL vereist niet dat alle onderdelen van een ‘library’ dezelfde licentie hebben.
Ik denk dat de RPC-licentie gewoon een Open Source licentie is, in de zin van de Open Source Definition. Glibc is dus altijd al Open Source geweest.
Het nieuws is dat Glibc nu ook vrije software is geworden.
Bastiaan: wat je zegt is op zich waar maar geldt niet voor dingen die je in de LGPL-licensed library stopt. Alleen voor dingen die je linkt met de library geldt dat je die onder eigen licentie mag uitbreiden. Ga je de broncode van de library zelf aanpassen, dan moet dat LGPL worden.
En wat MathFox al aangeeft, het hangt er maar vanaf hoe je de OSD (=DFSG met een s/Debian/Open Source/g) nu precies leest.
Arnoud: het hangt er maar vanaf wat je onder ‘de library’ verstaat. Zie LGPL sectie vijf:
Je kunt Glibc (voorheen) dus zien als een gecombineerde library van een LGPL onderdeel en een niet-LGPL onderdeel (RPC). Ik denk dat het niet zo lastig is om de RPC code als aparte faciliteit te zien.
Ik denk dat de FSF liever alleen GPL compatible licenties ziet en andere open source licenties niet als open source beoordeelt.
Ik denk dat de FSF je gaat vragen je mond te spoelen als je in hun bijzijn “open source” zegt. 🙂