These guys are making millions of dollars each year, while most of you DO NOT. There must be something they're doing right
Yes: they have an OS monopoly, great marketing, and vicious business practices. Whether their engineering or design practices are any good doesn't matter (they have improved, though).
Financial success is not an indicator of good products or good business practices.
so if you want OSS to succeed, steal some of it instead of dismissing it like 5 year olds
FOSS is doing just that: Linux desktops are so Windows-like that it makes many UNIX users want to puke. Even many known, bad design decisions are carried over from Windows just to make Windows users happy. But leave us the right to at least complain about it. Oh, and, yes, Linux distributions have those sounds.
No, the problem is neither logistics, nor availability of developers, not resources, it's priorities: making bug-free products simply doesn't matter much to Microsoft's bottom line, so they don't bother. What matters to them is fast time-to-market, long feature lists, and backwards compatibility, and all of those are in serious conflict with removing bugs.
(Linux developers have a slightly different set of constraints, but end up making many of the same bad choices as Microsoft developers.)
Or, as works with EVERY public forum. "Things you post in a public space are public knowledge and use.
There are actually quite a few companies that post source code and other information on the web with licenses that impose obligations on you if you as much as look at it.
For example, go to the Sun web site and look at the licenses under which they make Java documentation and source code available; read them carefully and then roll your eyes.
Different colleges have different goals and approaches; you need to pick your college to go with your goals. Many CS majors do not go on to become software developers, so it is perfectly legitimate for a college not to include project development experience in their courses. Even if you picked such a college, nothing prevents you from participating in one of the many open source projects or to start your own.
If you're infringing on a patent, you can't just replace the code with a rewrite; you have to remove the very idea from your code.
Wrong. You merely have to find something that the patent doesn't "read on"; often, that's just a small variation on the patented method.
Furthermore, we have a couple of decades of experience with this. There have been numerous patent claims against FOSS, and none of them had had any lasting effect.
Since the US Patent Office is what it is, the patent in question could well be "a method of simulating multitasking by changing the program being run multiple times per second", "authenticating an user with a secret string token" or something similar.
No, it couldn't be, because we'd know about it: patents and patent applications are published in the US. Furthermore, any bad patent like that that affects Linux or Mono in any significant way would like affect lots of other commercial software, so Microsoft wouldn't have to contend with just challenges from the FOSS community.
I don't know whether you just have a voodoo view of patents and business, or whether you are deliberately spreading fear, uncertainty, and doubt, but you couldn't be doing a better job at it if you were employeed by Microsoft's PR department.
No, it's not a "better option". Combinations of scripting languages and C/C++ are intrinsically brittle--a single pointer error in the C/C++ code sends the whole thing crashing down. That sort of thing is OK for scientific prototyping but almost nothing else. It's worse than plain C++ because it's actually harder to debug.
There are a few real alternatives, for example, D and Eiffel. But they have almost no real-world usage, no tool support, and they are still technically far behind Java and C#.
I think the FOSS community puts too much emphasis on it, even above usability in some cases.
That's because many people in the FOSS community have been burned multiple times by commercial software: forced ugprades, bad upgrades, abandoned products, changes in product direction that benefit the vendor but not the user, etc.
FOSS is a way to reduce costs and risks. And, yes, reducing costs and risks is more important than usability in many cases.
Unfortunately, many people don't know about long-term costs and risks, so they continue to choose proprietary platforms that expose them unnecessarily.
So it's your expert opinion that the GPL doesn't specifically take into consideration just these kinds of patent concerns?
The GPL addresses patent concerns just fine--but only for users of the GPL'ed software released by Sun and only for Sun's patents.
It doesn't address patent concerns for other implementations of Java (and there are several of them), or of people who use Sun's software under a dual license. It also doesn't address the issue of patent claims Microsoft or anybody else might have against Sun Java or other implementations of Java.
So we can contact you to fund the defense of the first FOSS developer / distributor to be sued by Microsoft right? You evidently have no idea what it costs to defend against patents do you? The fact that Microsoft holds a patent doesn't mean they'll use it but it also doesn't mean they won't. Given Microsoft's hatred of FOSS, it is my guess they would if you don't do as Novell did.
Microsoft holds lots of patents, and they can sue you no matter what language or platform you use. They can sue you if you use Java on Windows, or Python on Linux, or AppleScript on Macintosh, all platforms they probably "hate".
The worst that is likely to happen to a FOSS developer or distributor in such a lawsuit is that they say "my bad" they and everybody else changes their code to be non-infringing. A few big companies may be slightly more exposed, but they don't need to go on Slashdot to get legal advice.
And, like thousands of other developers, I am using Mono, I'm open about it, and Microsoft is free to sue me if they like and if they're stupid enough. The number of such lawsuits Microsoft can even launch is strictly less than 2, and the number of lawsuits they get a penny out of is likely strictly less than 1.
I don't know about that. Steve Ballmer just a few days ago all but promised to sue people who use linux unless they are using SUSE.
Good, I hope he follows through. The sooner the better, actually. So far, he hasn't even said what patents Linux is supposed to be violating. And as soon as he does, either his bluff will get called, or the offending code will be instantly replaced, leaving Microsoft with nobody to sue.
MS has patents on.NET. They just recently promised to sue people who violate those patents. I would stay away from mono, MS could sue you just for using it.
MS has patents on lots of things and they can sue you no matter what platform you use. The same is true for Sun.
Microsoft has made it abundantly clear that when you implement the the ECMA stuff, and your own CLR, you are entering into a RAND agreement with Microsoft, and they have patents essential to the running of it:
It doesn't matter what Microsoft "makes clear", they are simply spreading FUD, and so are you. You don't enter into agreements by implementing a public standard. You may be infringing on their patents, but given the vast amount of prior art, it seems unlikely that Mono is infringing on any claim that would hold up. And Microsoft's statement of terms may not be satisfying, but a court would take it into account if there ever were a lawsuit.
And what's the alternative? Sun has many patents on Java, has actively defended their intellectual property against FOSS projects, and open source implementations need to implement the entire Java platform in order to be useful.
Mono, in contrast, is a separate implementation, under an open source license, based largely on its own APIs and libraries. Also, Microsoft's patents have been scrutinized in detail.
The situation may not be very satisfying, but for anybody wanting something faster than Python and higher level than C++, the choices come down to Java and C#. Technically, I think C# is superior, and at least for now, the legal situation surrounding it is also better than Java.
Oops, I meant "nor does it 'just work' in any form". What I'm saying is: Java runs cross-platform, but the user experience is bad and a lot of things don't work quite right.
Of course, Linux has MonoDevelop, which is great for developing Linux apps and can be used for developing Windows apps.
However, I think there is some merit to the question. Sharpdevelop on Linux could be a good choice when people need to develop applications targetted at Windows, but when they prefer developing on Linux. The advantage of Sharpdevelop for that purpose would be that its primary platform is Windows, so you're less likely to incorporate Linux-specific features in your apps. (In a sense, Mono is the embrace-and-extend strategy of the Linux community.)
So, does anybody know whether Sharpdevelop runs on Mono 1.2?
I get a 22M RSS (280M total) for a Java application showing a single JButton in a JFrame; I get 7M RSS (22M total) for the same Gtk# application.
and has very mature gui compoenents in swing and awt that just work across platforms.
When I run a Swing application with Gtk LAF on my Linux box using Sun Java 5, it fails to pick up the Gtk theme I'm using, the menu buttons disappear when I click on them (because foreground/background seem to fail to pick up the right colors) and the menu shortcuts use the wrong font and wrong text. And that's just for starters. There is nothing "mature" about Java 5 on Linux, nor does it work in any form.
Java has its place in the world, and so does Mono, and they largely don't overlap.
They're going to streamline and clean up SUSE and other products, to make them much more useable by people working in mixed platform environments.
Microsoft hasn't even been able to do that with their own products; what makes you think they'll be able to do it with Linux?
it's easy to change your screen resolution... just open a terminal, type 'blah, blah'
Well, I hope that the people at Microsoft are as ill-informed as you are and that that's why they spent the $348m. (Hint: it's System > Preferences > Screen Resolutions)
If Novell actually had paid money to Microsoft as part of this transaction, then that argument would have some merit. But they didn't. On the whole, Microsoft has paid money to Novell, and that's not a very convincing argument to any court that Microsoft actually has patents that Novell cares about.
Furthermore, patents are public and Microsoft's patents are closely scrutinized, so there is no mystery as to what Microsoft can and cannot claim. They may be able to cobble together some obscure claim somehow, but they clearly don't have anything big that affects any of the FOSS packages we use.
The problem with all those arguments is that Novell/SuSE, RedHat, Debian, and Ubuntu are largely just distributors and packagers of other people's software. They can't cut deals on behalf of the authors, and the original authors of that software are vigilant about software patents, as is the user community.
Furthermore, we have had several software patent claims against FOSS and they have had no teeth: by the nature of FOSS projects, wilfull infringement hardly ever occurs, and damages are hard to claim. In the end, software patents are quickly and easily disposed of by FOSS by working around them.
I think we should consider this spending mostly part of a big FUD and PR campaign on the part of Microsoft. In the end, however, it's meaningless.
As I have written previously, the whole thing is primarily a publicity stunt on the part of Microsoft. By being able to point at deals like this, they can attempt to claim that there is something to their claims that they have intellectual property that Linux may infringe on. In addition, the reason the whole thing started is, I believe, a bunch of patents Novell asserted against Microsoft, not the other way around.
But in the end, the deal is legally meaningless because Novell cannot protect just its own customers from lawsuits over (L)GPL software; yes, Novell can agree to cover their customers' legal costs, but should Microsoft ever assert any patents against anybody on a piece of (L)GPL'ed software, Novell's customers have to stop using the software in question (well, technically, they'd just not get any updates, but that amounts to the same thing) just like everybody else, since the (L)GPL does not permit redistribution of software that's patent encumbered.
Potentially, this deal could be used by Microsoft to establish that their patents are "valuable", but I think courts aren't that stupid either. Furthermore, we have had several "worst-case scenarios" involving patents, open source software, and litigious companies, and their long term effect has been nil: open source seems to be able to work around intellectual property issues quite effectively.
In the end, Microsoft has given several hundred million dollars to an open source company for a legally meaningless move and the ability to spread a bunch of FUD. It probably would have looked better for Novell to turn them down, but I don't see it as a really big problem that they didn't, and it's a big chunk of change that will probably fund more open source development.
So, should you still use SuSE? I don't particularly like the company; I think they have always been excessively fond of software whose licenses I consider questionable (including Java and Qt). But I don't see them as a big threat either, and they are contributing to the community. In the end, the whole thing is a tempest in a teapot, except that an open source company is several hundred million dollars richer, which can't be all that bad.
Nevertheless, the lack of such an exception does not prevent the distribution of either kernel with non-GPLd applications on the same medium, never mind running them.
What's your point? If you're trying to reason by analogy from the kernel, that doesn't work. The kernel is more analogous to the virtual machine itself, and the combination of non-GPL apps and GPL virtual machines is not a problem. But the Java libraries are analogous to the C library that sits on top of the kernel and is necessary to call it, and the C library does have the linking exception because it needs it.
A distribution medium is not a derivative work of a GPLd work on it. [...] Works that are not derivative, can't become derivative by being placed on the same medium.
Sure they can. The GPL has its own definition of "derivative", and that includes many forms of aggregation on a distribution medium. (Sun has an even more encompassing notion of "derivative".)
The GPL works very well, it just doesn't always work exactly in the way described in the folk-tales of linkage, contamination and viral infects.
I agree that people are often excessively worried about the viral nature of the GPL. Nevertheless, if you distribute a GPL'ed library and proprietary program that link together, you are violating the GPL according to the stated intent of RMS and the GNU project. I'm not aware of any successful challenges to that interpretation.
Because they haven't done anything yet to clarify, have they?
That's why I was saying "why wouldn't they clarify this". If they pick the GPL without a linking exception, the assumption will be that their goal is to give the appearance of being open while delivering a license that, in this case, does not further the goals of free software. Sun's reputation in the open source community is already quite bad, and they can't afford another misstep.
I think any distinction made in "linking" to GPL'd Java class libraries versus calling a GPL'd program or OS API is so fine of a distinction as to be in the realm of anal.
Well, a lot of legal distinctions are. But this distinction is being made widely and it clearly reflects the intent of the original author.
Furthermore, you are looking at it the wrong way. It is not the case that the operating system situation is the default and that there are special rules prohibiting linking. Rather, it's the case that all cases in which program A somehow invokes program B are, by default, considered more than "mere aggregation" and hence t, but that, by convention, we have carved out a couple of exceptions.
For Sun to pick the plain GPL without exception would be a major blunder. Maybe people like you don't care, but there are enough people like me that it would be a major issue for them. And, instead of making Sun Java the predominant open source implementation, it would likely encourage the creation of alternative implementations and further damage Sun's reputation. And there's a good chance that Linux distributions would reject the new version and simply continue to treat Java like the proprietary software they are treating it as now.
a) The GPL allows you to run GPLd code freely, so applications running on top of GPLd code can not be 'contaminated'[1] through the act of running.
Correct. They are contaminated through the act of being distributed together with the GPL'ed Java runtime, something that Linux distributors will want to do. They are "contaminated" in the sense that if you have received them through that distribution channel, you have received them under the GPL and are therefore bound by the terms of the GPL if you do anything else with them. And if their original license is not compatible with the GPL, then you can't do anything with them at all.
The GPLd Linux kernel, for example, rather unsurprisingly does not 'contaminate' the non-GPLd Sun JVM running on top of it.
Let's take that analogy. Then, the Linux kernel is kind of like the JVM. There is no problem with running non-GPL'ed applications on top of a GPL'ed JVM. But on top of that kernel are supporting libraries, and the supporting libraries for the kernel have an explicit linking exception because they need one. Likewise, the supporting libraries on top of the JVM, which means all the Java libraries, need a linking exception. In addition, kernel extensions for a GPL'ed kernel need to fall under the GPL, so, by analogy, a GPL'ed JVM would cause problems with non-GPL'ed native libraries.
b) The GPL does not talk about linking at all, actually. It talks about derivative works.
That's correct. And RedHat Linux, Debian, SuSE, and Ubuntu are derivative works of the works they include. Furthermore, if Java applications on those CDs run on Java implementations on those CDs, then they don't clearly meet the "mere aggregation" test of the GPL.
c) Neither the source code, nor the resulting bytecode of an application written against the standard Java APIs is a derivative work of a particular implementation.
No, but the distribution containing both the Java implementation and the Java application together is a derivative work, and it's a derivative work that does not clearly meet the "mere aggregation" test.
d) GPL allows you to redistribute GPLd works with other works that aren't derived from GPLd works, without imposing obligations on them.
It does that provided they are "merely aggregated". If you ship a Java application intended to run on a Java implementation, then they aren't "merely aggregated", they are intended to run together.
The intent of the GPL vis-a-vis linking is explained here:
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.
RMS has also been quite consistent and vocal about the fact that this is his view and intent for the GPL. So, if a Linux distributor decides to include a GPL'ed Java implementation without linking exception, then the GPL implies that any code that runs on that Java implementation must itself be distributed under the GPL. For a lot of Java code, that's not possible because it already falls under GPL incompatible license, so there is a lot of Java code the distributor can't ship. I don't see how any Linux distribution, no matter how committed to the GPL, can live with that. The fact that there are some other ways in which a GPL'ed Java implementation and a non-GPL'ed Java program can find their ways onto your harddisk and you can combine them there yourself without violating the GPL doesn't change the fact that for many uses, this would be a serious problem.
Now, you can wave your hands and try to construct legal arguments why the GPL can't or doesn't actually achieve what RMS wants it to achieve (there are lots of people like you who have tried), but the fact is that a lot of people sh
Slashdot Mirror
These guys are making millions of dollars each year, while most of you DO NOT. There must be something they're doing right
Yes: they have an OS monopoly, great marketing, and vicious business practices. Whether their engineering or design practices are any good doesn't matter (they have improved, though).
Financial success is not an indicator of good products or good business practices.
so if you want OSS to succeed, steal some of it instead of dismissing it like 5 year olds
FOSS is doing just that: Linux desktops are so Windows-like that it makes many UNIX users want to puke. Even many known, bad design decisions are carried over from Windows just to make Windows users happy. But leave us the right to at least complain about it. Oh, and, yes, Linux distributions have those sounds.
The problem is logistics and resources.
No, the problem is neither logistics, nor availability of developers, not resources, it's priorities: making bug-free products simply doesn't matter much to Microsoft's bottom line, so they don't bother. What matters to them is fast time-to-market, long feature lists, and backwards compatibility, and all of those are in serious conflict with removing bugs.
(Linux developers have a slightly different set of constraints, but end up making many of the same bad choices as Microsoft developers.)
The little bits of polish really do matter to most people; they may not notice it when it's there, but they sure as hell notice when it's missing.
Yes, and Linux distributions have all those features. Ubuntu, RedHat, and SuSE can jingle on startup and shutdown with the best of them.
On a project of this size, aesthetics and engineering considerations are not mutually exclusive, you can have both.
You can also end up with neither, despite putting in a lot of money.
Or, as works with EVERY public forum. "Things you post in a public space are public knowledge and use.
There are actually quite a few companies that post source code and other information on the web with licenses that impose obligations on you if you as much as look at it.
For example, go to the Sun web site and look at the licenses under which they make Java documentation and source code available; read them carefully and then roll your eyes.
Different colleges have different goals and approaches; you need to pick your college to go with your goals. Many CS majors do not go on to become software developers, so it is perfectly legitimate for a college not to include project development experience in their courses. Even if you picked such a college, nothing prevents you from participating in one of the many open source projects or to start your own.
Patents aren't the same as copyright.
You're stating the obvious.
If you're infringing on a patent, you can't just replace the code with a rewrite; you have to remove the very idea from your code.
Wrong. You merely have to find something that the patent doesn't "read on"; often, that's just a small variation on the patented method.
Furthermore, we have a couple of decades of experience with this. There have been numerous patent claims against FOSS, and none of them had had any lasting effect.
Since the US Patent Office is what it is, the patent in question could well be "a method of simulating multitasking by changing the program being run multiple times per second", "authenticating an user with a secret string token" or something similar.
No, it couldn't be, because we'd know about it: patents and patent applications are published in the US. Furthermore, any bad patent like that that affects Linux or Mono in any significant way would like affect lots of other commercial software, so Microsoft wouldn't have to contend with just challenges from the FOSS community.
I don't know whether you just have a voodoo view of patents and business, or whether you are deliberately spreading fear, uncertainty, and doubt, but you couldn't be doing a better job at it if you were employeed by Microsoft's PR department.
No, it's not a "better option". Combinations of scripting languages and C/C++ are intrinsically brittle--a single pointer error in the C/C++ code sends the whole thing crashing down. That sort of thing is OK for scientific prototyping but almost nothing else. It's worse than plain C++ because it's actually harder to debug.
There are a few real alternatives, for example, D and Eiffel. But they have almost no real-world usage, no tool support, and they are still technically far behind Java and C#.
I think the FOSS community puts too much emphasis on it, even above usability in some cases.
That's because many people in the FOSS community have been burned multiple times by commercial software: forced ugprades, bad upgrades, abandoned products, changes in product direction that benefit the vendor but not the user, etc.
FOSS is a way to reduce costs and risks. And, yes, reducing costs and risks is more important than usability in many cases.
Unfortunately, many people don't know about long-term costs and risks, so they continue to choose proprietary platforms that expose them unnecessarily.
So it's your expert opinion that the GPL doesn't specifically take into consideration just these kinds of patent concerns?
The GPL addresses patent concerns just fine--but only for users of the GPL'ed software released by Sun and only for Sun's patents.
It doesn't address patent concerns for other implementations of Java (and there are several of them), or of people who use Sun's software under a dual license. It also doesn't address the issue of patent claims Microsoft or anybody else might have against Sun Java or other implementations of Java.
So we can contact you to fund the defense of the first FOSS developer / distributor to be sued by Microsoft right? You evidently have no idea what it costs to defend against patents do you? The fact that Microsoft holds a patent doesn't mean they'll use it but it also doesn't mean they won't. Given Microsoft's hatred of FOSS, it is my guess they would if you don't do as Novell did.
Microsoft holds lots of patents, and they can sue you no matter what language or platform you use. They can sue you if you use Java on Windows, or Python on Linux, or AppleScript on Macintosh, all platforms they probably "hate".
The worst that is likely to happen to a FOSS developer or distributor in such a lawsuit is that they say "my bad" they and everybody else changes their code to be non-infringing. A few big companies may be slightly more exposed, but they don't need to go on Slashdot to get legal advice.
And, like thousands of other developers, I am using Mono, I'm open about it, and Microsoft is free to sue me if they like and if they're stupid enough. The number of such lawsuits Microsoft can even launch is strictly less than 2, and the number of lawsuits they get a penny out of is likely strictly less than 1.
I don't know about that. Steve Ballmer just a few days ago all but promised to sue people who use linux unless they are using SUSE.
.NET. They just recently promised to sue people who violate those patents. I would stay away from mono, MS could sue you just for using it.
Good, I hope he follows through. The sooner the better, actually. So far, he hasn't even said what patents Linux is supposed to be violating. And as soon as he does, either his bluff will get called, or the offending code will be instantly replaced, leaving Microsoft with nobody to sue.
MS has patents on
MS has patents on lots of things and they can sue you no matter what platform you use. The same is true for Sun.
I clearly qualified my statement about Java with "for now" because of yahoos like you.
Furthermore, even if Sun releases Java under the GPL, that doesn't address patent concerns regarding Java.
Microsoft has made it abundantly clear that when you implement the the ECMA stuff, and your own CLR, you are entering into a RAND agreement with Microsoft, and they have patents essential to the running of it:
It doesn't matter what Microsoft "makes clear", they are simply spreading FUD, and so are you. You don't enter into agreements by implementing a public standard. You may be infringing on their patents, but given the vast amount of prior art, it seems unlikely that Mono is infringing on any claim that would hold up. And Microsoft's statement of terms may not be satisfying, but a court would take it into account if there ever were a lawsuit.
And what's the alternative? Sun has many patents on Java, has actively defended their intellectual property against FOSS projects, and open source implementations need to implement the entire Java platform in order to be useful.
Mono, in contrast, is a separate implementation, under an open source license, based largely on its own APIs and libraries. Also, Microsoft's patents have been scrutinized in detail.
The situation may not be very satisfying, but for anybody wanting something faster than Python and higher level than C++, the choices come down to Java and C#. Technically, I think C# is superior, and at least for now, the legal situation surrounding it is also better than Java.
Oops, I meant "nor does it 'just work' in any form". What I'm saying is: Java runs cross-platform, but the user experience is bad and a lot of things don't work quite right.
Of course, Linux has MonoDevelop, which is great for developing Linux apps and can be used for developing Windows apps.
However, I think there is some merit to the question. Sharpdevelop on Linux could be a good choice when people need to develop applications targetted at Windows, but when they prefer developing on Linux. The advantage of Sharpdevelop for that purpose would be that its primary platform is Windows, so you're less likely to incorporate Linux-specific features in your apps. (In a sense, Mono is the embrace-and-extend strategy of the Linux community.)
So, does anybody know whether Sharpdevelop runs on Mono 1.2?
It uses less memory than Mono
I get a 22M RSS (280M total) for a Java application showing a single JButton in a JFrame; I get 7M RSS (22M total) for the same Gtk# application.
and has very mature gui compoenents in swing and awt that just work across platforms.
When I run a Swing application with Gtk LAF on my Linux box using Sun Java 5, it fails to pick up the Gtk theme I'm using, the menu buttons disappear when I click on them (because foreground/background seem to fail to pick up the right colors) and the menu shortcuts use the wrong font and wrong text. And that's just for starters. There is nothing "mature" about Java 5 on Linux, nor does it work in any form.
Java has its place in the world, and so does Mono, and they largely don't overlap.
Chances are, you do. It ships with several Linux distros, and some Gnome apps are written in it.
They're going to streamline and clean up SUSE and other products, to make them much more useable by people working in mixed platform environments.
Microsoft hasn't even been able to do that with their own products; what makes you think they'll be able to do it with Linux?
it's easy to change your screen resolution... just open a terminal, type 'blah, blah'
Well, I hope that the people at Microsoft are as ill-informed as you are and that that's why they spent the $348m. (Hint: it's System > Preferences > Screen Resolutions)
If Novell actually had paid money to Microsoft as part of this transaction, then that argument would have some merit. But they didn't. On the whole, Microsoft has paid money to Novell, and that's not a very convincing argument to any court that Microsoft actually has patents that Novell cares about.
Furthermore, patents are public and Microsoft's patents are closely scrutinized, so there is no mystery as to what Microsoft can and cannot claim. They may be able to cobble together some obscure claim somehow, but they clearly don't have anything big that affects any of the FOSS packages we use.
The problem with all those arguments is that Novell/SuSE, RedHat, Debian, and Ubuntu are largely just distributors and packagers of other people's software. They can't cut deals on behalf of the authors, and the original authors of that software are vigilant about software patents, as is the user community.
Furthermore, we have had several software patent claims against FOSS and they have had no teeth: by the nature of FOSS projects, wilfull infringement hardly ever occurs, and damages are hard to claim. In the end, software patents are quickly and easily disposed of by FOSS by working around them.
I think we should consider this spending mostly part of a big FUD and PR campaign on the part of Microsoft. In the end, however, it's meaningless.
suggests Klingon disruptors
As I have written previously, the whole thing is primarily a publicity stunt on the part of Microsoft. By being able to point at deals like this, they can attempt to claim that there is something to their claims that they have intellectual property that Linux may infringe on. In addition, the reason the whole thing started is, I believe, a bunch of patents Novell asserted against Microsoft, not the other way around.
But in the end, the deal is legally meaningless because Novell cannot protect just its own customers from lawsuits over (L)GPL software; yes, Novell can agree to cover their customers' legal costs, but should Microsoft ever assert any patents against anybody on a piece of (L)GPL'ed software, Novell's customers have to stop using the software in question (well, technically, they'd just not get any updates, but that amounts to the same thing) just like everybody else, since the (L)GPL does not permit redistribution of software that's patent encumbered.
Potentially, this deal could be used by Microsoft to establish that their patents are "valuable", but I think courts aren't that stupid either. Furthermore, we have had several "worst-case scenarios" involving patents, open source software, and litigious companies, and their long term effect has been nil: open source seems to be able to work around intellectual property issues quite effectively.
In the end, Microsoft has given several hundred million dollars to an open source company for a legally meaningless move and the ability to spread a bunch of FUD. It probably would have looked better for Novell to turn them down, but I don't see it as a really big problem that they didn't, and it's a big chunk of change that will probably fund more open source development.
So, should you still use SuSE? I don't particularly like the company; I think they have always been excessively fond of software whose licenses I consider questionable (including Java and Qt). But I don't see them as a big threat either, and they are contributing to the community. In the end, the whole thing is a tempest in a teapot, except that an open source company is several hundred million dollars richer, which can't be all that bad.
Nevertheless, the lack of such an exception does not prevent the distribution of either kernel with non-GPLd applications on the same medium, never mind running them.
What's your point? If you're trying to reason by analogy from the kernel, that doesn't work. The kernel is more analogous to the virtual machine itself, and the combination of non-GPL apps and GPL virtual machines is not a problem. But the Java libraries are analogous to the C library that sits on top of the kernel and is necessary to call it, and the C library does have the linking exception because it needs it.
A distribution medium is not a derivative work of a GPLd work on it. [...] Works that are not derivative, can't become derivative by being placed on the same medium.
Sure they can. The GPL has its own definition of "derivative", and that includes many forms of aggregation on a distribution medium. (Sun has an even more encompassing notion of "derivative".)
The GPL works very well, it just doesn't always work exactly in the way described in the folk-tales of linkage, contamination and viral infects.
I agree that people are often excessively worried about the viral nature of the GPL. Nevertheless, if you distribute a GPL'ed library and proprietary program that link together, you are violating the GPL according to the stated intent of RMS and the GNU project. I'm not aware of any successful challenges to that interpretation.
Because they haven't done anything yet to clarify, have they?
That's why I was saying "why wouldn't they clarify this". If they pick the GPL without a linking exception, the assumption will be that their goal is to give the appearance of being open while delivering a license that, in this case, does not further the goals of free software. Sun's reputation in the open source community is already quite bad, and they can't afford another misstep.
I think any distinction made in "linking" to GPL'd Java class libraries versus calling a GPL'd program or OS API is so fine of a distinction as to be in the realm of anal.
Well, a lot of legal distinctions are. But this distinction is being made widely and it clearly reflects the intent of the original author.
Furthermore, you are looking at it the wrong way. It is not the case that the operating system situation is the default and that there are special rules prohibiting linking. Rather, it's the case that all cases in which program A somehow invokes program B are, by default, considered more than "mere aggregation" and hence t, but that, by convention, we have carved out a couple of exceptions.
For Sun to pick the plain GPL without exception would be a major blunder. Maybe people like you don't care, but there are enough people like me that it would be a major issue for them. And, instead of making Sun Java the predominant open source implementation, it would likely encourage the creation of alternative implementations and further damage Sun's reputation. And there's a good chance that Linux distributions would reject the new version and simply continue to treat Java like the proprietary software they are treating it as now.
a) The GPL allows you to run GPLd code freely, so applications running on top of GPLd code can not be 'contaminated'[1] through the act of running.
Correct. They are contaminated through the act of being distributed together with the GPL'ed Java runtime, something that Linux distributors will want to do. They are "contaminated" in the sense that if you have received them through that distribution channel, you have received them under the GPL and are therefore bound by the terms of the GPL if you do anything else with them. And if their original license is not compatible with the GPL, then you can't do anything with them at all.
The GPLd Linux kernel, for example, rather unsurprisingly does not 'contaminate' the non-GPLd Sun JVM running on top of it.
Let's take that analogy. Then, the Linux kernel is kind of like the JVM. There is no problem with running non-GPL'ed applications on top of a GPL'ed JVM. But on top of that kernel are supporting libraries, and the supporting libraries for the kernel have an explicit linking exception because they need one. Likewise, the supporting libraries on top of the JVM, which means all the Java libraries, need a linking exception. In addition, kernel extensions for a GPL'ed kernel need to fall under the GPL, so, by analogy, a GPL'ed JVM would cause problems with non-GPL'ed native libraries.
b) The GPL does not talk about linking at all, actually. It talks about derivative works.
That's correct. And RedHat Linux, Debian, SuSE, and Ubuntu are derivative works of the works they include. Furthermore, if Java applications on those CDs run on Java implementations on those CDs, then they don't clearly meet the "mere aggregation" test of the GPL.
c) Neither the source code, nor the resulting bytecode of an application written against the standard Java APIs is a derivative work of a particular implementation.
No, but the distribution containing both the Java implementation and the Java application together is a derivative work, and it's a derivative work that does not clearly meet the "mere aggregation" test.
d) GPL allows you to redistribute GPLd works with other works that aren't derived from GPLd works, without imposing obligations on them.
It does that provided they are "merely aggregated". If you ship a Java application intended to run on a Java implementation, then they aren't "merely aggregated", they are intended to run together.
The intent of the GPL vis-a-vis linking is explained here:
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.
RMS has also been quite consistent and vocal about the fact that this is his view and intent for the GPL. So, if a Linux distributor decides to include a GPL'ed Java implementation without linking exception, then the GPL implies that any code that runs on that Java implementation must itself be distributed under the GPL. For a lot of Java code, that's not possible because it already falls under GPL incompatible license, so there is a lot of Java code the distributor can't ship. I don't see how any Linux distribution, no matter how committed to the GPL, can live with that. The fact that there are some other ways in which a GPL'ed Java implementation and a non-GPL'ed Java program can find their ways onto your harddisk and you can combine them there yourself without violating the GPL doesn't change the fact that for many uses, this would be a serious problem.
Now, you can wave your hands and try to construct legal arguments why the GPL can't or doesn't actually achieve what RMS wants it to achieve (there are lots of people like you who have tried), but the fact is that a lot of people sh