Process Improvements in the Kernel Development 124
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."
Good Idea (Score:3, Insightful)
Accounting (Score:4, Insightful)
A Good Thing(tm) (Score:5, Insightful)
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.
Avoid even the appearance.. (Score:5, Insightful)
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:Accounting (Score:5, Insightful)
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
Details? (Score:4, Insightful)
Why do I get the feeling.... (Score:5, Insightful)
Re:A Good Thing(tm) (Score:4, Insightful)
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:This quote says it all (Score:5, Insightful)
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:Why do I get the feeling.... (Score:4, Insightful)
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.
No Anonymous Code (Score:5, Insightful)
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:Why do I get the feeling.... (Score:3, Insightful)
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:No Anonymous Code (Score:3, Insightful)
Hacking attempts (Score:2, Insightful)
Authentication Process (Score:4, Insightful)
Re:heheh (Score:5, Insightful)
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.
Just what I've been on about! (Score:4, Insightful)
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.
Re:heheh (Score:2, Insightful)
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.
Do "professional" organizations do this? (Score:4, Insightful)
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:No Anonymous Code (Score:3, Insightful)
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 (Score:4, Insightful)
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:A good thing. (Score:3, Insightful)
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.