GNU Lesser General Public License

Van Wikipedia, de gratis encyclopedie
Spring naar navigatie Spring naar zoeken
Het licentielogo van de LGPLv3
Het GNU-logo

De GNU Lesser General Public License of LGPL (voorheen de GNU Library General Public License ) is een licentie voor vrije software die is ontwikkeld door de Free Software Foundation (FSF). De LGPL stelt ontwikkelaars en bedrijven in staat om LGPL-software te gebruiken en te integreren in hun eigen (zelfs propriëtaire ) software zonder gedwongen te zijn de broncode van hun eigen softwareonderdelen vrij te geven vanwege een sterk auteursrecht . Eindgebruikers hoeven alleen de LGPL-softwareonderdelen te kunnen wijzigen: daarom worden bij propriëtaire software de LGPL-onderdelen meestal gebruikt in de vorm van een dynamische programmabibliotheek (bijv. DLL ) om de noodzakelijke scheiding te bereiken tussen propriëtaire en open source LGPL - om delen mogelijk te maken.

De LGPL is dus ontwikkeld als een compromis tussen de sterke copyleft van de GNU General Public License (GPL) en meer permissieve licenties zoals de BSD-licenties en de MIT-licentie . Het woord "Lesser" (wat "minder" betekent ) in de naam van de licentie is bedoeld om uit te drukken dat LGPL de eindgebruikers geen volledige vrijheid in het gebruik van software kan garanderen, aangezien alleen de LGPL-onderdelen, maar geen eigen software Share eindgebruikers de vrijheid om te wijzigen.

De LGPL werd in 1991 gepubliceerd en nam onmiddellijk aan dat versie 2 numeriek overeenkwam met GPL-versie 2. In 1999 werd de LGPL enigszins gewijzigd en voorzien van een versie 2.1, en de naam werd omgedoopt tot de GNU Lesser General Public License om het standpunt van de FSF tot uitdrukking te brengen dat niet alle bibliotheken de LGPL zouden moeten gebruiken. Versie 3 van de LGPL is in 2007 uitgebracht om te voldoen aan de aanvullende rechten van GPL Versie 3.

De LGPL wordt voornamelijk gebruikt voor softwarebibliotheken, maar ook bij stand-alone software.

Voorwaarden / technische conformiteit

In tegenstelling tot de GPL mag gesloten (dwz propriëtaire ) code ook worden gecombineerd met de LGPL-code met de LGPL, maar alleen als aan de volgende voorwaarde is voldaan: Een programma dat LGPL-code samen met zijn eigen propriëtaire code gebruikt, moet hierin worden gestructureerd manier dat elke eindgebruiker de open source LGPL-code (of gewijzigde versies daarvan) (zelfstandig) kan koppelen aan het uiteindelijke programma. [1] Dit kan worden gedaan door middel van dynamische koppeling (waarbij de LGPL-code wordt gebruikt in een dynamische bibliotheek); De eindgebruiker kan dan zijn eigen dynamische bibliotheek (Linux-jargon: Shared Object ) van het LGPL-gedeelte maken (bijvoorbeeld van een aangepaste versie van de LGPL-code) en deze gebruiken. Of het kan worden gedaan door statische koppeling - dan krijgt een eindgebruiker meestal de objectbestanden (of brontekst) van de propriëtaire code en de bronteksten van de LGPL-code en kan deze aan elkaar koppelen.

Deze voorwaarde is zodanig dat de gebruiker in staat moet zijn het LGPL-deel te wijzigen en opnieuw te integreren en daarin niet beperkt te worden; dus installatie-informatie moet aan de gebruiker beschikbaar worden gesteld om een ​​aangepaste versie van het LGPL-onderdeel in het gecombineerde werk te kunnen installeren en uitvoeren; Verder mag het de gebruiker niet worden verboden om wijzigingen in het LGPL-onderdeel te debuggen, inclusief reverse engineering .

Gewoonlijk koppelt de fabrikant van propriëtaire software zijn programma dynamisch aan de betreffende LGPL-bibliotheek. Hierdoor bevat de software een duidelijke scheiding tussen de LGPL-code en het propriëtaire gedeelte.

Voorbeelden van bibliotheken onder LGPL zijn de standaardbibliotheken van de afzonderlijke programmeertalen, zoals glibc (implementatie van de Standard C Library van de Free Software Foundation) of de GnuMP- bibliotheek.

Voor een C++-bibliotheek die veel inline- functies en klassensjablonen gebruikt, wordt meestal een licentie gekozen die minder beperkend is (voor eventuele externe ontwikkelaars) dan LGPL, op voorwaarde dat de bibliotheek samen met een vergrendeld (eigen) codedoel kan worden gebruikt. In dit geval moet de propriëtaire code al de inline-functies bevatten en moet de sjablooncode van de bibliotheek enz. al in de broncode zijn opgenomen. [2] Een voorbeeld is libstdc ++ (GNU C ++ Library), die tal van inline-functies en sjablonen gebruikt: Hier hebben de ontwikkelaars van libstdc ++ gekozen voor een GPL-licentie met een speciale toevoeging, [3] waarmee de ontwikkelaar om libstdc++ te gebruiken om te mixen met je eigen code, waarbij je eigen code niet onder GPL of LGPL hoeft te staan ​​(maar dat mag natuurlijk wel). In dit geval is er met name geen vereiste dat een eindgebruiker de libstdc++-bibliotheek in een gewijzigde vorm (statisch of dynamisch) moet kunnen koppelen en is daarom minder beperkend dan de LGPL met betrekking tot propriëtaire ontwikkelaars die de bibliotheek gebruiken .

Wel geldt het principe dat eventuele wijzigingen aan LGPL-onderdelen zelf (mits de wijzigingen niet uitsluitend voor eigen gebruik zijn aangebracht, maar als programma worden verkocht of op welke manier dan ook worden doorgegeven) altijd toegankelijk moeten worden gemaakt voor eindgebruikers. Openbaarmaking van uw eigen code, die onafhankelijk is van de LGPL-code, is alleen nodig als de gehele software broncodedelen bevat (of daarop is gebaseerd) die onder de GPL-licentie vallen en dus onder het copyleft- principe vallen.

De LGPL bevat een optie om een ​​aangepaste versie van software onder de GPL te publiceren. Dit geeft vrije software programmeurs de mogelijkheid om hun extensies te publiceren onder een copyleft licentie als ze dat willen.

Zie ook

web links

Individueel bewijs

  1. GNU Lesser General Public License, versie 3.0 ( niet-officiële Duitse vertaling )
  2. Veelgestelde vragen over GCC
  3. libstdc ++ Runtime Library-uitzondering