Opensourcebibliotheek Glibc nu eindelijk open source

gnu-c-library-glibc-software-library-bibliotheek-linken.pngOpmerkelijk: 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:

  1. Waar komt de code vandaan?
  2. Wie heeft deze geschreven, en was die persoon in dienst bij het bedrijf of een leverancier of inhuurkracht?
  3. 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.

15 reacties

  1. 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.

  2. @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/

  3. 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.

    In de Open Source Definition van OSI lees ik:

    1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
    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.

  4. 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:

    8. License Must Not Be Specific to a Product The rights attached to the program must not depend on the program???s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program???s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
    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.

  5. 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.

  6. 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?

  7. 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.

  8. 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.

  9. Arnoud: het hangt er maar vanaf wat je onder ‘de library’ verstaat. Zie LGPL sectie vijf:

    5. Combined Libraries. You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do …

    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.

Geef een reactie

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