Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 22 reacties
Bron: ZDNet, submitter: Longbeard

ZDNet meldt dat een klein conflict over licenties tussen Intel en de Linux community - in het bijzonder RedHat - is opgelost. Het probleem was ontstaan rond een project van Intel wat zich bezighield met de ontwikkeling van een ACPI interpreter. Dit project werd tot op heden onder twee verschillende licenties ontwikkeld, te weten de alom bekende General Public License (GPL) en de 'Component Architecture' licentie, een 'gesloten' licentie van Intel. De reden om het project onder twee verschillende licenties uit te brengen is dat Intel ontwikkelaars van besturingssystemen de mogelijkheid wil geven de software in hun OS te implementeren onder een bijpassende licentie. Zo kan in Linux bijvoorbeeld de open-source-GPL worden gebruikt.

Intel logo bij Intel gebouwHet probleem bestond nu uit het feit dat Red Hat wilde bijdragen aan de ontwikkeling van het project in de vorm van patches. Deze patches werden uiteraard onder de GPL uitgebracht. Eťn van de restricties van de GPL is dat software die eenmaal onder deze licentie valt, niet meer onder een 'gesloten' licentie kan vallen. De patches van RedHat konden dus niet direct worden doorgevoerd op het deel wat valt onder de component architecture licentie. Na de nodige discussie heeft Intel nu besloten het GPL-deel onder een andere licentie te laten vallen, te weten de BSD-licentie. Deze laatste is minder strict dan de GPL, echter is wel open source. Hiermee is het probleem dus opgelost.

ACPI staat voor Advanced Configuration and Power Interface en maakt het ondermeer mogelijk om uitgebreide stroombesparende maatregelen van een computer aan te sturen, waarmee het deels als vervanger van APM (Advanced Power Management) dient. Het project van Intel maakt op dit moment deel uit van de Linux-kernel, die in principe geheel onder de GPL valt. Op de mailinglist van de kernel werd korte tijd moeilijk gedaan over het feit dat er nu een klein deel onder de BSD-licentie zou vallen. Dit is echter volgens enkele prominenten van de Linux-community geen probleem, aangezien er al meer onderdelen zijn die onder een andere licentie vallen dan de GPL. Enkele personen suggereerden dat ontwikkelaars Intel zou kunnen dwingen hun ACPI patches niet onder de gesloten licentie konden worden gebruikt door de losse patches te laten vallen onder de GPL. Linus Torvalds, de bedenker van Linux, deed deze mogelijkheid echter afwimpelen met de volgende opmerking:

In fact, I don't think I'd even merge a patch where the submitter tried
to limit dual-license code to a simgle license (it might happen with
some non-maintained stuff where the original source of the dual license
is gone, but if somebody tried to send me an ACPI patch that said "this
is GPL only", then I just wouldn't take it).

[...] Somebody else can go off and make their own GPL-only additions, and
quite frankly I would find it so morally offensive to ignore the intent
of the original author that I wouldn't take the code even if it was an
improvement (and I've found that people who are narrow-minded about
licenses are narrow-minded about other things too, so I doubt it _would_
be an improvement).

Moderatie-faq Wijzig weergave

Reacties (22)

Na de nodige discussie heeft Intel nu besloten het GPL-deel onder een andere licentie te laten vallen, te weten de BSD-licentie.
Waarom niet de LGPL licentie? Die is praktisch hetzelfde als de BSD licentie.
Waarom niet de LGPL licentie? Die is praktisch hetzelfde als de BSD licentie
Dan moet je je toch even beter verdieppen in licentie's

Code onder de BSD licentie mag worden gebruikt in closed source producten en veranderde code hoeft niet te worden terug gegeven, code onder de LGPL mag niet in closed source producten worden gebruikt maar mag alleen als library (daar staat de laatste L in LGPL voor) worden aangeroeppen, tevens moetten verandering van code onder de LGPL worden terug gegeven.
...maar mag alleen als library
Niet helemaal.

Bij de LGPL is het linken van niet-(L)GPL software tegen LGPL software toegestaan. Maar onder linken valt ook statically linken, en dan kun je niet echt meer van een library spreken.
(daar staat de laatste L in LGPL voor)
Je bedoelt neem ik aan de eerste L? En zelfs die staat niet voor "library". LGPL staat voor "Lesser General Public License". bron.
Je bedoelt neem ik aan de eerste L? En zelfs die staat niet voor "library". LGPL staat voor "Lesser General Public License"
Je hebt helemaal gelijk, mijn fout.

Maar de essentie van het verhaal, het verschil tussen BSD en LGPL, blijft instand.
De L stond vroeger voor Library, maar staat nu voor 'Lesser', feitelijk betekent het dat producten hieronder wel binnen closed source eind-producten mag worden toegepast, echter de LGPL-gelicenseeerde onderdelen vallen onder openbaringsvoorwaarden zoals deze in de GPL staan, het bedrijf is verplicht De Lesser GPL-gelicenseerde code zoals deze is toegepast te publiceren en als source downloadable te maken, ook wanneer zij er wijzigingen in aanbrengen.

veranderde Berkeley-style licensed code kan in een gesloten source-product worden toegepast zonder dat een bedrijf de verplichting heeft de wijzigingen te publiceren.
Die is praktisch hetzelfde als de BSD licentie
Nou dan, dan boeit het ook niet welke je pakt. ;)
Dit laat weer eens duidelijk zien dat voor een goede samenwerking tussen open source en closed source de BSD licentie veel geschikter is dan de GPL.
Dat weet ik zo net nog niet, de GPL zorgt er namelijk voor dat veel hackers mee gaan doen aan projecten, omdat die niet misbruikt kunnen worden door commerciele closed source software makers, bij de BSD licensie is dat misbruik er wel en zullen er minder mensen zijn die mee willen werken (wat juist een van de voordelen van OSS development is)
Als Intel zo graag de source beschikbaar wil stellen aan zowel commerciele bedrijven met proprietary software als aan de Free software community, dan vraag ik me een beetje af waarom ze niet meteen voor een BSD-style license zijn gegaan.

