Process Improvements in the Kernel Development

Kalki writes "In an e-mail to the Linux kernel mailing list, sent Saturday, Torvalds proposed that kernel developers begin certifying that the code that they contribute is entitled to be included in the Linux kernel as well as a technique for "signing off on patches" that would better track which developers had handled source code contributions. check this Infoworld story on it."

Comments

Santa Claus

[Anonymous Coward]

... track which developers ...
So Santa Claus and the Tooth Fairy need not be featured on slashdot :P

Re:Santa Claus

[smatt-man]

that would better track which developers had handled source code contributions.

To find out who's naughty or nice.

heheh

[RupertJ]

"..."signing off on patches" that would better track which developers had handled source code..."

.... and Linux joined the world of professional software development!! =)

/me ducks

Re:heheh

[bigdady92]

So finally it would become a cathedral instead of a bazzar? That in and of itself would be amazing! :)

Re:heheh

[drooling-dog]

.... and Linux joined the world of professional software development!! =)

I hope not, since the "unprofessional" model has worked so well (and I'm not being sarcastic). This is more an acknowledgement that GNU/Linux is swimming in dangerous waters, and has enemies with money to burn. Even though SCO's claims have apparently turned out to be lame, you have to assume that intellectual property traps are being set left and right.

Re:heheh

[AnuradhaRatnaweera]

.... and Linux joined the world of professional software development!! =)

