Nieuw systeem voor codewijzigingen Linux-kernel

Open Source Development Labs (OSDL) heeft vandaag laten weten dat er een nieuw systeem in gebruik is genomen om informatie over wijzigingen bij te houden in de codebase van de Linux-kernel. Om code toe te kunnen voegen is het noodzakelijk dat de betreffende ontwikkelaar met een zogenaamde Developer's Certificate of Origin (DCO) akkoord gaat. In dit certificaat is ondermeer vastgelegd dat erkenning zal worden gegeven aan ontwikkelaars voor bijdragen en afgeleide werken. Dit wordt voornamelijk vormgegeven doordat de ontwikkelaar toestemming geeft om de broncode onder enkele open-sourcelicenties vrij te geven. Het voornaamste doel van het DCO is het voorkomen van vragen of rechtszaken over code in de Linux-kernel.

Het nieuwe systeem zal echter niet helpen om antwoorden te geven op vragen over de herkomst van de huidige code. Bij die code is de nieuwe informatie vanzelfsprekend nog niet aanwezig. De verwachting is dat deze wijziging grote invloed zal hebben op de release van versie 2.7 van de Linux-kernel, die over een jaar verwacht wordt. De aanklachten van SCO zijn overigens niet de enige reden voor deze wijziging. Ook het feit dat steeds meer bedrijven en overheden Linux gaan gebruiken is een reden. Deze instanties willen namelijk als een van de onderdelen van de documentatie zien waar code vandaan komt, wie ermee bezig is geweest en wat er toen is veranderd.

Reacties (22)

[BartOtten]

Dit is een hele goede stap. Credits voor de coders en een sterke troef in de handen van de basic-ontwikkelaars. Dit systeem hadden ze al veel eerder moeten hebben.
Wat ik me dan wel afvraag : hoe lang is die lijst over 20 jaar? Als er elke keer een naam toegevoegd word bij kleine dingentjes dan heb je na een korte tijd toch wel een erg lange lijst.

[Verwijderd]

Je snapt het doel niet. Credit geven is het doel absoluut niet, dat is hoogstens een leuke bijkomstigheid. De credits-lijst zal dan ook niet hieruit worden opgebouwd. De credit-lijst blijft gewoon de MAINTAINERS file in de toplevel source directory.

Het doel van deze verandering is om herkomst van code makkelijker te traceren. Op deze manier is het simpeler om claims over eigendom van code te kunnen weerspreken, je weet immers exact welk stukje code door welke ontwikkelaar(s) is geschreven. Het is dus eigenlijk gewoon een uitbreiding van de huidige chain-of-trust (de weg van een patch vanuit de source naar Linus) door middel van documentatie van de afgelegde weg tussen personen van een patch.

De uiteindelijke lijst van contributors van elke patch zal dan ook niet in een credit-lijst terecht komen, maar slechts onderdeel vormen van de bitkeeper commit message zoals je daar duizenden van vind op linux.bkbits.net/.

[dasiro]

ach, die houden ze wel bij in een MS excel-spreadsheetje

[MisterData]

Dan is het nog altijd Gnumeric of KSpread ofzo

[dasiro]

i think u missed the funny part, better luck next time

[Verwijderd]

Wordt de kernel officieel niet uitgebracht met versie nummers die een veelvoud zijn van 0.2? Is het dan niet 2.8 die over een jaar verwacht wordt?

[rb338]

Oneven releases zijn uit de development trees, even releases zijn 'stable'.

Het lijkt me ook dat 2.7 bedoeld wordt. De release van Linux 2.7.0, de eerste unstable voor 2.8 dus, zal niet al te lang meer duren neem ik aan.

2.8.0 zal nog zeker een jaar duren.

Correct me if I'm wrong natuurlijk

[Exirion]

Gezien de ontwikkeltijden van 2.4 en 2.6 denk ik eerder dat het weer minimaal 2 jaar wordt voordat 2.8 er is

[Defspace]

De oneven releases zijn de test/developer releases en de even releases de stable/productie releases.
Over ongeveer een jaar verwachten ze de test/developer release van 2.7 dus. 2.8 kan je nog wel even langer op wachten.

edit
rb338 was me net voor

[Olaf van der Spek]

Over ongeveer een jaar verwachten ze de test/developer release van 2.7 dus.