Behalve het vermelden van copyright en nog wat kleine dingetjes mag je met software onder een BSD-style license alles doen wat je wil. Zo had ťťn license kunnen volstaan voor zowel bedrijven als de Free software community.
En dat nu juist wilden ze voorkomen; een gesloten ontwikkelingsomgeving voor de windows-aanhangers en een open omgeving voor de Linux-aanhackers :)

Zo kunnen ontwikkelingen in GPL snel via BSD worden overgezet naar de gesloten versie. De ontwikkelaars van de gesloten versie staat het ook vrij het onder BSD uit te brengen, zodat het in de GPL mee kan. Alleen acht ik die kans wat kleiner.

Op deze manier profiteert de gesloten omgeving toch van GPL; iets wat enkel positief kan zijn: lees Thorvald's opmerking.
is er ergens een site met de omschrijving van GPL/BSB/etc die een beetje toegankelijk is?
GPL:

http://www.gnu.org/copyleft/gpl.html

Alle andere licenses (ook GPL btw) kunnen hier worden gevonden ;)
http://www.opensource.org/licenses/
Ga nou eerst een ontdekken wat de software is en dan pas jezelf druk maken of het GPL, of neen, liever BSD of dan toch LGPL....

Beoordeel de software voor wat het is en ga dan pas kijken of je verkiest om er voor te ontwikkelen, dit License Shopping vindt ik ergerlijk.

Torvalds heeft wel gelijk...
Uhm,

bertstevens vraagt alleen maar om omschrijving van licenses ... niet over deze software volgens mij :?
..........I wouldn't take the code even if it was an
improvement (and I've found that people who are narrow-minded about
licenses are narrow-minded about other things too, so I doubt it _would_
be an improvement).


Voor aan de muur, zo'n uitspraak !
Zonder meer een goede zaak.
Zo blijkt maar weer dat ook de grote producenten van componenten de Linux-boys als "echte" vakmensen zien, en de dingen die ze doen serieus nemen. Als MS doorgaat op de manier waarop ze op dit moment bezig zijn, gaan de Linux-boys een aardig stuk groter worden dan ze nu al zijn.
Ik zie MS nergens vermeld in dit verhaal... maar goed, al zouden ze ergens vermeld zijn, wat heeft dat dan voor invoeld op de "linux-boys" ?? Wie is dat dan? Kom op man dit lijkt wel een voetbal stadium hier..
en los d'r van: dit limiteerd zich niet alleen tot de 'linux' crew, maar strekt tot de gehele opensource (denk aan *bsd en al die anderen) community.

Ik snap Linus z'n uitspraken ook wel, hij is juist heel blij met die dual-licence zaken in de kernel, aangezien zo de gehele opensource gemeenschap aan het samenwerken is. Het gebeurt geregeld dat BSD autheurs iets poorten naar de Linux kant en andersom.

sure, de BSD license geeft mij theoretisch het recht de hele meuk direct weer te veranderen van licentie, dus ook naar bijvoorbeeld een closed-source licentie, zonder dat ik 1 bit code heb veranderd. Maar dit is simply 'not done'. Zelfs microsoft doet dat niet. (en die gebruikt redelijk wat *BSD code in windows inmiddels)
In reactie op Den Dave:

MS staat inderdaad nergens in dit verhaal vermeld.
Wat ik er mee bedoelde te zeggen was dat juist door dit soort overeenkomsten, en de manier waarop diegenen die Linux-distributies maken of zich er mee bezig houden op het moment zeer regelmatig positief in het nieuws komen, er toch steeds meer mensen de overstap zullen gaan maken. Linux begint meer algemeen goed te worden, i.p.v. dat het een OS is voor "freaks".
En Linux-boys was gewoon een algemene benaming die ik makkelijk en korter vond als : diegenen die zich met Linux-ontwikkelingen bezig houden of er distributies van maken.
waar je je al druk om kan maken zeg :?
Zoiezo een mooie zaak, zo zijn alle geschillen opgelost en is er een degelijke compromis gesloten...

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True