Signing patches alone may not entitle kernel development to be called "professional". Don't forget that many patches are sent over SMTP, and it is possible for spoof a real kernel contributor. Of course, most of the spoof attempts will fail, but with the present and potential future scale of the kernel development, Father Brown's `unnoticed' theory might manifest.

Re:heheh

[bfields]

This is more an acknowledgement that GNU/Linux is swimming in dangerous waters, and has enemies with money to burn.

On the other hand, the SCO case also showed that even a well-funded company given a year (so far) and great incentives to find intellectual property problems in the linux source has been unable to do so.

Not that it's bad for the linux developers to be careful and think ahead.

--Bruce Fields

Re:heheh

[Nutria]

So finally it would become a cathedral instead of a bazzar?

How does that make it a cathedral? Linux is still open; it will just be "tracked" in the future.

Re:heheh

[Short Circuit]

and it is possible for spoof a real kernel contributor.

So some company's going to run a black-op to steal the developer's private GPG key?

I won't say it's impossible. But it does sound an awful lot like AntiTrust. (An excellent movie, BTW. I enjoyed it.)

A good thing.

[Raven42rac]

The more organisation and delegation in Linux, the better. With the gains being made using Bitkeeper and this, I feel that Linux will make leaps and bounds in the next year. The things I hope for are better hardware detection and working device drivers for more devices (especially multifunction printers). I think Xandros is getting really close to the way things can be. But then again, I run a Debian CLI install on a Pentium II 350. I guess what I meant to say was, for Linux to gain mass market acceptance, it needs to do everything Windows/OS X does, but better, cheaper and faster.

Re:A good thing.

[ImpTech]

Well obviously we'd love Linux to be better than Windows and OSX in every way. Thats pretty unrealistic though. You can't honestly say that either Windows or OSX is definitively better than the other in every way, and for that matter I'd argue that there are ways in which Linux is already clearly better than both. But no OS will ever be all things to all people.

I'd also add that the kernel lacks nothing that would allow good hardware detection, as thats not really the kernel's job. Device drivers... well, we could go on about that forever, but thats a matter of convincing hardware manufacturers to play nice with Linux. And yeah, some of that falls on the kernel developers, but they're not even remotely the whole problem.

The way I read it, this 'process improvement' is just to provide more precise accountability for changes. Sounds good as far as resolving future legal issues, but I doubt if it'll result in a better kernel.

Re:A good thing.

[AstroDrabb]

The things I hope for are better hardware detection and working device drivers for more devices

Actually, as far as Linux the kernel goes, hardware detection is already there. It is up to the distro builder to have a good hardware database to know what drivers to load. If you plug in a USB key, /sbin/hotplug gets called with info about the device. Some distros like Fedora pretty much do nothihng. I plug my USB HDD, USB Archos MP3 player/recorder or USB mass storage camera into Fedora and nothing happens. I have to manually mount each device. SuSE and Mandrake seem much better at things like this. I think all distros should all contribute to a hardware ID database pool and share a common /sbin/hotplug setup to be able to detect all devices that work under Linux and handle them in a newbie friendly way.

As far as drivers go, most/all devices with a standard or open spec get supported. For the proprietary stuff, you need to hammer on the makers.

Linus retiring?

[johnthorensen]

This is very speculative, but this looks like the sort of thing somebody does to ease the transition when they turn something over to another leader. Yeah, it's about a 1:10000 chance that I'm right, but remember you heard it here first...

-JT

Re:Linus retiring?

[xlyz]

This is very speculative, but this looks like the sort of thing somebody does to ease the transition when they turn something over to another leader. Yeah, it's about a 1:10000 chance that I'm right, but remember you heard it here first...

you know what? I agree
in 50 year max Linus will hand over his responsability
please add me to the credit list of the future-tellers

Re:Linus retiring?

[skidv]

Remember that Linus "retires" from a version of the kernel when he thinks it is stable enough for a maintainer to supervise. Once he is freed from maintaining the current "release" version of the kernel, he starts working on the next development version.

He'll pass version 2.6 to someone and then start work on 2.7, just as he passed 2.4 to Marcelo Tosatti and then began working on 2.5.

Re:Linus retiring?

[Anonymous Coward]

He's already handed over much of the release management for 2.6 to Andrew Morton. Linus is more focused on the development tree at the moment.

Re:Linus retiring?

[Turmio]

And that someone would be Andrew Morton.

Re:Linus retiring?

[BinaryJono]

2.6 is maintained by andrew morton, the keeper of the mm patchset

Re:Linus retiring?

[Anonymous Coward]

Yeah. Unfortunately, that dev tree is still 2.6.

Re:Linus retiring?

[Anonymous Coward]

And in case you were wondering after reading the three previous posts to the parent, Andrew Morton handles much of 2.6. Just in case you didn't get it the third time.

Re:Linus retiring?

[Anonymous Coward]

Andrew Morton.

Re:Linus retiring?

[Anonymous Coward]

What, like 2.6 and Andrew Morton?

Re:Linus retiring?

[Anonymous Coward]

Don't quote me on this, but I think it's going to be Andrew Morton.

Re:Linus retiring?

[millette]

Just wait till he finds a nice lady and they start popping kids. If he ever moves out of his parents' basement in Finland, he's bound to attract a lot of females, just look at his cute face :)

Good Idea

[Anonymous Coward]

Good idea, even if some people will say that SCO scared them into doing it (they say it is a factor, but not the driving reason)

Re:Good Idea

[Anonymous Bullard]

Several academic and corporate friends of Linux have legal access to source code from hostile parties (e.g. MS), or simply access to other comparative/competitive code that is either proprietary or semi-open under incompatible license. Someone could probably even "handle" proprietary code that has been leaked illegally

These friendly parties should establish automated processes for line-by-line comparison between all Linux code (and as much major GPL'd code as feasible) and potentially illegal code.

On the other hand FSF and pro-Linux parties should begin lobbying the-powers-that-be for corporate responsibility on the part of the developers of proprietary software. Say, upon releasing a new version of a product, a vendor of proprietary product should be encouraged to perform a line comparison between their application and FSF's bank of GPL'd software. Such certification could be conducted by the vendor itself, FSF or a trusted 3rd party. Heck, the proprietary vendors should establish a neutral bank for their proprietary code for similar purposes; to prevent industrial theft by an unscrupulous competitor or insider.

Such monitoring of proprietary code combined with stricter accountability monitoring on Linux' behalf should help both prevent licensing and illegality issues and help solve them quicker if any should arise.

Source code is the major if not only asset a software vendor has, and yet it seems only OSS developers treat it with the respect their customers/users deserve, i.e. with openness and especially accountability (which should further improve with the suggested measures).

Would such a source bank for proprietary vendors ever be accepted? Could its confidentiality, neutrality and security be guaranteed? Hmmm, maybe proprietary vendors would still prefer to keep their (dark?) secrets to themselves but all available (through licensing or leakage) non-GPL-compatible code should still be compared.

Re:Good Idea

[bro1]

This sounds like a good way to ensure accountability on who made what changes, and when they did it. Linus says the SCO debacle "have provided a "big impetus" for the changes", this will make sure similar legal action can be shot down immediately.

No, similar legal action cannot be shot down imediately, because SCO did not identify the infringing code for a very long time.

Accounting

[dimss]

Over years, Linux development team has become an enterprise. Finally they realised that they need accounting.

Re:Accounting

[xlyz]

Over years, Linux development team has become an enterprise. Finally they realised that they need accounting.

now if only the "proprietary" software developer will accept external audit to verify they are not using sources they are not entitled to, we will be all set

Re:Accounting

[cerberusss]

Well, well mr. know-it-all. If you had bothered to RTFA, you'd see it's just an extra line in the accounting that's called source control.

Re:Accounting

[swillden]

Over years, Linux development team has become an enterprise. Finally they realised that they need accounting.

Just a clarification: What Linus is doing is making the accountability easier and somewhat more complete, not adding it. As he pointed out in his LKML post, Linux developers have been able to find the origin of every bit of code they've needed to, but the process has been painful and has required a little guesswork, particularly for the oldest stuff.

What he's proposing here is just a slight formalization and elaboration of the process that has been used for years. Currently, if I submit a patch to LKML to fix, say, a VFS bug, it will get poked, prodded and adjusted on the mailing list until people think it's clean and solid. Then the subsystem maintainer (Al Viro, in this case) will pick it up, probably tweak it some more, attach a "From" comment, stating that I am the author and forward it to Linus. Linus will review it, accept it, and his scripts will add my name into the changelog and the CREDITS file.

Since all of this happens on the public, archived, mailing list, there's plenty of accountability, but figuring out the sequence of events requires digging through the archives, and there may not be any obviously ideal search criteria.

Now, Linus wants me to attach my name myself, and to do it in a standardized format so that it's more searchable. Further, he wants everyone else who modifies the patch in any way to add their stamp as well, providing a change history in the patch itself. It's a weak change history, since it doesn't describe what changed, but it provides the starting point for searching the archives.

So, what Linus is asking for isn't so much to create a better accountability trail as it is to make the existing trail easier to follow. It's an ease-of-use optimization.

Well, there is one way in which this is perhaps a significant enhancement, and that is that Linus wants to formally define the legal commitment a contributor makes. In a reasonable world, this should be unnecessary, since if I contribute some code that I don't own, I should be the one held liable for the copyright infringement, not the others who used it in good faith. In the litigious world we live in, however, it's a good idea to formally spell it out, and make clear to everyone that by attaching their name to a patch, they're providing a certain warranty of their right to contribute it.

Re:Accounting

[Anonymous Coward]

Yeah, but do they have human resources yet? How about janitors?

Groklaw article

[jadel]

There is an article on this subject at groklaw
It covers more or less the same territory in a bit more depth.

A Good Thing(tm)

[Alizarin Erythrosin]

Anything that prevents the possibility of another SCO-type BS lawsuit is a Good Thing.

Hopefully it can avoid patent issues too. If something goes into Linux and later some company (Microsoft?) files a patent lawsuit, there may be evidence of prior art if the code was "certified" on a certain date.

On the reverse side, it can provide exactly who contributed the code (which can already be done mind you), but this time, they certified it for use, which can possibly cause more legal troubles.

Re:A Good Thing(tm)

[colinleroy]

On the reverse side, it can provide exactly who contributed the code (which can already be done mind you), but this time, they certified it for use, which can possibly cause more legal troubles.

Well, the submitter would certify that he has right to write and submit $patch - (a) or (b) of Linus' certificate example. People touching and applying $patch would certify (c): that the previous hop in the chain certified (a), (b) or (c). They wouldn't verify the original submitter's claims.

Re:A Good Thing(tm)

[Spoing]

1. Anything that prevents the possibility of another SCO-type BS lawsuit is a Good Thing.

Prevent? Nothing will do that short of turning SCO corp. into a legal crater as an example of any other company foolish enough to attempt the same stunt.

The kernel development process is about as public, auditable, and open as I can imagine. (Yes, there are some with better audit controls, though most of those projects are quite private or secret!)

Any code that has substance goes in has a name associated with it in the change log, and historic versions of the kernel are available going back 10+ years. I don't know of any closed commercial application I've ever worked with that can say the same...usually, it's a couple years, major releases (maybe), and forks. That's it!

Re:A Good Thing(tm)

[Eccles]

Anything that prevents the possibility of another SCO-type BS lawsuit is a Good Thing.

One horse's head in Darl McBride's bed comin' up!

Re:A Good Thing(tm)

[Anonymous Coward]

Hopefully it can avoid patent issues too. If something goes into Linux and later some company ... files a patent lawsuit, there may be evidence of prior art if the code was "certified" on a certain date.

The question with prior art against patents is "what does it do" and "when did it do it publicly". Unlike copyright, prior art against patents usually doesn't care "who wrote it" or "where did they get it". This new certification plan is generally no better at creating prior art than plain old dated submissions. That's not what it's for.

IANYL--GYOGDLYMNO

Re:A Good Thing(tm)

[Deusy]

Prevent [another SCO-type BS lawsuit]? Nothing will do that short of turning SCO corp. into a legal crater as an example of any other company foolish enough to attempt the same stunt.

Fortunately SCO and Darl McBride are doing a great job of cratering themselves. Short of turning up and denying the crap SCO is flinging at people, IBM and the like have had to do almost nothing.

Is it only me who gets the impression, lately, that everything SCO does digs their grave a little deeper?

Re:A Good Thing(tm)

[iabervon]

The real point is to make it easier to look up. Proving that Linus wrote the code which SCO claimed to own took a weekend of looking through history and it was only distinctive due to characteristic bugs. The goal with this is to be able to be able to report the entire history of the code back to the original authors of each line by the question and answer section. "But that code was donated by Christopher Hellwig and signed off on by Robert Love. Do you mean to claim that the CEO didn't have the authority to do so?" It's quite beneficial to have the real story worked out while the press is still there.

Re:A Good Thing(tm)

[Spoing]

1. Is it only me who gets the impression, lately, that everything SCO does digs their grave a little deeper?

Agreed...though I'm very puzzled why the stock price is still above the $3 mark (the price when they started this mess about 13 months ago).

Why isn't it at $2 or even lower?

If someone is pumping up the stock price, they can't do it forever...it's got to collapse sometime! (Doesn't it?)

tracking

[colinleroy]

"signing off on patches" that would better track which developers had handled source code contributions.

Linus Torvalds' problem is the fact that, as it is currently easy to find out who commited the patch, and often who provided it (which often appears in Bitkeeper's changelog), the whole submission process can be a blackbox - if I send a patch to alsa subsystem's maintainer, he'll probably apply it to alsa's CVS, maybe someone else will modify this patch, and when included in linux' main tree, only the merge information would appear.

Re:tracking

[justsomebody]

Quite contrary my dear Watson, patches can be traced in colective manner much easier.

Re:tracking

[manWorkSucks]

Linus' original email linked further down makes clear the intention to track where the code came from start to finish.

Its official then

[Timesprout]

Patches submitted as AC will no longer be included in the Linux kernel

Re:Its official then

[Anonymous Coward]

Patches submitted as AC will no longer be included in the Linux kernel

Damn, bad news for Alan Cox ...

Avoid even the appearance..

[hot_Karls_bad_cavern]

As taught to almost all people taking the moral high-ground, that are in the public eye:

Avoid even the appearance of wrong doing.

Guys, this is a great idea for accountability in the kernel source. In the next round, the "SCO" of that round might not be so blatently stupid and far more sinister. Please watch your code and keep it clean!

Re:Avoid even the appearance..

[BinLadenMyHero]

I wonder if this is in any way related to this.

From FSF:
We have just begun a project here at FSF to document and codify our process, so that it can be disseminated in the form of a policy manual and accompanying software, to all other Free Software projects who wish to solidify their legal assembly process. Distilling nearly two decades of organizational know-how into easy-to-understand software and documentation is no easy task, and we will rely greatly on your financial support to aid us in carrying out this momentous task.

Professional Approach coming to Linux ?

[kbsingh]

Sounds pretty good. I think Linux needs a basic system of this sort in place as-soon-as-practical. It will bring together a lot of accountability of / for code in the Kernel itself. Plus, it should counter any issue like the SCO created one, in the future.

Another interesting point here seems to be that with this management overhead and the admin work that issue such as this create, how much of time is Linus actually spending with them ? while he might be working with the technical side of things ?

Inspite of all the noise, there are just a handfull of people contributing major code into the Kernel ( would 300 be a fair guess ? ) How are all these admin overheads going to effect their performance ? Also is anyone / everyone expected to research the piles and piles of patenets / copyrights before they make such a declaration ?

This quote says it all

[Henrik S. Hansen]

I think this quote really says it all about why this is a good idea:

"People who don't understand how I interact with the people I work with literally feel better just having it down more as a documented process," he [Linus] said.

Re:This quote says it all

[gosand]

I think this quote really says it all about why this is a good idea: "People who don't understand how I interact with the people I work with literally feel better just having it down more as a documented process," he [Linus] said.

Take my comments with a grain of salt, because I am up to my eyes in process development because we are trying to get CMM Level 2 certification where I work.

I don't see a problem at all with documenting the way things are done. I know a lot of people resist it, but think about it. How hard would it be for Linus to just write down how he does things. You'd be surprised how many times you uncover problems (or potential problems) when you have to write down your processes. Sometimes, you immediately see ways to improve things. If not, then at most you are out a little bit of effort.

But I really think that Linus wants to do this so that when he is on the stand and a SCO attorney asks him how code is added to the kernel, he can just say "RTFM!".

Re:This quote says it all

[Spoing]

1. "People who don't understand how I interact with the people I work with literally feel better just having it down more as a documented process," he [Linus] said.

That's exactly it. Why is it that most of the comments here say "Good...Linux needed more professionalism/riggor/process/...."

I'm Mr Process myself. I ~love~ the SEI-CMM, will quote you hymn and verse from project plans, will dog you if you are sloppy and can't file a defect report on stuff you yourself wrote or if you mis-categorize it. Process is important because it makes people focus on doing the right thing when they don't want to.

OTOH...I've also been following Linux (the kernel) for years and how it is managed. The added test suite is fantastic, as is Linus' stand on using the best tools for the task. Linus and the other core Linux developers are already motivated to do the right thing so adding more formal processes in that don't help with development is not a good thing. It's sad. I have no doubt that this extra layer will not get in the way...so it's not too sad!

I like this bit the best

[technomanceraus]

Hola! This is a request for discussion.. 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. You tell em' go linus

[RFD] Explicitly documenting patch submission

[Anonymous Coward]

This is the e-mail itself, as posted to LKML by Linus - on Sunday, not Saturday.

Posted anonymously to avoid karma whoring.

Re:[RFD] Explicitly documenting patch submission

[jap]

Um, no, as his message with the original date-header shows, it was written saturday linustime.

Re:[RFD] Explicitly documenting patch submission

[Hatfieldje]

"it was written saturday linustime"
Oh great, one more timezone to have to worry about. Question is... does he go along w/ daylight saving time?

Good Idea

[Whitecloud]

This sounds like a good way to ensure accountability on who made what changes, and when they did it. Linus says the SCO debacle "have provided a "big impetus" for the changes", this will make sure similar legal action can be shot down immediately.

Considering all the code thats been leaked lately, this is a welcome insurance policy to keep Linux on track as free alternative OS.

Link to Linus' Mailing List Post

[sgarrity]

Here's the post discussed in the article.

moderation of patches

[millahtime]

maybe they can put some kind of mod system in for the patches. like /. then those who add patches that aren't coded well could get moded down and have bad karma.

Re:moderation of patches

[magefile]

But then we'll have Linus and Co deciding they don't need to read patches, leading to Goatse in splash screens everywhere, ASCII/ncurses Goatse in the kernel compiling utilities.

Worse, we'll have the same "Soviet Russia" and "hot grits" patches released over and over!

Details?

[gpinzone]

The story is a little light on the details. The change management system they use (I remember hearing it was BitKeeper) ought to log the users who contributed the code automatically. What I'm wondering is if Linus is talking about validating the identity of the contributers. If so, this will prevent any anonymous code contribution. I wonder how many people who work for companies that signed NDAs are contributing code that will no longer be able to do so?

Re:Details?

[hughk]

I think it is more about having someone say that they own the copyright of the work and have the right to GPL it. It doesn't mean no anonymous contribs, but somebody (one of the people with BK commit access would have to be able to certify it on behalf of the other person so they should knwo the person even if it is never identified publicly.

Re:Details?

[miffo.swe]

Not many i would presume since its the contributors ass who gets fried and not Linus. To my knowledge most contributors is working with their companys blessing.

Re:Details?

[gpinzone]

Guess how fast the person who certifies the anonymous contributor will flip when he/she gets a subpoena from SCO? Like I said, it's the end of anonymous contributions.

Re:Details?

[hughk]

Good point. However, the person who issues the certification should also be sure of who it came from. You are right, it isn't true anonymity but the contributors name need never go into the kernel. It may just be replaced as a John Doe.

So, if a person submits some source code from NT to one of Linus's trusted assistents, they should query it. Unless there is a chain of provenance going back to Bill Gates, there is no release. However, Bill gates can still opt to submit code but request that his name is kept out of the change log.

Why do I get the feeling....

[10Ghz]

That we will soon see SCO/AdTI press-releases saying "we were right! There are serious problems with the way Linux-hackers handle the code! After all, if there are no problems, why are they taking these steps to correct the situation? This proves once and for all that our claims regarding Linux are true!"

Re:Why do I get the feeling....

[tfbastard]

And I've got a feeling SCO/AdTI would do the same should Linus decide to tie his shoes differently.

"Look! Linux suffers from clothing-related instabilities, why would Linus Torvalds do something like this unless Linux sucks?"

They're certainly not above it.

Re:Why do I get the feeling....

[linuxdoctor]

The problem is that SCO, Microsoft or any other company have even worse problems.

Unless and until a company has in place a development process that conforms to independent and internationally recognized standards such as ISO-9000 and has been certified as such you have no guarantee that what they are doing conforms to good engineering practices.

The truth is Linux development has always been open. SCO and other private companies keep their development process secret. Who knows what they are hiding behind all that secrecy.

For my money, I'd like to see Linux development conform to ISO-9000.

Re:Why do I get the feeling....

[jejones]

For my money, I'd like to see Linux development conform to ISO-9000.

Who would volunteer to be the official Linux Stupid Label Guy?

Re:Why do I get the feeling....

[pe1rxq]

Unless and until a company has in place a development process that conforms to independent and internationally recognized standards such as ISO-9000 and has been certified as such you have no guarantee that what they are doing conforms to good engineering practices.

Conforming to the ISO standards is no guarantee at all that a company isn't producing crap... The only thing you know is that they have followed a documented procedure to make crap.

Jeroen

Re:Why do I get the feeling....

[SEE]

ISO-9000 was not developed by an ISO-9000-conformant process. How can you trust it?

Thread on kerneltrap

[lazy_arabica]

You may read the lkml thread and Linus post on kerneltrap.
Just thought it could be interesting...

Re:Thread on kerneltrap

[Anonymous Coward]

The only difference between root and God is that I exist.

Which one are you, then?

Bad idea...

[mangu]

Think about the karma-whoring. Checking the relative length of up-moderated comments on /., one realizes that this system would contribute to a lot of "insightful" bloat. On the other hand, are we interested in getting "funny" one-liners?

His aim is different

[lazy_arabica]

Taken from Linus post (talking about SCO claims) :

People have been pretty good (understatement of the year) at debunking those claims, but the fact is that part of that debunking involved searching kernel mailing list archives from 1992 etc. Not much fun.

I suppose having lawyers read your private mail in order to find some clue about the origine of a piece of code make you a much more careful man.

Re:His aim is different

[Xzzy]

LKML is hardly private. Type darn near anything about linux into google and 50% of the results (or more) are going to be hits off that mailing list.

It's gotta be one of the most mirrored lists out there.

Re:His aim is different

[kasperd]

The list is even repeated on multiple newsgroups. Two of which are archived on google groups: fa.linux.kernel linux.kernel

This sounds good, but ...

[magefile]

Can it run Linux['s development processes]?

No Anonymous Code

[Short Circuit]

So what happens to people who want to contribute code, but don't want their name attached to it, for various reasons?

• Such as encryption development in France or China, where unauthorized encryption is illegal, IIRC.
  
• Or some employee whose boss wants to own all his creative work, on and off the clock.
  
• Or people who simply don't want to take the risk of being unfairly targeted by some software company for writing code that looks vaguely like the company's.
  
• Or people who had a great idea, but couldn't possibly know someone else had come up with the idea and copyrighted or patented it.
  
  
  IMO, it has its ups and its downs. It allows a greater degree of delegate-the-blame (Good for any large project, Objectively speaking), but it will reduce contributions.

Re:No Anonymous Code

[Atzanteol]

Those reasons are pretty good ones to have such a system in place. If you're submitting to the kernel, you should be *sure* there is nothing that can come back and bite you in the ass.

Re:No Anonymous Code

[Short Circuit]

So we're protecting potential developers from themselves? What about people who don't want that protection? Such as political dissidents in China?

Re:No Anonymous Code

[Atzanteol]

Then they don't donate code. I thought that was obvious.

Re:No Anonymous Code

[Anonymous Coward]

Simple: Use a pseudonym.

Re:No Anonymous Code

[Zathrus]

If you're submitting to the kernel, you should be *sure* there is nothing that can come back and bite you in the ass.

That's infeasible. In today's world with software patents, you expect every developer to do a patent search whenever they submit code? That's essentially what you're proposing you know. Requiring that everyone perform a $5k-50k search is going to cause a bit of a drop in kernel development I suspect.

In some cases I agree that the people shouldn't submit code -- particularly the intellectual property contract one (who owns the code on and off the clock). If you have an issue with that kind of contract, then strike the phrase before signing. Most companies won't care. Hell, if you're in a place with that contract alreaady, then talk to your management. Most of them will release you from that clause (mine has, at least verbally. If I was to ever want to excercise that right I'd have something a bit more substantial, if only email, prior to contributing). If they still won't, well, get your resume/CV prepared and start looking (no, don't be stupid and quit... just start looking for an alternative).

I'm all for the accountability, but, realistically, this is just a cover-your-ass move. It just means that if someone comes after OSDL in the future they may be able to disclaim legal liability.... straight onto the head of whoever did contribute the code.

Re:No Anonymous Code

[sweede]

This is the whole idea of the accountability thing.

If you live in china or where ever and dont want to get in trouble for writing encryption code, DONT. I mean how hard is that? If you choose to do something illegal you SHOULD be accountable for your actions and any repercussions from those actions. You probably bitch and moan on how you where going just "5mph" over the speed limit when you get pulled over for doing 50 in a 30 or complain that you were going around the block and didnt need a seatbelt.

If you sign a contract for work that says your employer owns all of the work you do during non-work hours, you should of read it first. If you did and you signed it anyways, dont bitch about having to give up everything you write.

If a closed source company tries to sue you for thinking that your code is close to theirs, you must ask yourself, how much water does their claim hold if there is no way you can view the sources? in a court case, you, the defense has a right to see their evidence against you, and the code that you are infringing on. You do have rights you know. This is easily solved by saying "whoops, I didnt know and i'll change/remove, show me which lines". Again, this is taking responsibility for your own actions. why do people think they can do things and not take any responsability for it? Worse yet, what if you where the project maintainer? since no one signed the code and now you submitted it, your name is on it and you are in trouble.

this last one is just stupid,
"Or people who had a great idea, but couldn't possibly know someone else had come up with the idea and copyrighted or patented it."

What about having a great idea, not doing jack about it, then 3 years later some company does the same thing and makes a mint from it? What can you do about it then?
you: "hey that was my idea 3 years ago and your violating GPL"
them: "oh ya, wheres your proof"
you: "oh right, i have none"

If you have a great idea that might or might not be copyrighted or patended and your too lazy to search around to see if it actually is, you shouldn't be contributing code to any project.

I guess the only downside that i can think of is that it holds people to take responsibility for what they do.

damn, I forget that's horrible!

Re:No Anonymous Code

[Short Circuit]

I try hold myself to the letter of the law. Sure, I speed. But I won't give the officer any lip when he gives me a ticket; I'll thank him for doing his duty to the community, and probably shake his hand.

As for the rest of this, I'm speaking on behalf of a huge number of projects...not just the Linux kernel.

If a closed source company tries to sue you for thinking that your code is close to theirs, you must ask yourself, how much water does their claim hold if there is no way you can view the sources? in a court case, you, the defense has a right to see their evidence against you, and the code that you are infringing on. You do have rights you know.

Yeah, but do you know how much it costs to defend those rights? How much it costs to come up with enough exculpatory evidence to convince a judge or jury that you didn't copy it?

All their lawyers have to do is bury your lawyer in a mountain of paperwork. And where are you going to get an who's affordable, competent, understands technology and understands IP law? Your best bet is going to be to call the EFF for help. And I don't know if they'd do anything for you if they don't consider your project pivotal to their cause.

And then there's your day job. How long is your boss going to allow you to skip work for the court case? If you don't skip work, how long is he going to tolerate the reduced quality due to stress? How are you going to travel back and forth to whatever district the company chose to file the suit?

If you live in china or where ever and dont want to get in trouble for writing encryption code, DONT.

Now, I know what I'm about to say will sound terribly selfish and attached to my own culture, but here goes: So much for progress... Do you think China would be dragging itself to a free market system if there weren't ways to smuggle information into the country? Information about how a hard worker can build a better life for himself? I don't know what France's problem is; I can only imagine it has to do with law enforcement.

Re:No Anonymous Code

[Alizarin Erythrosin]

What about having a great idea, not doing jack about it, then 3 years later some company does the same thing and makes a mint from it? What can you do about it then?

That's when you get an overly broad patent based on a generic idea, sit on it for a long time or wait for technology to evolve while filing extensions, then sue the pants off people once it becomes a commidity item!

Re:No Anonymous Code

[IncohereD]

That's infeasible. In today's world with software patents, you expect every developer to do a patent search whenever they submit code? That's essentially what you're proposing you know. Requiring that everyone perform a $5k-50k search is going to cause a bit of a drop in kernel development I suspect.

If you're a halfway competent developer I'd hope that you'd be able to tell the difference between code you write that is new and potentially unique, versus run of the mill bugfixes and driver updates. And new, good ideas will probably have been discussed on the list, or in other literature, and you should have an idea which ones are or are not encumbered.

I see a parallel...

[IGnatius T Foobar]

This sounds a lot like the school of thought which suggests that "If you allow yourself to live in fear, then the terrorists have already won."

It isn't much of a stretch to draw a parallel and assert that "If you allow yourself to live in legal paranoia, then SCO has already won."

Google link to full text

[quixoticsycophant]

text

Re:Linux is just the kernel

[Anonymous Coward]

Rubbish. GNOME wipes the floor with OSX? You're mad. KDE comes close, if set up right (i.e. if redhat haven't been anywhere near it), but GNOME????

The original thread

[42forty-two42]

Here's the thread in question.

Hacking attempts

[Anonymous Coward]

Perhaps this will also help to avoid attempts from hackers to insert backdoors as we have seen recently..

Authentication Process

[Master Eclipse]

The authentication needs to be done using GPG (GNU Privacy Guard) or PGP (Pretty Good Privacy). This will prevent anyone in the future from inappropriately placing code in the kernel. These two programs provide an excellent means of determining the authenticity of the author. Moreover, the origins of all code submissions can easily be tracked and catalogued using some open source software some friend of mine and I have been working on. In a nutshell it works like this: Code is received either by FTP, E-mail or (virtually) any other mans. At the end of the encrypted code, the code is signed and encrypted with the writer's key. Each of these keys is kept in a database that contains verified information about the writer. This can include their name, and address, or whatever is appropriate. This database is kept as a public record of which code belongs to whom, and when it was created (or submitted). Think about it... anybody who wants to submit code should not be able to do so anonymously. This stands to reason in light of what has been going on lately with SCO. Moreover, this method looks good to executives who have no idea how software is developed and is a legitimate method of proof. So far as being on the Internet, this project is not right now, some friends of mine and I at the University have been beta testing it and it works wonderfully and is very secure. Thank you for your interest!!!! Any thoughts?

Re:Authentication Process

[Anonymous Coward]

So you are talking about using a PKI solution to sign the data, providing identification and integrity. Yes, these systems are ever so slightly common already.

Re:Authentication Process

[mike260]

Something similar was discussed and rejected by Linus on LKML.
Read the original thread, pointed to by several posters.

Re:Authentication Process

[JarekC]

The authentication needs to be done using GPG (GNU Privacy Guard) or PGP (Pretty Good Privacy). [..] These two programs provide an excellent means of determining the authenticity of the author.

These programs would NOT guarantee authenticity of the author.

As you probably know the whole idea of PGP is based on a web of trust, which in turn is based on signing your public key by peers, after they verified your identity. And this peer-based verification is the weak point of establishing TRUE identities.

First of all establishing a web of trust would be difficult, because it requires everyone to meet at least one other person face-to-face in order to check each other's ids and exchange key signatures. This alone is quite troubloesome for such a diverse community as Linux kernel devs.

Second, kernel devs are not typically trained in spotting a fake, or even completly bogus, ids. Even if we met face-to-face, could you - by checking my Ukrainian ID - gurantee that I REALLY am who I claim I am?

Re:Linux is just the kernel

[soloport]

Rubbish. GNOME wipes the floor with OSX? You're mad. KDE comes close, if set up right (i.e. if redhat haven't been anywhere near it), but GNOME????

So true. I'm running KDE on Fedora Core 2 and it is simply a dog (1.2MHz uP). I don't know what RedHat has done to KDE, but the diference between it and KDE on other distros is stark!

However, I have no idea which way to go from here. Buck up and learn to stomach Gnome? Find a distro that is more KDE-centric? Fedora still seems to be the best at supplying recent packages and easy server setup.

Just what I've been on about!

[Paul Fernhout]

And it did not attract much interest back then. Maybe now is the time for such a peer-to-peer repository tool with related free licensing affirmations. 2001 posting to gnu.misc.discuss and further: second 2001 posting to gnu.misc.discuss

Excerpt from the first: So anyway, what do people think? Would such a license management approach with tools, protocols, and standards (ensuring every work received or sent comes with a legally binding machine-readable license and related audit trails for derived works) promote more clearly titled (in a legal sense) free software or would it be the slippery slope to the "right-to-read" future? Without explicit licensing handling, are we just setting the free software or open content communities up for legal challenges down the road as people just try to do their best without such tools? Is trying to automate license handling really that much different (in a bad way) from the current situation of often distributing zip files including both content and license?

Excerpt from the second: This need for a license is especially true for making derived works you plan to redistribute, because here your liability seems highest. If we are to have a lot of free software and free content, based on fine grain collaboration made possible by the internet allowing us to rapidly modify each others works, that is a lot of licenses citing a lot of authors. If these licenses get lost (as in the midi file download example I cited), the content can no longer be considered free. Handling lots of papers is what computers are good at. The less time people need to spend thinking about, negotiating, and managing paperwork and extra files related to free licenses, the more time they can spend making free software and free content.

[RFD] Explicitly documenting patch submission

[Stefan2100]

Here is the full posting by Linus and the live comments thread on LWN: [RFD] Explicitly documenting patch submission

Open source has different risks

[xyote]

based on detectability of infringement of IP. Typically patenting something is only useful if usage of it is detectable. Normally you don't have access to source so you have to infer it from behavior and that behavior has to be fairly unique. For example, if all you have is O(log n) and there are ten other algorithms with O(log n) you will have a difficult time making a case for infringement. To say nothing of why you patented something that was not an improvement on existing art.

Not only does having the source make detection of infringement easier, it also makes patenting of otherwise completely indetectable algorithms feasible. Feasible that is if someone (SCO anyone?) can establish a precedent for making money by filing lawsuits against users of open source. This could get really bad given the USPTO's tendency to issue nonsense patents which will really lend themselves to being submarine patents due to their trivialness.

Re:Open source has different risks

[Anonymous Coward]

Normally you don't have access to source so you have to infer it from behavior and that behavior has to be fairly unique. For example, if all you have is O(log n) and there are ten other algorithms with O(log n) you will have a difficult time making a case for infringement.

Uh, what?

Have you heard of this little thing called a "disassembler", which lets you examine the inner workings of a program without access to source code?

What disassemblers don't do is make it trivial for you to modify or use the code. They do make it possible for you to see what it does, and that's enough for you to prove what algorithm it's using.

Re:Open source has different risks

[xyote]

I've done that with DOS 1.0. Present kernels are quite a bit larger than that now. I don't know how practical that would be unless you had a pretty good idea where to look. Sometimes that's possible but there wounldn't be any guarantee.

When?

[miffo.swe]

Now that the Linux development is totally transparent when will we be able to audit Microsoft, SCO, and other propriarity code for stolen bits and pieces?

We should shout out of the top of our lungs that the propriarity way foster code stealing because no one can audit it.

Re:When?

[vijaya_chandra]

when MS decides to replace kernel.dll with vmlinuz-2.x.x-xx

Re:When?

[The Bungi]

Now that the Linux development is totally transparent when will we be able to audit Microsoft, SCO, and other propriarity code for stolen bits and pieces?

Linux has existed for more than 10 years. Is it just now that the process is "totally transparent" to you? What about the whole BitKeeper issue (not that I think it is an issue, but many people do)? Have you decided that this month-old scheme will be absolutely successful?

And further, what exactly gives you the right to demand that Microsoft (or any other commercial software developer) try to prove a negative to you? Because your code can now be "audited"? The Windows source code is and has been available to a lot of people for many years. Given that it can be leaked wholesale, do you think for a second that no one would have found a way to get the word out that it contains "stolen" code from some open source project?

That Microsoft would ever open themselves up to trouble by using code that is not theirs without a proper license is just wishful teenage thinking. One of those memes like the "hidden APIs" in Windows which have been proven totally untrue time and again.

We should shout out of the top of our lungs that the propriarity way foster code stealing because no one can audit it.

By your own reasoning SCO has a case because I could not "audit" the Linux code before yesterday. And given the sheer number of GPL violations in the past few years I could definitely make a case that open source also "fosters" code stealing.

Try to think before you "shout out of the top of your lungs".

Re:When?

[miffo.swe]

Linux development has always been transparent. A deep dig into lkml can reveal every bit and piece that got into the kernel. Since the source is free it is already very easy if some company suspects foul play to compare sources, find who submitted what and go forward. The difference now is that it is totally transparent without any digging into forums.

The thing that bugs me is that Microsoft is running around claming linux is a heaven to pirates and bad people in general when its very hard to find a single MS Windows computer without any pirated software on it. Topping that they charge open source to steal things and plagiate and such. That just makes me so mad.

The hidden APIs is not whole APIs but rather undocumented "features" in them that lets MS use hooks that no one else can use.

MODERATOR MADNESS

[hummassa]

there is no "development tree" at the moment. the 2.6 kernel tree is being managed by Linus. Andrew Morton is not yet in complete charge of it. development tree will be 2.7.

Re:MODERATOR MADNESS

[Anonymous Coward]

Next thing you'll tell me that Gates isn't Microsoft's CEO or that Michael's handing off the Dell CEO title -- or would anyone who said such nonsense be moded down.

(In Dells case, it was to the singer of Black Flag, wasn't it)

Heh...

[Anonymous Coward]

And I wonder why the submitter didn't think to link to the same story on Groklaw!

Go figure?

Do "professional" organizations do this?

[ron_ivi]

"Linux joined the world of professional software development!!"

Do companies like Microsoft or Sun make Developers certify that the code they submit in a particular check-in isn't "borrowed" from GPL'd or other open source stuff?

Seems Linux is well ahead of professional organizations in this respect.

Re:Do "professional" organizations do this?

[bonch]

Do companies like Microsoft or Sun make Developers certify that the code they submit in a particular check-in isn't "borrowed" from GPL'd or other open source stuff?

Well, as a matter of fact, yes they do. In a lot of professional contracts it's even stated that people pledge not to plagiarize code. It would make the company liable for something.

It's not like the code for something like, say, Windows, is locked away in a vault where no one will ever know if code was plagiarized or not. Lots of people have access to that code, including several major universities. Microsoft signs it out to people on a regular basis.

Re:Do "professional" organizations do this?

[Anonymous Coward]

Then why couldn't Linux just get away with a pledge that people didn't plagerize, to free itself from liability?

Re:Linux is just the kernel

[bicho]

I think the main problem with Fedora and/or Redhat and maybe other distros is that they still produce binaries thinking on a i386.

Re:Linux is just the kernel

[Short Circuit]

I'm not sure, but I think the Debian project compiles x86-32 packages for i686.

Re:Linux is just the kernel

[sprprsnmn]

Not quite. The -march flags in gcc will change the ABI so that the programs can only run on that (or better) cpus. Debian compiles with the -mcpu flags which organizes intruction to be nice to certain processors (align on WORD boundaries and whatnot) without actually breaking the support for lower processors. Debian will still boot on a true 386 machine, but you'd have to be a masochist to want that.

Amateurs

[amightywind]

The sheer number of significant changes the kernel team is making between releases is amazing. Not bad for amateurs. Legal matters go with the territory however. It is a measure of the fear Linux has created in the industry. I used to think ESR's rhetoric about Linux winning the OS war through sheer numbers was wrong. Not anymore. The constancy of the effort is also amazing. It is very satisfying to be able to download a vanilla kernel to my Gentoo system, build it for my configuration and watch the machine run perfectly.