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"

Comments

Oh boy.....

[wpiman]

Software methodology comes to open source.... Mind as well can the project now.....

Re:Oh boy.....

[dotz]

Well, it surely comes, but only to *Linux*, not opensource. And, while we're at operating systems: *BSD projects use both CVS and bug tracking system from a long, long time. It's Linus "dislike of versioning systems" (or perhaps, being resistant to good advices), which made Linux-SCO claims as easy. With FreeBSD Web CVS interface, you can do usual things you can do with CVS. For example, review all commits to /README in FreeBSD (just click here) in the last 9 years. Responsible people, commit dates, commit messages. SCO claiming they did the changes? Don't think so. How about Linux? Yes, Bitkeeper repository. Since when? 2.4.x, if I remember correctly... and the code was already above 20 MB tgz by that time. Pretty late. Well, better late, than never. I'm waiting to see Linux kernel having a "core team", and a central bugzilla... not the mailing list with patches.

Great idea

[l0wland]

Hmm, did the toothfairy whisper this in his ear last night?

Re:Great idea

[jlp2097]

Don't get it? Look here.

Speed vs. SCO-secure

[tfbastard]

I wonder how this will affect the speed of the development process.

Re:Speed vs. SCO-secure

[pheared]

And I wonder who will play Record Keeper with all of these DCOs. Kernel development is currently very distributed, but this calls for a single entity who can track the DCOs and be sure that they will never disappear.

DCO?

[havaloc]

The name is kind of ironic, yes? You say DCO, I say SCO, let's call the whole thing off.

Like building a plane

[vchoy]

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.

Re:Like building a plane

[femto]

> ...whoever created the code is not liable...

Is this something that will change? With improved contribution tracking, will the next SCO/liability/whatever suit be directed against individual developers?

What if someone uses Linux in a 'mission critial' situation and it fails due to a bug? The bug is then traced back to an individual developer who is sued. There are countries where 'denial of liability' is a weak defence. Can the fact that a developer didn't get paid, so there was no transaction between teh developer and user act as a defence?

Just playing devils advocate.

Re:Like building a plane

[kpansky]

There already is a EULA. Its called the GPL.

Re:Like building a plane

[prisonernumber7]

Not needed. Because you do not have a right to use Linux as well as its accompanying utilities, the GNU tools - and if you don't have a right to use something, you can hardly sue somebody because that something did misbehave.

Except of course if you agree to the GNU General Public License, which the software is licensed under. Then you can use it. Obviously only under the terms of the GPL, which explicitly state that you must not hold the author liable for any damages caused.

Also interesting: In most countries of the world (such as my country, Austria), EULAs are not enforcible because the user does not get any more rights granted than what he got anyways when he bought the software. The GPL, in contrast, is enforcible.

Re:Like building a plane

[x-router]

The GPL protects you for this sort of thing.

NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Re:Like building a plane

[Minna Kirai]

There already is a EULA. Its called the GPL.

No. No. No! For the last time, moron, the GPL is not an EULA.

GPLed programs never demand the End User to Agree to a License before using the software.

Re:Like building a plane

[Minna Kirai]

Except of course if you agree to the GNU General Public License, which the software is licensed under. Then you can use it.

Wrong wrong wrong. If somebody gives you software, you can use it from then on. Once the files are in your possession, you can use them, unless you've somehow signed a specific prior contract promising you won't. The only things you can't do with software you possess is break other laws- primarily copyright, which in most countries prohibits you from copying (or redistributing copies) of a program without explicit consent from the author.

If you don't plan to give out copies of the program, you have no need to agree to the GPL, or even read it.

Now, I don't know Austrian law, but if there is something unique about it that requires specific permission from software authors before you can run their programs, you should've said so.

Obviously only under the terms of the GPL, which explicitly state that you must not hold the author liable for any damages caused.

Wrong. Go read the GPL before lying about it anymore. The GPL mentions there is NO WARRANTY, but just a statement of fact- reminding you that if you thought an author had offered a warranty, that no, she really didn't. It contains no "agreement" of the form "If you decide to use this, you give up all consumer-protection rights and can never sue me"

Re:Like building a plane

[femto]

1. ... TO THE EXTENT PERMITTED BY APPLICABLE LAW.

12. ... UNLESS REQUIRED BY APPLICABLE LAW ...

So if local law doesn't recognise denial of liability, you're liable?

Given this condition, a claim for liability would seem (to me) to be allowed under the GPL. Thus one couldn't even declare the GPL to have been violated, claim the user was using your code without permission, and countersue for copyright infringement.

Re:Like building a plane

[xchino]

No, GPL is a license to DISTRIBUTE, not a license to USE. You may use GPL software any way you see fit, the only restrictions are on distributing it.

Re:Like building a plane

[femto]

However, I can't see individual developers being held liable by any sane judge for anything short of deliberately malicious coding.

