Linus Adopts Enhanced Tracking Process
millette writes ""Under the enhanced kernel submission process, contributions to the Linux kernel may only be made by individuals who acknowledge their right to make the contribution under an appropriate open source license. The acknowledgement, called the DCO, tracks contributions and contributors. The DCO ensures that appropriate attribution is given to developers of original contributions and derivative works, as well to those contributors who receive submissions and pass them, unchanged, up the kernel tree. All contributors are called upon to "sign off" on a submission before it may be considered for inclusion in the kernel."
From the press release. Also seen in the New York Times"
Software methodology comes to open source.... Mind as well can the project now.....
Hmm, did the toothfairy whisper this in his ear last night?
"Honey, I feel a certain distance between us..." "Really? A 31ms ping ain't that bad..."
I wonder how this will affect the speed of the development process.
The name is kind of ironic, yes? You say DCO, I say SCO, let's call the whole thing off.
Reminds me of a documentary called "Why Planes Fall" which shows how planes are built. Each part, component and the tool used is logged to a person who created/assembled it. The system logs the tester/auditors which sign off on the work. It's amazing!
The only think I see different from this Linux process is that whoever created the code is not liable for anything that happens when you use the operating system. I see the 'auditors' of the Linux process are those that signoff on the code that are written by authorised contributors. There is no 'finger pointing' as so to speak when something goes wrong.
Is this going to be applied to the existing kernel sources or just new submissions? I think it'd be quite a job to track down all the people who still have their names at the top of kernel files after all these years. Especially those who have died (there must be at least one) or companies that no-longer exist (quite a few).
Regardless, I wonder whether this will slow down kernel contributions? Here's hoping it won't. People will still be able to create unofficial patch sets (like mm, ck and love sources) to test their ideas before actually contributing modifications to the authoritative source.
This article seems to just confirm that Linus did what he said he was thinking of doing.
/. posting is here.
The original
Bureaucracy loves company.
I keep saying this, and I am so surprised this is not broguht up more often, but if folks donate code to the project, are they not liable rather than the users of the project? I know I am talking about SCO, yes, it just seems so silly that anyone takes them seriously. Maybe this is a terrible metaphor, as I am only just starting to intake the coffee... but I sometimes thnk of this as if I gave someone a book, but inside the book there was tickets to a show. Then after giving the book I say to the person, by the way, I did not realize my tickets were there, can you pay up please? Sorry to rant, now back to the grindstone...
photoplankton
NYT comes out of nowhere with this idiotic, inflammatory headline. It's disheartening that mainstream technology journalists are still attributing anarchy, punk rock and anti-establishment to Open Source.
DCO is a wonderful idea. Steve Lohr, on the other hand, needs to get his head out of his ass.
That is a pretty interesting certificate; I may end up using it too. However, the second and (esp.) third options seems a little unspecific: Shouldn't it require the contributing developer to name the origional work and its author(s)/entity(ies)? That way the lead developer could independently confirm that there are no copyright problems, if needed.
It is impossible to enjoy idling thoroughly unless one has plenty of work to do.
- Jerome Klapka Jerome
What is it about? It's about putting information that was already mostly available (by scrounging in mail archives) in a structured form. So that the next SCO doesn't waste so much developer time, and (as a bonus) so that Linus can figure out which maintainer sent some code when debugging.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
But, more importantly, you have to realize--this has nothing to do with giving (positive) "props" to the kernel authors and everything to do with identifying sources of blame when it all goes to hell.
Forget whether or not you like software patents for a moment; the fact is that right now they exist. Previously, you could in theory contribute some patented or even copyrighted (direct copied) source into the kernel and it might go unnnoticed for years. Now, the theory goes, once the infringing bit is noticed, IBM or Autozone can't be sued as easily anymore--rather, what they will do is say "no, look - this piece of code came from monkeyboy332, a programmer in serbia".. sue him instead!
In short, this is a nice way for large companies attempting to wash their hands of responsibility for a linux kernel that they arguably have access to because it's open. In simpler terms still, this is corporate welfare by linus to try to win wider adoption of linux. It's not a bad strategy, but accept it for what it is.
It has nothing to do whatsoever with giving authors "credit." That is already well handled by other mechanisms.
Although I'm not an expert in law (and certainly not US law since I live in the EU with different laws regarding to this), my gut feeling says I would never, never, nerver ever sign a document like that even if my work would be 100% original and not copied.
...) for any damages. Since most of the programmers probably do not have their assets split between their personal property and some form of 'company property' this might get dangerous. Please excuse me for not knowing the correct legal terms for 'private property' and property as part of an "inc." or "ltd.".
Just the mere fact that you sign a document that proves you wrote part of the Linux code, makes you liable for litigation. If any company thinks its rights are violated by a Linux component they can easily sue the contributors of this (and more) components personally. Given the track record of US litigation, I would never sign it.
Signing the document means that the author of the code will have to seek expenive legal support in case a lawsuit is started. Even if he can prove in court the code is original and written by himself, the bill for legal advice can be quite substanstial. If an author programmed in his spare time, this means he personally is liable... personally as in 'with your own personal assets'...
As an employee of a software firm (or worker at any other firm), your work is done "acting as a part of the company". Hence the company itself and not the individual employee is (financially) responsible for his/her mistakes. In case of litigation the company will have to seek legal council and incurr the damages. In my country the company could try to sue the employee for the incurred damages afterwards, but it will have to prove very extensively that the employee made very serious professional errors. And even then, companies rarely do so.
But a private author is personally responsible with his own assets (wage, house, car,
No, to me this more sounds like a preventative measure, to make sure something like the whole SCO debacle doesn't happen again.
It could also provide a more improved structure for linux, but I'm not a programmer, so I don't know what the heck I'm talking about.
This is the sig that says NI (again)
For example, you could imagine a SCO-wannabe taking their commercial code (that nobody is buying anymore but which they for some reason believe has real IP value), and putting one line (seemingly innocuously, effectively no-op'ed by some never-happens if cases) in an obscure kernel module (maybe a driver for some crufty ancient device). Then repeat (possibly under the guise of a different developer). Soon the module is working, with all the sleeper code inside. Then submit a patch that gets rid of all the intervening lines and voila, a big chunk of proprietary code is in the kernel and nobody noticed.
There are probably simpler ways to sneak stuff in if you want to be malicious. Maybe I've been watching "The Manchurian Candidate" too often!
This is a very bad precedent: the OSS community now has to follow processes that in the past, only large corporations could afford: audit trail, overkill documentation, etc. The fact that SCO/MS has managed to move Linus on *their* turf and make him play by *their* rules alas without their resources makes me really nervous: whoever gets to frame the debate always has a disproportionate advantage. What's next? More FUD campaign to fuel the fire, more hoops we'll have to jump through. While OSS people have to play lawyers, they don't write any code.
there's no place like ~
By creating this paper trail of responsibility, the work on Linux will be externally auditable. This will help reassure big business that they will not legally shaft themselves.
Sincerely, Stormcrow309
Remember, free is only free when you consider support and hardware costs.
In God we trust, all others require data.
All contributors are called upon to "sign off" on a submission before it may be considered for inclusion in the kernel.
I don't say it currently is, but in future it *may* be a step towards elitarian class establishment, as well as political control tool for technology. How well-defined should be an identity of a GPL project contributor?
When signing on will be obligatory for contribution, a simple rejection to sign on a person for some "external" reason may have such political consequences. For the first, I believe it is in direct contradiction to the spirit of GPL.
Example: what about potential kernel developpers from countries politically inacceptable in United States?
Currently, it is not possible for major distro releasers from the new continent to export a linux technology to the Iran, Lybia or Northern Korea. Does the U.S. government violate the GPL license? Yes, it does.
What if some kernel contributors will actually become from these countries? Should be all farsi and arabic localisation contributors to the any of the sourceforge projects be perlustrated for not actually being an al-Quaeda operatives?
There you are, staring at me again.