I don't believe this is necessarily the case (insert IANAL disclaimer of your choice). In fact it's perfectly possible to say that the GPL doesn't apply for the Linux kernel, but does for NMap - because SCO's position is that whoever applied the GPL to the Linux kernel didn't have the right to do so, because they didn't hold the necessary IP rights.
It's (almost) certainly the case that you can accept the GPL for some programs and not for other, particularly if you have multiple different licenses available for a particular piece of software.
In specific cases, can you accept a license that you believe to be unenforcable legally? I don't see why not.
Judge: "So you don't agree with the license?" SCO: "We do not believe that the license is constitutional, or that aspects of it have any legal standing, but in the case of this piece of software we are willing to accept it provisional to any legal ruling on the matter and conform to the constraints imposed by the license, while not surrendering our rights to deny the validity of the license as applied to other pieces of software, particularly those where the legal rights of the licensor to the code is in question." Judge: "Right. We could be here some time..."
A fair and +3 Interesting point, though I wouldn't like to argue the legal aspects of it (I wouldn't like to argue the legal aspects of anything, though - I'm not a lawyer and I'd get crushed like a bug by people who are). My entirely uneducated thoughts on the issue are that the license would pertain to a particular piece of software. Where the boundaries end would be a difficult matter, but it would probably be the point at which functionality is available - you couldn't selectively break the license for a single fragment of code or source file, but breaking the license for one program wouldn't break the license for another program that can be run entirely separately from the first (as is the case with the Linux kernel and nmap).
The one exception to that (and the one which may make a lot of my other points completely invalid) would possibly be clause 5, which specifies that you have to accept the GPL and agree to its terms to get your rights to use/distribute the software. If SCO's position that the GPL is unconstitutional means that they are seen as making a blanket refusal to accept the license for any software where that license is the GPL, then whether it means they're barred from using all GPLed software as a single unit or all GPLed software on an individual basis is a pretty moot point. That said I don't know whether believing a license is invalid prevents you from agreeing to accept it in some cases where you intended to conform to its requirements anyway. Again, determining whether that's true is a job for the lawyers.
I'm pretty much positive that accepting the GPL for one piece of software doesn't mean you've accepted it for all GPLed software, though. And bear in mind that SCO's case works on the assumption (well-founded or delusional) that code in Linux was GPLed by people who did not have the right to do so.
That's the thing, though. I don't believe NMap's authors can just retract SCO's license to redistribute NMap, and I don't believe they can change the license on new versions to prevent SCO from using it without making their license (probably) non-free and (certainly) GPL-incompatible. The only scope for termination of the license is clause 4, and that's something that SCO have to initiate themselves, by breaking one of the other terms of the license (which you might argue they already have done, probably through clause 5).
As soon as they are found to have violated the license, then as you point out, they're (theoretically) in trouble, because they don't have the right to use and distribute the code, which they're quite obviously doing - assuming that since they don't like the license they have the right to do whatever they want (which is explicitly denied by clause 5 anyway).
Have they forced users to buy licenses for nmap in addition to the GPL? My understanding was that the licenses were only to cover the kernel itself, which is where the disputed code lies. SCO may have violated the GPL in general, but not in this specific case. Looking at it dispassionately, I can't see that they've actually broken any aspect of the license with respect to nmap.
Whether they believe in the enforcability and constitutionality (is that a word?) of the GPL is kind of irrelevant - as long as they comply with the terms of the license in a given case.
Here is a company who in public says GPL is not legal. And these people are trying to use GPL against them.
Um. No they aren't. If SCO believes that the GPL is not legal, then they do not have a license to use and distribute nmap. Now they're being called on it. The default state of software where the copyright is held by someone else is that you do not have the right to use it, and just disagreeing with the license they're distributing the software under doesn't magically give you the right to steal their IP.
More interesting, however, is the question of whether nmap have the right to retract the license from SCO (IANAL, but I'm pretty sure they don't - that's part of the point of the GPL, after all). And a new license that explicitly denies SCO the right to use the code wouldn't be GPL-compatible, AIUI.
That said, in order to exercise their rights under the GPL, SCO have to agree to it. They can't claim it's an invalid license while at the same time agreeing to it in other cases. My guess is that they'll just ignore this problem and try to keep their two faces pointing different ways on the issue...
i think this is a fine joke. a java program has portability trouble across different JRE on the same processor and OS.
Can have portability trouble. If this is a problem for you, you can use the old JRE, and things will work well - the equivalent of using a special compatibility layer within NetBSD, IMO. You're comparing apples to oranges here: if nothing changes in the supporting layer, there is no chance of breakage (or more breakage than you had in the first place). If something changes, the chance goes up. Well duh - no surprise there.
Against that, Java (in my experience) does a better job of running across hardware platforms and JRE versions than C does. As part of my current job I've had to run the same code on Windows 2000, Windows XP, Linux and Solaris boxen, using JREs from 1.3.1 to 1.5 (well, I didn't have to try 1.5, but I wanted to know...) and it worked fine everywhere. I can guarantee this won't happen with your C binaries.
As long as you don't expect miracles, Java pretty much lives up to the promises of 'Write Once, Test Everywhere'. And more often than not, for the vast majority of code I've worked with, it really has managed to be 'Write Once, Run Anywhere' - or at least anywhere I've needed to. YMMV, especially depending on what sort of app you're writing.
Java is said to be impossible to be used to write non-portable programs.
Possibly, but only by people who are wrong. Sun certainly never claimed that, nor did anyone who knows what they're talking about when it comes to Java. The rantings of the clueless should never be held against a language, or we'd never get any code written.
C is a standard. We had the ANSI C that was followed by ISO C and more recently the C99 which GCC supports. So if you write code relatively cleanly it will get compiled (sometimes with a few fixes) on weirdo platforms.
Provided you don't want to do anything complex, like have a GUI, I believe.
The license that accompanies the JRE you can download from Sun gives you the right to use it to test your own applications. It does not give you the right to run other people's applications arbitrarily.
Not by my reading of it, though IANAL. "Sun grants you a non-exclusive, non-transferrable, limited license without license fees to reproduce and use internally Software complete and unmodified for the sole purpose of running Programs." The supplemental license terms extend that allowing developers to redistribute the JRE with their own code under additional constraints and has a reference to use of the code for development and testing, but AFAICT it doesn't supercede your right to use the license for running programs as defined in the main body of the license.
When it comes to terminating the license, you actually have more rights than Sun do - you have the ability to terminate it just because you want to, which they do not reserve for themselves.
Perhaps your source is getting confused and reading the license agreement for beta software (such as the new 1.5 early access release) which I believe is only available for testing. Which is what betas are normally for anyway.
If Sun does not free their Java as C or C++ or various other languages are free to use and build upon, it will remain in its niche sadly.
In very much the same way, if Microsoft doesn't free up their Windows as Linux or NetBSD are free to use and build uppon, it will remain in its niche. I'm sure they don't cry themselves to sleep at nights over that, though.
Don't get me wrong - I'd love to see Java as an open standard in a real way, provided it didn't just open things up for Microsoft to do a demolition job on it. It would be my preferred way for the language to go, for a variety of reasons which others have probably explained in g
Um. That link shows Java as having 11132 projects - the highest number except for C++ (12686) and C (12706). Given Java's big uptake in commercial development and the fact that it hasn't been around and mature for as long as C/C++ (how far back do Sourceforge projects go) I'd say you've not really done much to disprove his claim. Java is certainly one of the most popular languages out there today, and might even be at the top of the heap.
Of course, I understand that Britney Spears is rather popular too...
Um. This happened in 2002 according to the article. I think we've missed the boat on this one... the actual new information is the sentence handed down to the culprit.
No problem at all running NVidia drivers under Mandrake 9.2 (other than the brokenness of some versions of the drivers, that is...) Haven't tried the new release (took me long enough to fix the damage the last set caused) but I'll be taking a look soonish.
No, that's alright. I'm in a band that used Fruityloops on a laptop to provide drums until we managed to find a human drummer, but it kept terrible time - it was always out of time with the rest of the band by the end of the song...
Surely this is covered by the DMCA? No matter how pathetic the security may be, attempting to violate it is a crime.
Either way, whether it's acceptable by the letter of the law, it strikes me as highly morally dubious - and it would be just as dubious if the Democrats were doing it, before the obvious straw man gets pulled out.
True to a point, but it could actually do a better job of discouraging long parking periods - just have a non-linear scale of fees. If the price starts to rise dramatically after three or four hours, then there's an incentive to move on before that time, rather than just dropping back briefly to stick more money in the meter.
Um. You may not have noticed, since occasionally a day passes without a Slashdot story about it, but SCO are already trying to put pressure on corporate Linux users.
To continue your analogy, the stampeding herd of angry elephants is within earshot, and have sent you a note to inform you that they intend to pass through your living room at 3:30pm.
Indeed: the existence of Eclipse for Linux has allowed me to migrate my work PC to Linux - there's now nothing that I needed to do under Windows that I can't do under Linux.
Actually, there is a justification for an apostrophe. Although it's falling out of fashion, an apostrophe to denote the plural of an acronym has been acceptable (even standard - witness the 1984 GPO style guide).
It's a common mistake (in my opinion) to rant and rave about how people who pluralise acronyms with an apostrophe are 'wrong' - it's still really a matter of personal preference and style.
Works well for spearmen in lines, but IIRC the orcs were mostly lined up in squares, which are great at dealing with cavalry charges. To be honest, the Rohirrim might have been better off ignoring the spearmen and finding a more suitable target for their strengths.
Forget the CGI actors. Ignore (if you can) the comedy dwarf tossing. My biggest complaint about the battle sequences is the hideous lack of strategy the leaders seem to have. I don't care who you are: a cavalry charge against a huge rank of spearmen is not a smart idea, and we see it happen at least twice in the series. And charging headlong at rampaging Oliphaunts? You deserve to be crushed underfoot. Swing out and take them from the flank, perhaps?
Slashdot Mirror
Don't forget Sodipodi, which is free.
I don't believe this is necessarily the case (insert IANAL disclaimer of your choice). In fact it's perfectly possible to say that the GPL doesn't apply for the Linux kernel, but does for NMap - because SCO's position is that whoever applied the GPL to the Linux kernel didn't have the right to do so, because they didn't hold the necessary IP rights.
It's (almost) certainly the case that you can accept the GPL for some programs and not for other, particularly if you have multiple different licenses available for a particular piece of software.
In specific cases, can you accept a license that you believe to be unenforcable legally? I don't see why not.
Judge: "So you don't agree with the license?"
SCO: "We do not believe that the license is constitutional, or that aspects of it have any legal standing, but in the case of this piece of software we are willing to accept it provisional to any legal ruling on the matter and conform to the constraints imposed by the license, while not surrendering our rights to deny the validity of the license as applied to other pieces of software, particularly those where the legal rights of the licensor to the code is in question."
Judge: "Right. We could be here some time..."
A fair and +3 Interesting point, though I wouldn't like to argue the legal aspects of it (I wouldn't like to argue the legal aspects of anything, though - I'm not a lawyer and I'd get crushed like a bug by people who are). My entirely uneducated thoughts on the issue are that the license would pertain to a particular piece of software. Where the boundaries end would be a difficult matter, but it would probably be the point at which functionality is available - you couldn't selectively break the license for a single fragment of code or source file, but breaking the license for one program wouldn't break the license for another program that can be run entirely separately from the first (as is the case with the Linux kernel and nmap).
The one exception to that (and the one which may make a lot of my other points completely invalid) would possibly be clause 5, which specifies that you have to accept the GPL and agree to its terms to get your rights to use/distribute the software. If SCO's position that the GPL is unconstitutional means that they are seen as making a blanket refusal to accept the license for any software where that license is the GPL, then whether it means they're barred from using all GPLed software as a single unit or all GPLed software on an individual basis is a pretty moot point. That said I don't know whether believing a license is invalid prevents you from agreeing to accept it in some cases where you intended to conform to its requirements anyway. Again, determining whether that's true is a job for the lawyers.
I'm pretty much positive that accepting the GPL for one piece of software doesn't mean you've accepted it for all GPLed software, though. And bear in mind that SCO's case works on the assumption (well-founded or delusional) that code in Linux was GPLed by people who did not have the right to do so.
That's the thing, though. I don't believe NMap's authors can just retract SCO's license to redistribute NMap, and I don't believe they can change the license on new versions to prevent SCO from using it without making their license (probably) non-free and (certainly) GPL-incompatible. The only scope for termination of the license is clause 4, and that's something that SCO have to initiate themselves, by breaking one of the other terms of the license (which you might argue they already have done, probably through clause 5).
As soon as they are found to have violated the license, then as you point out, they're (theoretically) in trouble, because they don't have the right to use and distribute the code, which they're quite obviously doing - assuming that since they don't like the license they have the right to do whatever they want (which is explicitly denied by clause 5 anyway).
Have they forced users to buy licenses for nmap in addition to the GPL? My understanding was that the licenses were only to cover the kernel itself, which is where the disputed code lies. SCO may have violated the GPL in general, but not in this specific case. Looking at it dispassionately, I can't see that they've actually broken any aspect of the license with respect to nmap.
Whether they believe in the enforcability and constitutionality (is that a word?) of the GPL is kind of irrelevant - as long as they comply with the terms of the license in a given case.
Um. No they aren't. If SCO believes that the GPL is not legal, then they do not have a license to use and distribute nmap. Now they're being called on it. The default state of software where the copyright is held by someone else is that you do not have the right to use it, and just disagreeing with the license they're distributing the software under doesn't magically give you the right to steal their IP.
More interesting, however, is the question of whether nmap have the right to retract the license from SCO (IANAL, but I'm pretty sure they don't - that's part of the point of the GPL, after all). And a new license that explicitly denies SCO the right to use the code wouldn't be GPL-compatible, AIUI.
That said, in order to exercise their rights under the GPL, SCO have to agree to it. They can't claim it's an invalid license while at the same time agreeing to it in other cases. My guess is that they'll just ignore this problem and try to keep their two faces pointing different ways on the issue...
Due to user error, the words "to NetBSD" were omitted from the end of the article.
Can have portability trouble. If this is a problem for you, you can use the old JRE, and things will work well - the equivalent of using a special compatibility layer within NetBSD, IMO. You're comparing apples to oranges here: if nothing changes in the supporting layer, there is no chance of breakage (or more breakage than you had in the first place). If something changes, the chance goes up. Well duh - no surprise there.
Against that, Java (in my experience) does a better job of running across hardware platforms and JRE versions than C does. As part of my current job I've had to run the same code on Windows 2000, Windows XP, Linux and Solaris boxen, using JREs from 1.3.1 to 1.5 (well, I didn't have to try 1.5, but I wanted to know...) and it worked fine everywhere. I can guarantee this won't happen with your C binaries.
As long as you don't expect miracles, Java pretty much lives up to the promises of 'Write Once, Test Everywhere'. And more often than not, for the vast majority of code I've worked with, it really has managed to be 'Write Once, Run Anywhere' - or at least anywhere I've needed to. YMMV, especially depending on what sort of app you're writing.
Possibly, but only by people who are wrong. Sun certainly never claimed that, nor did anyone who knows what they're talking about when it comes to Java. The rantings of the clueless should never be held against a language, or we'd never get any code written.
Provided you don't want to do anything complex, like have a GUI, I believe.
Not by my reading of it, though IANAL. "Sun grants you a non-exclusive, non-transferrable, limited license without license fees to reproduce and use internally Software complete and unmodified for the sole purpose of running Programs." The supplemental license terms extend that allowing developers to redistribute the JRE with their own code under additional constraints and has a reference to use of the code for development and testing, but AFAICT it doesn't supercede your right to use the license for running programs as defined in the main body of the license.
When it comes to terminating the license, you actually have more rights than Sun do - you have the ability to terminate it just because you want to, which they do not reserve for themselves.
Perhaps your source is getting confused and reading the license agreement for beta software (such as the new 1.5 early access release) which I believe is only available for testing. Which is what betas are normally for anyway.
In very much the same way, if Microsoft doesn't free up their Windows as Linux or NetBSD are free to use and build uppon, it will remain in its niche. I'm sure they don't cry themselves to sleep at nights over that, though.
Don't get me wrong - I'd love to see Java as an open standard in a real way, provided it didn't just open things up for Microsoft to do a demolition job on it. It would be my preferred way for the language to go, for a variety of reasons which others have probably explained in g
Um. That link shows Java as having 11132 projects - the highest number except for C++ (12686) and C (12706). Given Java's big uptake in commercial development and the fact that it hasn't been around and mature for as long as C/C++ (how far back do Sourceforge projects go) I'd say you've not really done much to disprove his claim. Java is certainly one of the most popular languages out there today, and might even be at the top of the heap.
Of course, I understand that Britney Spears is rather popular too...
Um. This happened in 2002 according to the article. I think we've missed the boat on this one... the actual new information is the sentence handed down to the culprit.
I thought everyone knew that Fords could be any colour you like, as long as they're black...
No problem at all running NVidia drivers under Mandrake 9.2 (other than the brokenness of some versions of the drivers, that is...) Haven't tried the new release (took me long enough to fix the damage the last set caused) but I'll be taking a look soonish.
Shame you can't spell it. Try simpler words, like 'straw' and 'man', and look back at the coverage of Blaster.
And quite how accusing someone of being sad for stooping to set up a DDoS counts as 'covering for them' is a mystery...
No, that's alright. I'm in a band that used Fruityloops on a laptop to provide drums until we managed to find a human drummer, but it kept terrible time - it was always out of time with the rest of the band by the end of the song...
Surely this is covered by the DMCA? No matter how pathetic the security may be, attempting to violate it is a crime.
Either way, whether it's acceptable by the letter of the law, it strikes me as highly morally dubious - and it would be just as dubious if the Democrats were doing it, before the obvious straw man gets pulled out.
True to a point, but it could actually do a better job of discouraging long parking periods - just have a non-linear scale of fees. If the price starts to rise dramatically after three or four hours, then there's an incentive to move on before that time, rather than just dropping back briefly to stick more money in the meter.
Um. You may not have noticed, since occasionally a day passes without a Slashdot story about it, but SCO are already trying to put pressure on corporate Linux users.
To continue your analogy, the stampeding herd of angry elephants is within earshot, and have sent you a note to inform you that they intend to pass through your living room at 3:30pm.
I'd be interested in seeing the Java code for those benchmarks: if it's that terrible, I'd suspect overuse of the String class as a culprit.
Indeed: the existence of Eclipse for Linux has allowed me to migrate my work PC to Linux - there's now nothing that I needed to do under Windows that I can't do under Linux.
That assumes that forall:A,B enemy(A,X) && enemy(B,X) => friend(A,B) - which can be shown to be untrue with a simple game of Quake.
Actually, there is a justification for an apostrophe. Although it's falling out of fashion, an apostrophe to denote the plural of an acronym has been acceptable (even standard - witness the 1984 GPO style guide).
It's a common mistake (in my opinion) to rant and rave about how people who pluralise acronyms with an apostrophe are 'wrong' - it's still really a matter of personal preference and style.
Wow. The IT industry really is in a slump. I can remember the days when Slashdot readers could afford more than one chestnut between them...
Works well for spearmen in lines, but IIRC the orcs were mostly lined up in squares, which are great at dealing with cavalry charges. To be honest, the Rohirrim might have been better off ignoring the spearmen and finding a more suitable target for their strengths.
Forget the CGI actors. Ignore (if you can) the comedy dwarf tossing. My biggest complaint about the battle sequences is the hideous lack of strategy the leaders seem to have. I don't care who you are: a cavalry charge against a huge rank of spearmen is not a smart idea, and we see it happen at least twice in the series. And charging headlong at rampaging Oliphaunts? You deserve to be crushed underfoot. Swing out and take them from the flank, perhaps?