Good point. It leaves me feeling a little uncomfortable though, as it would still require a defence in court.

I would think that if the developer did not accept compensation (money) for their code that might remove any liability under consumer law, as no 'transaction' ever took place?

There is also the curly question of professional indemnity. What if the developer is a professional, coding for free on the side? The judge might then rule that he/she should have known what he/she was doing and so find him/her liable for mistakes?

Re:Like building a plane

[prisonernumber7]

Wrong wrong wrong. If somebody gives you software, you can use it from then on. Once the files are in your possession, you can use them, unless you've somehow signed a specific prior contract promising you won't.

If you download software, then you are actively seeking to acquire that software. Nobody gives it to you. The software is at most being made available to you, but it is not given to you.

As a metaphor: If I leave my front door open anybody can go in and take stuff from my house. That does not mean that they may do so though. Since software is meant to be used that's a chewing gum point however, but let's get to that in a second:

If you don't plan to give out copies of the program, you have no need to agree to the GPL, or even read it.

From the GPL FAQ, on the question whether users have fair use rights on a GPLed program: "Yes, you do. "Fair use" is use that is allowed without any special permission. Since you don't need the developers' permission for such use, you can do it regardless of what the developers said about it--in the license or elsewhere, whether that license be the GNU GPL or any other free software license.

Note, however, that there is no world-wide principle of fair use; what kinds of use are considered "fair" varies from country to country."

So fair use is nothing generic and nothing you can count on. If there are liability problems you have a case that is beyond fair use in any event. In this case you must agree on the GPL to get what the license gives you in terms of warranty - which is, as you rightly point out, no warranty at all.

Wrong. Go read the GPL before lying about it anymore.

*shrugs*. So strong words. For the sake of clarity, "no warranty" can be considered to also mean "not liable for damages" (of course, it means other things too). Can you stop trolling now puh-lease?

Re:Like building a plane

[schon]

A lot of them have installers that force you to agree to the GPL before it will install.

No, they don't. They may display the GPL, and present a button labeled "I agree", but (if you actually _READ_ the GPL) the GPL contains this text:

5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.

So they do not "force" you to agree to anything.

Just because something is presented as an EULA, by someone who doesn't know what an EULA is, does not make it an EULA.

Existing source code?

[Ianoo]

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.

Reference to original posting

[hussar]

This article seems to just confirm that Linus did what he said he was thinking of doing.

The original /. posting is here.

I'm not a legal expert, but

[denisdekat]

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

Horay!

[91degrees]

Now all I need to do, is get hold of some code, claim it's mine, and I'm now officially the owner!

Now, what is this "Linux" thing? Does it run under Windows 98, or will I need to upgrade to XP?

"R.I.P.: The Counterculture Aura of Linux"

[Anonymous Coward]

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.

Re:"R.I.P.: The Counterculture Aura of Linux"

[mumblestheclown]

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.

Yes, it's hard to figure out where they get their ideas, given the well-thought-out and mainstream ideas on copyright (not to mention perhaps-rarer but still around anti-GUI rants we see every so often) we see on slashdot every day. Yes, slashbots spend more time blathering about (as I am doing now) than writing code, but, like it or not, this is seen as a major orifice of the OSS community.

Is that third option missing something?

[Quantum Jim]

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.

Re:Is that third option missing something?

[Anonymous Coward]

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)?

No. Read the third option carefully: "The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it." [emphasis mine].

Basically, the third option is geared towards people who maintain certain parts of the tree and get patches sent their way rather than straight to Linus. There will be a separate certificate provided to the maintainer.

The second option contains the phrase "as indicated in the file", which means that the origin is already recorded.

What this is not about

[The Pim]

1. This is not about a chain of trust. Nobody is expected to verify the identity or trustworthiness of anyone else.
2. This is not about preventing unauthorized submissions. There is no process for checking the provenance of code.
3. This is not about marketing. I'm sure Linus doesn't care if this helps some manager sleep at night.

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.

Not "attribution", but ACCOUNTABILITY.

[mumblestheclown]

First, it's pretty sad when the NYT scoops slashdot on a major piece of linux news like this.

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.

Re:Not "attribution", but ACCOUNTABILITY.

[LMCBoy]

Now, the theory goes, once the infringing bit is noticed, IBM or Autozone can't be sued as easily anymore

Except that neither IBM nor Autozone have been sued for using alleged "infringing" code in Linux...in fact, no one has.

Seems to me that this kind of "paper trail" will only be useful against a hypothetical litigator that points to a piece of code in Linux and said: "this code here, this infringes on my IP". It's not so useful against a SCO-like "we own it all, so pay up" FUD blitzkrieg.

SCO

[jb.hl.com]

Isn't this just like admitting that Linus has no idea what's in the kernel and SCO code could be in there?