Meestal beginnen ze direct met de volgende testing/unstable release na een stable release.
Want waar laten ze anders al die code die ze in dat jaar schrijven?

[solatis]

Logische stap na al dit gedonder. Je wilt gewoon zoveel mogelijk gedocumenteerd hebben, zeker als het gaat om 'geleende' code of code die niet door de ontwikkelaar zelf is geschreven.

Maar of het echt uit zal maken als er een rechtzaak over komt...

[sebas]

Some of you may have heard of this crazy company called SCO (aka "Smoking
Crack Organization") who seem to have a hard time believing that open
source works better than their five engineers do. They've apparently made
a couple of outlandish claims about where our source code comes from,
including claiming to own code that was clearly written by me over a
decade ago.

Humor heeft Linus blijkbaar wel. :-)

[Hoicks]

Op deze manier voorkomen ze dus dat SCO kan claimen dat er coden van hen in de kernel komt te zitten.

[stappel_]

nee, op deze manier kunnen ze herleiden waar de code vandaan komt. stel dat een "SCO" een claim legt dan kunnen zij zeggen: "maar dat hebben wij van dit persoon gekregen, ga maar bij hem zeiken"

ook kunnen ze zo herleiden als er ergens een backdoor in zit, van wie het komt.

[Olaf van der Spek]

Kan dat niet al lang?
Volgens mij is het enige dat nu veranderd dat de developer een 'contract' moet tekenen.

[Verwijderd]

Je tekent niks. Je signeert niks. Je geeft in je PATCH emailtje slechts aan welke personen aan deze patch hebben meegewerkt.

En inderdaad, source-herleiding was al mogelijk, zoals Linus in zijn emailtje aangeeft. Maar het is painful, het duurt te lang, en is afhankelijk van mailinglist archieven. Dit is veel effectiever en houdbaarder, omdat het een integraal onderdeel van de bitkeeper repository vormt.

[ATS]

Ik begrijp zo eigenlijk niet wat dit toevoegt aan de standaard in gebruik zijnde versioning systemen. Ik kan met CVS (ik weet dat voor de kernel iets anders gebruikt wordt, maar die zal ongetwijfeld hetzelfde kunnen) heel eenvoudig zien wie wanneer welk stukje code gewijzigd heeft. Wat is dan het nieuwe hieraan?

[Verwijderd]

Gedeeltelijk, want elke update komt van Linus, Andrew, een subsystem maintainer of een driver maintainer. De patch zelf is dikwijls afkomstig van derde personen en heeft een hele weg van personen afgelegd voordat hij bij Linus/Andrew aankwam, of soms zelfs voordat hij bij de officiele maintainer aankwam. Dit is dus completer.

[SED]

Deze stap is een heel belangrijke op weg naar volledige professionaliteit en acceptatie voor Linux.
Met dit soort maatregelen haal je het systeem uit het hobbysfeertje waar het toch veel te lang is blijven hangen. Als de pro-linux aanhangers nu ook nog wat serieuzer gaan reageren op tegenzetten van MS die ongetwijfeld gaan komen dan staat een brede toepassing niets meer in de weg.

[BartOtten]

Mijn mama zei altijd: "Als je volwassen bent reageer je daar niet op."
Dus als ik dat van jouw met dat van haar combineer moet de Linuxgemeenschap MS doodzweigen. Of zie ik t nou verkeerd

[Total-Control]

Nou lijkt dit aan de ene kant wel een mooi idee, maar een echte oplossing is het niet.

Stel ik heb een bedrijfje en ik heb een belangrijk kernel onderdeel gemaakt. Vervolgens vraag ik of iemand anders deze code wil voordragen aan de community; uit zijn eigen naam natuurlijk.

Vervolgens kom ik na een jaartje als bedrijf gewoon bij iedereen aankloppen dat ze source code van mij gebruiken en dus even moeten afrekenen; zo niet dan geen gebruik meer van maken van.
Bij de gene die de code heeft voorgedragen hoef je geen verhaal te halen, want alle software heeft natuurlijk zo'n mooie disclaimer, dus die gaat
vrijuit.

Je krijgt dus nog altijd hetzelfde probleem als er nu bestaat. Kortom leuk plan, maar echt effectief is het niet.

[Verwijderd]

Dan heeft die persoon dus gelogen. Jij kan dus ten hoogste die persoon aanklagen, niet de Linux community. .