[opensuse] SCO is toast... Novell go get em
http://www.groklaw.net/article.php?story=20061129165103775 Well, it looks like SCO isn't going to get to use their *evidence* because de judge has slapped them hard with a devastating ruling... basically upholding the lower court's ruling that a sanction is warranted because SCO willfully violated discovery rules. ooops, SCO is toast, and Groklaw is vindicated. Go get em Novell... I'm rooting for you ! (trial coming up) ... and the good news is, you're going to have some new bucks to pursue the case--- from the M$ deal. cool~ huh? Ok Suse fans I have a very serious question for yous guys (and please don't tell me its off topic, cause it aint, so stay in your chair) .... I want to know who puts code into the kernel... please don't laugh... I'm serious. In other words, how in the world can SCO (or anybody else) accuse IBM (as a sole entity) of placing anything willfully into the kernel, when the kernel is not controlled by IBM, and when the kernel is contributed to from kernel developers world-wide...??? How much of the kernel comes from Novell? How much from Shuttleworths folks..??? how much from Redhat...oooops, I mean IBM?? yeah, right.... Look, either the kernel has System V code in it (copyright protected, or patented, or both) or it doesn't. This shouldn't be about discovery rules in a court of law for crying out loud. Either copyrighted code is in the kernel or not, and if so why can't SCO prevail??? (they shouldn't and I don't want them to, just a hypothetical question--) But that is not my real question... my real question is this: How hard would it be to pull M$ hooks out of the kernel (once they're in there) if and when they get discovered a year from now... ? ha-uummm??? Would it take a court order? ---years of litigation? you know... discovery, summary judgment petitions, rules and thousands of pages of B$ .... and all the time M$ has hooks into the kernel... Let's make sure from the top that that does not happen... please? -- Kind regards, M Harris <>< -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On November Thursday 30 2006 1:48 pm, M Harris wrote:
http://www.groklaw.net/article.php?story=20061129165103775
Well, it looks like SCO isn't going to get to use their *evidence* because de judge has slapped them hard with a devastating ruling... basically upholding the lower court's ruling that a sanction is warranted because SCO willfully violated discovery rules. ooops, SCO is toast, and Groklaw is vindicated.
Go get em Novell... I'm rooting for you ! (trial coming up)
... and the good news is, you're going to have some new bucks to pursue the case--- from the M$ deal. cool~ huh?
Ok Suse fans I have a very serious question for yous guys (and please don't tell me its off topic, cause it aint, so stay in your chair) .... I want to know who puts code into the kernel... please don't laugh... I'm serious. In other words, how in the world can SCO (or anybody else) accuse IBM (as a sole entity) of placing anything willfully into the kernel, when the kernel is not controlled by IBM, and when the kernel is contributed to from kernel developers world-wide...??? How much of the kernel comes from Novell? How much from Shuttleworths folks..??? how much from Redhat...oooops, I mean IBM?? yeah, right....
Look, either the kernel has System V code in it (copyright protected, or patented, or both) or it doesn't. This shouldn't be about discovery rules in a court of law for crying out loud. Either copyrighted code is in the kernel or not, and if so why can't SCO prevail??? (they shouldn't and I don't want them to, just a hypothetical question--)
But that is not my real question... my real question is this: How hard would it be to pull M$ hooks out of the kernel (once they're in there) if and when they get discovered a year from now... ? ha-uummm??? Would it take a court order? ---years of litigation? you know... discovery, summary judgment petitions, rules and thousands of pages of B$ .... and all the time M$ has hooks into the kernel...
<Snip> As I understand it, the kernel code is still under the control of Linus and his group. Nothing goes in til they agree. I can't see why he would let MS or anyone else put things into the kernel that he wouldn't allow now. And there are lots of , erm, heated discussions on the kernel list .. which is not part of any distro BTW .. No one who does distribute Liux code is going to do anything dumb, like fork to their own kernel version . And then BTW lost out on all that free labour. I could be wrong here, but I believe Red Hat and Suse et al, have people who also work on kernel stuff.. it's part of their contribution to the community, however , no one is going to get anything into the kernel that would render it inoperable by all of the rest of the community. Linus has worked for company in the past and didn't lean the kernel towards that product ( hardware ) I see no reason why he would do so now... but if you are so certain of your facts, perhaps you should take it up w/ the kernel list, and get your answers from the people who really do know. -- j If a hurricane doesn't leave you dead It will make you strong. Don't try to explain, just nod your head . Breathe in breathe out , move on. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 11/30/06, M Harris <harrismh777@earthlink.net> wrote:
[...]
Look, either the kernel has System V code in it (copyright protected, or patented, or both) or it doesn't. This shouldn't be about discovery rules in a court of law for crying out loud. Either copyrighted code is in the kernel or not, and if so why can't SCO prevail??? (they shouldn't and I don't want them to, just a hypothetical question--)
Because there are no copyright protected or patented code in the kernel. If there ever really was, then SCO would put the evidence on the table and the case could go on.
But that is not my real question... my real question is this: How hard would it be to pull M$ hooks out of the kernel (once they're in there) if and when they get discovered a year from now... ? ha-uummm??? Would it take a court order? ---years of litigation? you know... discovery, summary judgment petitions, rules and thousands of pages of B$ .... and all the time M$ has hooks into the kernel...
I don't follow. What hooks might MS have in the kernel and how would that get in the kernel in the first place? -- Andre Truter | Software Consultant | Registered Linux user #185282 Jabber: andre.truter@gmail.com | http://www.trusoft.co.za ~ A dinosaur is a salamander designed to Mil Spec ~ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 30 November 2006 13:07, Andre Truter wrote:
I don't follow. What hooks might MS have in the kernel and how would that get in the kernel in the first place? Please be patient with me on this because I'm making it up as I go along... but how about this hypothetical scenario:
Suse gets (permission) to install proprietary drivers (using existing kernel hooks) which provide genuine *interoperability* at the cost of degraded performance. In other words compatible kernel modules could conceivably be introduced (not Linus sanctioned) into the distro (I can change the kernel if I want to, for crying out loud) that may or may not provide *interoperable* functionality, but would provide deliberate performance degradation. [ this might have been done on exiting platforms in the past in order to slow down say, Netscape ] Yes, it would be detected, and some folks might even be sharp enough to patch it and publish their findings, but the damage would be done. If the damage were subtle enough, it might not even be suspected immediately. But even if it is suspected, it would take time and money to search, remove, and/or remedy the damage. I agree that no distro company would be foolish enough to fork their own kernel version... but its not inconceivable. I want a promise from Novell that the kernel will be controlled by the community outside of the Novell corporate environment... and not under the monetary control of M$. -- Kind regards, M Harris <>< -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 30 November 2006 20:31, M Harris wrote:
Suse gets (permission) to install proprietary drivers (using existing kernel hooks)
Will you get it through your head that Novell has purged ALL proprietary non-GPL drivers from the shipped distributions, because it is not GPL compatible. If you know anything at all about kernel development and kernel developers, the following should say it all: Novell's head of kernel development is Greg Kroah-Hartman. With that said, anyone who still thinks the company would willfully commit a GPL violation needs his head examined, and I don't mean that as a humorous exaggeration. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 30 November 2006 13:47, Anders Johansson wrote:
Novell's head of kernel development is Greg Kroah-Hartman. Now we're getting someplace...
... this is what I am really getting at... and I genuinely am seeking knowledge; what does it mean to be head of kernel development at Novell? ... or anywhere else for that matter? (see Greg Freemyer's explanation) Is the kernel that ships with Suse the "official" kernel that I can download from the official site unmodified <?> or, is it modified by kernel development at Novell? note: I am not asking whether the kernel has non gpl code at this point... only whether Novell kernel development modifies the official kernel before redistribution and redistributes it under the gpl license, or--- whether Novell modifies the kernel via the process Freemyer described? And I have another question along the same lines... consider: "Linux 2.6.15 consists of 18,811 files and 7,290,070 lines of code." Folks, that's a lot of lines of code... what I want to know is how many of them were coded (patched) by Novell kernel development? What do those patches do? How many of those patches, or future patches, will M$ control behind the scenes... and if Freemyer's explanation is correct... how can we be sure that the "patches" that get through are *ok*. And I don't mean gpl vs non gpl... and I don't mean legal vs illegal... this is a control issue for me... I mean, controlled by M$ to provide degradation of performance, or a back-door, or anything else... that gets slipped by the watch-dogs on the Linus team----- * -- Kind regards, M Harris <>< -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 30 November 2006 21:29, M Harris wrote:
On Thursday 30 November 2006 13:47, Anders Johansson wrote:
Novell's head of kernel development is Greg Kroah-Hartman.
Now we're getting someplace...
... this is what I am really getting at... and I genuinely am seeking knowledge; what does it mean to be head of kernel development at Novell?
It means being in charge of the team that does kernel development at SUSE Linux Products GmbH. This means, aside from the normal administration things all managers have to suffer through, being in charge of fixing kernel related bugs in the SUSE kernel. For a closer job description, you'd have to ask Greg himself
Is the kernel that ships with Suse the "official" kernel that I can download from the official site unmodified <?> or, is it modified by kernel development at Novell?
Yes it's modified. The goal is to have a version as close to kernel.org as possible, but the kernel version is frozen at the time of release. For example, SLES 9 shipped with kernel 2.6.5. Since that time there have been numerous bug fixes in the kernel.org kernel, and the ones relevant to the SLES 9 kernel get backported Also, there are drivers being maintained outside kernel.org, and they get patched when there are bugs or other problems All differences are kept as separate patch files in the src rpm, along with clear indications of which bug numbers they fix
Folks, that's a lot of lines of code... what I want to know is how many of them were coded (patched) by Novell kernel development?
Browse through the patch files in the src rpm. They are all kept separate and each patch is reasonably small and self contained (so the developers can have an easier time deciding if a patch is good or not)
What do those patches do?
Feel free to cross reference the bug numbers with the entries in bugzilla.novell.com
How many of those patches, or future patches, will M$ control behind the scenes...
bite me -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On November Thursday 30 2006 3:46 pm, Anders Johansson wrote: <snip>
What do those patches do?
Feel free to cross reference the bug numbers with the entries in bugzilla.novell.com
How many of those patches, or future patches, will M$ control behind the scenes...
bite me
And *that* is why we couldn't let you drift out of the Linux, and Suse linux world when you tried to get away, Anders, common sense is one thing, educated informed common sense , such as yours is just too valuable an asset to lose! ;) I guess for folks who will insist that the henhouse is now unguarded, we can never convince them. but until I get a fresh new copy of Suse 10.2 I probably will keep trying, for my sins, it's my punishment. Still, I like Suse's packages and I will wait for the boxed set. Even if later they require me to go find other packages.. But isn't Amarok doing mp3? and every sound player does ogg-vorbis IIRC. It just ain't that hard kiddies, if blonde lil ole me can do it just about anyone can. ( I'm assuming there are a few new souls on the list who may not know ;) ) BTW, you get bonus GK points for the week end. You made me laugh, and that is good enough for this week. -- j If a hurricane doesn't leave you dead It will make you strong. Don't try to explain, just nod your head . Breathe in breathe out , move on. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 11/30/06, M Harris <harrismh777@earthlink.net> wrote:
On Thursday 30 November 2006 13:47, Anders Johansson wrote:
Novell's head of kernel development is Greg Kroah-Hartman. Now we're getting someplace...
... this is what I am really getting at... and I genuinely am seeking knowledge; what does it mean to be head of kernel development at Novell? ... or anywhere else for that matter? (see Greg Freemyer's explanation)
Is the kernel that ships with Suse the "official" kernel that I can download from the official site unmodified <?> or, is it modified by kernel development at Novell? note: I am not asking whether the kernel has non gpl code at this point... only whether Novell kernel development modifies the official kernel before redistribution and redistributes it under the gpl license, or--- whether Novell modifies the kernel via the process Freemyer described?
And I have another question along the same lines... consider:
"Linux 2.6.15 consists of 18,811 files and 7,290,070 lines of code."
Folks, that's a lot of lines of code... what I want to know is how many of them were coded (patched) by Novell kernel development? What do those patches do? How many of those patches, or future patches, will M$ control behind the scenes... and if Freemyer's explanation is correct... how can we be sure that the "patches" that get through are *ok*. And I don't mean gpl vs non gpl... and I don't mean legal vs illegal... this is a control issue for me... I mean, controlled by M$ to provide degradation of performance, or a back-door, or anything else... that gets slipped by the watch-dogs on the Linus team----- *
If you look at the SUSE Kernel source RPM (or any other SUSE source RPM) you will see it has a few different sections. One big section is the vanilla kernel code. ie. Straight from www.kernel.org as released by Linus Torvalds. Then you will find another section that is just a bunch of patches. I have not looked recently, but in the pre-Novell days it was hundreds of patches. These are all patches that get applied to the vanilla source prior to it being compiled. None of those patches have been formally accepted into the vanilla kernel by Linus. This is typical of _every_ distribution. Particularily in 2004-2005 the vanilla kernel team never released any patches to released kernels, so if for instance 2.6.12 was found to have a bug then the vanilla kernel people would say "sorry not my problem, we will get the fixed in our next full release which will be 2.4.14". This practice made it mandatory for the distro people to accept and maintain patches for the kernels they had based a release upon. At some point in the last year, the kernel team assigned GregKH to be the stable kernel maintainer. (I may have that title wrong and this has nothing to do with Novell, except possibly he does this on company time). As such job is to track serious bugs in the released kernel and accept patches to it for formal release from www.kernel.org. So prior to today's release of 2.6.19, GregKH would have been solely responsible for accepting patches into the 2.6.18 series. So 2.6.19 just made the transition. Prior to its release today (or yesterday) it was under Linus Torvolds pervue. Now that it is released GregKH will handle any additional patches it gets and will handle point releases like 2.6.19.1 In addition to the above GregKH is the USB subsystem so for the about to begin 2.6.20 series of prerelease kernels all USB subsystem patches have to be submitted to him. He will collect them up and submit them to Linus in batches. It is a general rule that during the first 2 weeks after a full release feature enhancement patches will be accepted by Linus, then only bug-fix patches until the next full release. So for USB GregKH should have been collecting new feature enhancement patches for the last couple of months. He now has 2 weeks to submit those to Linus. At that point the "merge window" closes and Linus will only accept bugfix patches. Typically it takes a couple of months to get the next release stable, so 2.6.20 will likely be released about 2 1/2 months from now. FYI I don't know what GregKH's duties are at Novell and I didn't know he worked for them, but most of the core Linux Kernel team is employed in the Linux industry, so it is not much of a surprise that he does. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
M Harris wrote:
On Thursday 30 November 2006 13:47, Anders Johansson wrote:
Novell's head of kernel development is Greg Kroah-Hartman. Now we're getting someplace...
... this is what I am really getting at... and I genuinely am seeking knowledge; what does it mean to be head of kernel development at Novell? ... or anywhere else for that matter? (see Greg Freemyer's explanation)
Is the kernel that ships with Suse the "official" kernel that I can download from the official site unmodified <?> or, is it modified by kernel development at Novell? note: I am not asking whether the kernel has non gpl code at this point... only whether Novell kernel development modifies the official kernel before redistribution and redistributes it under the gpl license, or--- whether Novell modifies the kernel via the process Freemyer described?
It is a SuSE modified kernel for SuSE's dist only. The additions SuSE put into it are only 'blessed' by SuSE not by the 'official' kernel community.
And I have another question along the same lines... consider:
"Linux 2.6.15 consists of 18,811 files and 7,290,070 lines of code."
Folks, that's a lot of lines of code... what I want to know is how many of them were coded (patched) by Novell kernel development? What do those patches do? How many of those patches, or future patches, will M$ control behind the scenes... and if Freemyer's explanation is correct... how can we be sure that the "patches" that get through are *ok*. And I don't mean gpl vs non gpl... and I don't mean legal vs illegal... this is a control issue for me... I mean, controlled by M$ to provide degradation of performance, or a back-door, or anything else... that gets slipped by the watch-dogs on the Linus team----- *
SuSE, but only SuSE, controls every line of code in every kernel they ship. But kernels they ship are NOT the 'official linux kernel'. The only way to get that is from kernel.org. And every thing there goes through the 'official kernel community' before it is released. I can only assume that the 'official kernel community' would catch anything 'wrong' that a possible Novell employed contributor might contribute or attempt to contribute. However if I'm not mistaken SuSE does employ some considered 'in the official kernel community'. Even so, very few lines of code get in the official kernel without many people seeing them first. Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 11/30/06, M Harris <harrismh777@earthlink.net> wrote:
On Thursday 30 November 2006 13:07, Andre Truter wrote:
I don't follow. What hooks might MS have in the kernel and how would that get in the kernel in the first place? Please be patient with me on this because I'm making it up as I go along... but how about this hypothetical scenario:
Suse gets (permission) to install proprietary drivers (using existing kernel hooks) which provide genuine *interoperability* at the cost of degraded performance. In other words compatible kernel modules could conceivably be introduced (not Linus sanctioned) into the distro (I can change the kernel if I want to, for crying out loud) that may or may not provide *interoperable* functionality, but would provide deliberate performance degradation. [ this might have been done on exiting platforms in the past in order to slow down say, Netscape ]
You are talkin here about a 3rd party kernel module, like for instance the NVidia or ATI drivers. I can write a kernel module that does nothing productive, all it does is it writes a 1 into a file every time the system clock reaches a primary number. But my module (or NVidia's or ATI's) does nothing to the kernel itself, it is not part of the kernel and will never become part of the kernel, so it cannot affect the kernel at all. I cannot gain any form of control over the kernel or it's design or it's future by distributing my module, because it is not part of the kernel. Even if the kernel developers think that my module is very cool and they accept it as an official kernel module that will be distributed with the kernel, then I still have not control over the kernel or any other module. I will have to GPL my module and it will be under the scrutiny of the other kernel developers and if I suddenly decide to change my module to write "MS Rulez" in the file instead of the 1, then my module will most probably be kicked out of the list of supported kernel modules and I would still not have gained anything.
Yes, it would be detected, and some folks might even be sharp enough to patch it and publish their findings, but the damage would be done. If the damage were subtle enough, it might not even be suspected immediately. But even if it is suspected, it would take time and money to search, remove, and/or remedy the damage.
You would have to write a REALLY, REALLY good module that will affect kernel performance (or any performance or negative effect) so that it will be noticed by users and not by the kernel testers. If anything has an affect to such an extent that it would do damage that users will notice, then the kernel developers and testers will have to be totally blind to oversee it before it is accepted as a module. This situation is just not very practical. I think we have a better chance of being hit by an egg that was thrown on one of the planets in the Alpha Centauri system that managed to escape the gravity and atmosphere....
I agree that no distro company would be foolish enough to fork their own kernel version... but its not inconceivable. I want a promise from Novell that the kernel will be controlled by the community outside of the Novell corporate environment... and not under the monetary control of M$.
How can it ever be controlled by MS, or even Novell. No corporation controls the kernel, only the kernel team controls it. Novell can go totally nuts and employ Steve Ballmer as thier new head of kernel development and it would still not make a difference, because the only way that those contributions would be accepted into the kernel is if aliens brainwashed Linus Torvalds and took over his body and got bought out my MS. This whole idea is inconceivable... -- Andre Truter | Software Consultant | Registered Linux user #185282 Jabber: andre.truter@gmail.com | http://www.trusoft.co.za ~ A dinosaur is a salamander designed to Mil Spec ~ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 30 November 2006 21:33, Andre Truter wrote:
Even if the kernel developers think that my module is very cool and they accept it as an official kernel module that will be distributed with the kernel, then I still have not control over the kernel or any other module. I will have to GPL my module and it will be under the scrutiny of the other kernel developers and if I suddenly decide to change my module to write "MS Rulez" in the file instead of the 1, then my module will most probably be kicked out of the list of supported kernel modules and I would still not have gained anything.
More likely, the original module - assuming it was useful - will be kept, but the patch to break it won't be accepted and you will no longer be the maintainer of it -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 30 November 2006 10:07, Andre Truter wrote:
Because there are no copyright protected or patented code in the kernel.
To be perfectly pedantic, I think you will find the entire kernel is copyright protected. Just look at any source module. -- _____________________________________ John Andersen
On 12/1/06, John Andersen <jsa@pen.homeip.net> wrote:
On Thursday 30 November 2006 10:07, Andre Truter wrote:
Because there are no copyright protected or patented code in the kernel.
To be perfectly pedantic, I think you will find the entire kernel is copyright protected. Just look at any source module.
I meant that there are no code that is copyrighted by someone else or patented by someone else. All the code is copyrighted under GPL. -- Andre Truter | Software Consultant | Registered Linux user #185282 Jabber: andre.truter@gmail.com | http://www.trusoft.co.za ~ A dinosaur is a salamander designed to Mil Spec ~ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 11/30/06, M Harris <harrismh777@earthlink.net> wrote:
Ok Suse fans I have a very serious question for yous guys (and please don't tell me its off topic, cause it aint, so stay in your chair) .... I want to know who puts code into the kernel... please don't laugh... I'm serious.
I don't know how it worked historically, but today: Linus Torvalds is the ultimate kernel maintainer, so in theory he accepts and reviews each and every patch. Realistically he can't do that so he has a bunch of lieutenants. Specifically second in command (Andrew Morton) typically accepts patches of a general nature. Then for specific subsystems there is typically an assigned maintainer that can accept patches for that subsystem. Then at the specific driver level there is typically a maintainer for the driver. So in theory a patch has to get buy-in from all of the above for it to get in, but that has little to do with copyright / patent issues. The above is primarily technical buy-in and nobody is checking to ensure the code is legal to put into the GPLed kernel. The one exception is with each patch submission at any level the submitter themselves is supposed to include a "Signed off by" line. The purpose of this is to state that they know the origins of the patch they are submitting and that it can be legally placed under the kernels GPL license. Obviously it is very hard to know how well that works. Especially if the claimed violation is a patent issue where even independently derived code that performs the same function could be a violation. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 30 November 2006 19:48, M Harris wrote:
Look, either the kernel has System V code in it (copyright protected, or patented, or both)
copyright and contract protected. There were no software patents back then
But that is not my real question... my real question is this: How hard would it be to pull M$ hooks out of the kernel (once they're in there) if
What on earth do you think a "hook in the kernel" is? Usually a kernel hook is a function exposed to third party modules. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (7)
-
Anders Johansson -
Andre Truter -
Greg Freemyer -
jfweber＠gilweber.com -
John Andersen -
M Harris -
Mark Hounschell