Re:SCO

[Killjoy_NL]

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.

Legal implications to coders

[wimbor]

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.

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, ...) 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.".

Re:Legal implications to coders

[pe1rxq]

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 a document aknowledging that you wrote it doesn't make you more liable...
Wheter you sign or not doesn't change the fact that you wrote it.
If you are liable after signing you were liable before. The signing just makes it a little bit easier for the other party to find you.
Unless you posted all your patches to linux-kernel as anonymous coward this doesn't change anything at all.

Jeroen

Re:Legal implications to coders

[wimbor]

Jeroen,

You are indeed correct that writing and attributing the code is of course the fact that could get you in trouble. Whether or not you sign a document. As you said it is only easier to find you (which is more or less uncomfortable), but the real difference is also that your signature of the DCO makes you vow that you are responsible for the code, that the code is yours in the making. If another party thinks this is not the case, they can also attack you on specifically that: the fact that you knowingly lied about the contents of the code... I would think this is an additional disadvantage...

Apparantly the GPL does metion that the author does not guarantee the software. But, alitigator can still sue you, and lose... but the legal costs are still there...

Anyone else notice?

[space77pup]

That this article was on the front page of Google News in the Sci/Tech section? Perhaps it'll still be there. Google News Sci/Tech

I can imagine some subversive ways of sneaking in

[shoppa]

I understand that nothing is foolproof, especially when someone tries malicious tricks.

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!

When do we see such a thing on slashdot ?

[heytal]

Slashdot Comment Submitter's Certificate of Origin 1.0

By submitting a comment to this slashdot story, I certify that:

(a) The comment was created in whole or in part by me and I have the right to submit it under the copyright laws; or

(b) The comment is based upon a previous comment from a dupe story, and to the best of my knowledge, is covered under an appropriate copyright law and I have the right to submit that comment with modifications, whether created in whole or in part by me; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

Devils advocate reply

[vchoy]

This system would be excellent for situations against SCO/liability/whatever suits. The beauty is that the code in question can be tracked. SCO or whoever who decides to sue can't just say "Hey...[the whole of] Linux is ours!"
With tracking, the code written by the author can be reviewed and resolved if necessary!

Mission critical: Well buy mission critical support from Redhat/Suse/Mandrake etc... Don't like that? Signup and offer patches or fixes to contributors.

As said previously, this process is not a 'finger pointing process'. Its a process that helps the development of linux to enable it to progress to new heights! If code needs modification/optimisation, communicate and help the contributor! If you find a particular component is really helpful or beneficial, write to the contributor and thank them, or you may even paypal or donate..etc.etc.etc.etc!

Have fun.

Re:Devils advocate reply

[femto]

Here's one from the Devil's advocate:

Redhat/Suse/Mandrake back up their mission critical support with insurance. One day, they get a big failure and their customer makes a claim against the XYZ insurance company.

XYZ insurance company, in common with most insurance companies, is run by a group of low lifes who would kill their grandmother for a dollar and don't give a damn about the principles of free software. In true insurance company style, XYZ tries to pass the liability and recover its costs by suing the developer who wrote the buggy code.

Despite the best intentions of the free software community, we now have defenceless developer vs. rich insurance company. How to stop this?

A bad precedent?

[Petronius]

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.

Linux External Auditing

[Stormcrow309]

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.

Liability

[jrj102]

Does this mean that an individual writing code would now get sued by the SCOs of the world instead of companies that deploy Linux? Is this a good thing?

BSD?

[Anonymous Coward]

How does this compare to BSD's processes?
Or Apache's?

Will this be a growing trend across open-source projects, to push accountability down to the contributors?

Freedom of coding?

[Maljin Jolt]

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?

NYT Bias

[beforewisdom]

The New York Times article is interesting.

It is written in such a way that it reads like SCO does own what it claims to own and that IBM took an extra liberty under some sort of agreement.

Quite the opposite tone and bias from the tech journals ("what is SCO smoking??!!").

Given that most business people are more likely to read NYT then Slashdot or Groklaw I can now understand why SCO got as far as it did with its stock scam.

Steve

Duh, what's a precedent?

[anthonyx]

The plan is to make this very light-weight, and to fit in with how we already pass patches around--just add the sign-off to the end of the explanation part of the patch. That sign-off would be just a single line at the end (possibly after other peoples sign-offs), saying:

Signed-off-by: Random J Developer <random@developer.org>

-- Linus

You seem to disagree with Linus as to how much work is involved in this kind of tracking.

I dissagree with you about what turf and rules belong to "SCO/MS".

Lawyers may care a lot about precedent, but I don't know any programmers who do.

Re:who gave linus the authority ?

[Zoolander]

Well.. yeah? Anyone can (and many have) make a fork of the official Linux kernel. Check out the mm and ac branches on kernel.org, for example.