"Show me a single court case in which the GPL was held NOT to be a license and I'll reconsider my position."
As the GPL is a copyright license it is enforced through copyright law and there wont be any case ever about a 'GPL violation'. Any such 'violation' is simply copyright infringement and any court case about it would be a civil or criminal copyright violation case, not a civil contract case.
Those are just a few starters from any number of articles you wish written by lawyers, legal experts, or laymen.
If you're interested in the concepts of open source licenses I'd also reccomend gmane OSS license mail list and debian-legal.
And, no, I'm not a lawyer. Altho I've been researching copyright law (US and various european versions) and the GPL and other OSS licenses for a decade by now out of interest. If you want a legal opinion I suggest you consult one of the many lawyers you'll find while researching these issues.
Mistaking the GPL for a contract is easy tho, and the reason for most misconceptions about it.
Shrink wrap licenses are in addition to. The GPL is not in addition to. The GPL contains no contractual provisions, and deals entirely in the terms required to obtain the permission of the owner to engage in distribution. The GPL is a bare license with conditions. You meet the conditions you get the right. You dont, you dont get the right.
This is what makes the GPL compatible with most legal systems, what makes it pointless to fight in court and what makes it so easily enforcable. Were it a contract it would require agreement by both parties to be enforced (and also an exchange of consideration in many jurisdiction), and a whole host of issues with agreement needing to be present between each and every holder of copyrights in the combined works would assue. However, as it's not a contract these difficulties do not arise.
So, the result obtained is not difficult to obtain, or in any other way odd. It is the only way a distributor can avoid copyright infringement, so it is the only possible result if they wish to continue distributing the software in question. (But of course, you're right that a code usually wont force them to continue using the code; however, this was an out-of-court settlement, and I guess Allnet wanted to continue using the code).
I reccomend you research the GPL carefully. This is an issue that has been hashed to death many many times.
You confuse the GPL with a contract. It's not. The GPL is not a binding contract, it does not require agreement between the parties, and a violation is not a breach of contract violation.
The GPL _is_, however, the only grant of permission you have to distribute the copyrighted 'intellectual property' distributed under the GPL. If you dont agree to, or follow, the terms of the GPL you're not in breach of contract, you're in violation of copyright law. Behaving in accordance with the terms of the GPL is the only way you will not be engaging in copyright violation.
So, it's not especially strange they get that result. It's the only way to obtain permission to distribute the copyrighted code.
"If the Xfree team exempted linking to libraries from their acknowledgement clause everyone would be happy."
Indeed, that's another possible solution. On the XFree86 side of things there's a whole bunch of solutions, ranging from like you said, tidying up the library licenses, to going through the license goal with someone from, for example, debian-legal who has some experience in GPL compatibility engineering, and coming up with a license scheme that does what they want but in a clean and compatible way. The intent of the change is not necessarily incompatible with the GPL.
As shipped with the various vendors, yes. If you look through them you'll find they're either not GPL, or they have a specific exception for the SSL library.
"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."
That's why you can run GPL programs on, and ship them for, proprietary OS's. That clause is also why the commercial UNIX vendors ship most free software separately from their base OS installs. It's why the Linux and BSD vendors can ship the GPL software with the base OS installs. And it's why the Linux and BSD vendors get a world of pain from system component license changes, conflicts and issues.
"Yet we don't see Linux distributers refusing to include products with those licenses."
It's no problem as long as you arent shipping any GPL applications linking with the incompatible code.
There are a whole bunch of GPL licensed applications that link to the X library code. The desktop environments, for starters.
So the choice is between not shipping the new version of X or not shipping any GPL licensed applications that use X. So you can have new X but no Gnome or KDE, or you can have the older revision of X and KDE and Gnome. Which would you prefer?
It's not that Redhat and the others have to insert acknowledgements, it's that they're not allowed to distribute GPL licensed components linked to code that requires them to insert acknowledgements.
Of course, there are ways around the problem. One I've seen would be to distribute the X libraries of a forked X linked with the GPL applications, and distribute the new X server as a completely standalone X server (which is how you can distribute commercial X servers with GPL applications). That would require double installs of a lot of things but it would probably be legal.
"Copyright law forbids removing copyright notices, but it does not require you to include additional ones.. this does."
And the stated purpose of the license change was to prevent others from claiming to have written it... so why doesnt Dawes just slap the notices where he wants them and trust copyright to do his job for him without charging straight into a random license change he cant have run by anyone?
"Second, this has nothing to do with trademark. If I write "DogOS" I can license it to you under the condition that you do not call your version "DogOS"."
But I can still do whatever I want as far as regards the name with the older licensed code. Which makes the entire clause completely contratictory as you can freely use the name as long as you're not using the code? They change the license to get more credit then they try to limit the use of the name in advertising?
Without a trademark I just cant see the point. It appears to follow no form of ordinary logic.
Apart from the fact that the license changes are completely redundant as copyright law already forbids removing copyright notices, and that the use of the name should be controlled through a trademark (as it's dubious wether you can control the name usage without one), the clauses may be incompatible with the GPL. That means you risk infringing on GPL software you may distribute like KDE, Qt, Gnome, etc, if you link with X libraries under the new license.
It's not a big deal for the average user, but it's a problem for the distributors. The last year has shown that nutcases can pop out of the woodwork and file lawsuits based on exceptionally odd reasoning. To ship software with the possibility of real licensing issues in such a situation would be a bad idea.
The Itanium is just surfacing in the enterprise market. Last year was when the Itanium proved itself in benchmarks, and this year is when it comes up on the upgrade cycle for enterprise systems. Before now it just hasnt been worth the bother to migrate, but with the outstanding Itanium 2 performance it's starting to get traction.
Opteron and/or Xeon arent playing in the same market at all. Sure I'd buy an Opteron for my desktop at home when memory, MB and CPU prices fall into the non-pointless range, but Opteron isnt going to be an alternative that is even discussed in the enterprise for the next several years.
Of course, one can have a thing or two to say about Intels strategy to turn the Itanium into a highend expensive chip only rather than leverage their strength in the mass market with cheaper versions. Good shot in the foot on Intels part. Greed got the better of them and they'll suffer from it.
But the Itanium is here to say and it's only just getting started.
I think it's more about the EU Competition Directorate General actually being serious about competition issues. They're fairly good at ripping new orifices in european corporations too.
Riiight. Go run ldd on your X apps and count the libs from X. Try removing the XFree86 libraries from your system and see how many X application will remain functional with another X server. If you can even get any of them to load. The dynamic loader tends to get a bit upset when it cant find libraries anymore.
Unless you're planning on implementing the X libs in each of your clients you sure as hell are going to link that API to your client.
That is the problem. The networked separation is what allows the commercial X servers, but as most applications use the Xlibs from XFree it's not quite the same issue.
"And is the FSF or some other organization going to sue a Linux distributor over shipping XFree86? They'd have to be on crack to want a test case for the GPL like that."
Um, yeah, and as we all know there are no crackpots in Utah, of course, and even if there were they'd never try to sue anyone anywhere, right?
Who says the FSF would be the one trying to mess around with a linux distributor?
Sure the new XFree86 license isnt unreasonable, it's just pointless (as it's not legal to remove copyright notices anyway, so that part is redundant, and they'd probably need a trademark to have a chance to enforce the name usage clause) and it's very definitely incompatible with the GPL.
Acquiring 59 employees shows they're bloody serious? Mr Haff, the analyst, certainly has an interesting take on the concept of being bloody serious. 59 employees for a company of Suns size is probably less than the average weekly turnover.
Dont get me wrong, I like Sun. But in the x86 space they have _serious_ comittment issues, and they've been going back and forth in years.
If you want my 'analysis' I suspect that the Solaris Opteron idea is a strategic plan to try to derail the Itanium train somewhat more, and to one-up MS in the x86 game. That leaves them free to peddle Sparc in the high-end as the Opteron is no threat there for a long time, and it fits perfectly into their "_Solaris_. On. _Sparc_." overall strategic plan.
Which, of course, leaves any Solaris x86-64 customers high and dry as it's just yet another iteration of Suns "support-x86 but only when it suits our marketing and it's not really a serious product" line.
With that in mind, unless Sun can show a serious long range product plan and strategic shift into the x86 space for a longer period, I think I'll go with one of the several competitors who actually mean buisness when they're talking x86 and/or Linux.
"It means rock-solid 64-bit UNIX on commodity x86 hardware. Very cool..."
Not really. It means a rock-solid 64-bit unix that you should be running on SPARC. And by the way, it's gonna be discontinued next month. Or wait... no, we're gonna support it. Maybe. Or maybe not. You should be running Solaris on SPARC. But wait, you can run it on x86-64. Or SPARC. But we're going to discontinue Solaris on anything but SPARC next month. Or not. Well, hey, run x86 Solaris! No, it's not supported. Yes it is. Etc. Etc. Etc.
The fact is, until Sun can get their story straight for 6 consecutive months I wont ever consider running Solaris on anything but SPARC. As long as they cant commit for more than the attention span of a stoned gnat with split personality syndrome I have serious doubts about both the stability and the level of support one will recieve for non-SPARC platforms.
Apart from the controversy over wether SCO can or can not sell any rights to their unix code at all, they most definitely cant sell the right to call something UNIX, as UNIX is a registered trademark which is not in SCO's possession.
So, no, the rights they bought from SCO do not convey the right to call it UNIX.
Mmm... no. It was the communists who were into idea and thought control. The democratic system leans more towards freedom of ideas, thoughts and expression.
Well, unless someone else has the exclusive rights to those thoughts.
"For example, without patents, companies that develop new drugs would quickly disappear."
Heh. They already have. The remaining ones arent developing any new drugs, they're developing new proprietary versions of aspirins that arent better than the old ones except they're patented. Then they send the doctors on golfing trips so they'll prescribe new expensive versions of the same old shit instead of cheap generics.
Well, except the ones that are developing various organ enlargment pills.
I'd place a bet that we'd get more useful medical research done if we scrapped the patent system, kicked the pharmaceutical corps out and relied on public and charity funding for research.
I think you have a bad monitor or a horrid video card in that case (or maybe you should check your convergence settings on the monitor). I have yet to see an LCD screen come even close to the display quality I'm used to looking at.
Not to mention I have a serious problem with LCD viewing angle. Even with the better ones you still get color shifts in various screen areas if you're sitting close enough to them, and if you have a setup with loads of terminals and small fonts, you tend to get fairly close to them.
So, no, until the quality on LCDs improve quite some bit it's CRT all the way for me.
"Which is, uh, basically what I just said. If someone wants to build and distribute a product using GPL code, they also have to GPL their work."
No they dont. They can license their code under a BSD type license or release it as public domain. Only the combined work needs to be distributable under the terms of the GPL, which means the license has to be compatible with the GPL (but not _the_ GPL), to allow distribution of the GPL code itself.
You claimed that the GPL was not meant to make the code stay free, saying people could just as well release it under BSD in that case. The point I'm trying to make is that no, the BSD license is not good enough to protect the freedom of my code.
If someone recieves code that was under BSD license but has been proprietarized, they cannot change that proprietary code. Even if what they wish to change or adjust in the program is part of the BSD portion of the code they cannot change the product they have recieved. The BSD portion of the code is no longer free in that derivative, even if it was in the original. And even if the original remains free, that does not do the recepient of my (proprietarized) code any good, as he still will not be allowed to change my code in the proprietary product.
The GPL preserves the freedom of _my_ code. Any recepient of my code, by any distributor, in any derivative, will be able to change my code.
If you wish to combine my code with your code and license your code under a compatible license, that's ok. I'm only concerned that users should be able to modify _my_ code when they recieve it. If someone wants to release a proprietary version they're free to use your part of the code (which they can separate from mine) if they're allowed by you, as long as they dont distribute my part.
"Trashing users is not really productive. Unless they live and breathe computers they are not going to keep up on every new variation of probelms, and shouldn't be expected to."
Agreed. And MyDoom showed very clearly how totally flawed the 'dont open attachments unless you're expecting them' idea is. The reason it got the level of spread it did is exactly because it emulated expected attachments. People expect various automated returns on unsuccessful mails, so this one got most of the 'responsible' users too.
Allowing execution of binaries from untrusted sources like the internet without active user action is the problem. If Outlook merely forced users to save the attachment and change permissions on the file to executable the whole trojan problem would be _gone_. The number of users who'd not get the warning bells then would number in the thousands, rather than the millions. And most of those wouldnt know how to make the attachment executable anyway.
The whole trojan problems fault lies squarely on the application manufacturers. Userfriendliness is a good idea, but TV's dont have a 'blow tube' button on the remote, nor do cars have a 'set fire to my gas-tank' button. Mail programs should not have the equivalent, just for the sake of simplicity.
"The point of releasing under the GPL is to require other people using GPLed code as a base to develop and distribute their own work to also GPL *their* code."
Not at all. They can distribute their code under whatever license they want, but they cant distribute my code in proprietary form, nor can they distribute my code together with proprietary code.
There is no legal basis for the GPL to force any form of license onto any other code. It only affects the code under the GPL.
If that means some proprietary developer doesnt want to use the GPL code because they wont be allowed to distribute it in a proprietary form or together with their proprietary code, well, that's their problem, not mine.
Slashdot Mirror
As the GPL is a copyright license it is enforced through copyright law and there wont be any case ever about a 'GPL violation'. Any such 'violation' is simply copyright infringement and any court case about it would be a civil or criminal copyright violation case, not a civil contract case.
But ok, I'll do some research for you.
License, not contract
Moglen.
Australian perspective
Wikipedia
Those are just a few starters from any number of articles you wish written by lawyers, legal experts, or laymen.
If you're interested in the concepts of open source licenses I'd also reccomend gmane OSS license mail list and debian-legal.
And, no, I'm not a lawyer. Altho I've been researching copyright law (US and various european versions) and the GPL and other OSS licenses for a decade by now out of interest. If you want a legal opinion I suggest you consult one of the many lawyers you'll find while researching these issues.
Mistaking the GPL for a contract is easy tho, and the reason for most misconceptions about it.
Shrink wrap licenses are in addition to. The GPL is not in addition to. The GPL contains no contractual provisions, and deals entirely in the terms required to obtain the permission of the owner to engage in distribution. The GPL is a bare license with conditions. You meet the conditions you get the right. You dont, you dont get the right.
This is what makes the GPL compatible with most legal systems, what makes it pointless to fight in court and what makes it so easily enforcable. Were it a contract it would require agreement by both parties to be enforced (and also an exchange of consideration in many jurisdiction), and a whole host of issues with agreement needing to be present between each and every holder of copyrights in the combined works would assue. However, as it's not a contract these difficulties do not arise.
So, the result obtained is not difficult to obtain, or in any other way odd. It is the only way a distributor can avoid copyright infringement, so it is the only possible result if they wish to continue distributing the software in question. (But of course, you're right that a code usually wont force them to continue using the code; however, this was an out-of-court settlement, and I guess Allnet wanted to continue using the code).
I reccomend you research the GPL carefully. This is an issue that has been hashed to death many many times.
You confuse the GPL with a contract. It's not. The GPL is not a binding contract, it does not require agreement between the parties, and a violation is not a breach of contract violation.
The GPL _is_, however, the only grant of permission you have to distribute the copyrighted 'intellectual property' distributed under the GPL. If you dont agree to, or follow, the terms of the GPL you're not in breach of contract, you're in violation of copyright law. Behaving in accordance with the terms of the GPL is the only way you will not be engaging in copyright violation.
So, it's not especially strange they get that result. It's the only way to obtain permission to distribute the copyrighted code.
"If the Xfree team exempted linking to libraries from their acknowledgement clause everyone would be happy."
Indeed, that's another possible solution. On the XFree86 side of things there's a whole bunch of solutions, ranging from like you said, tidying up the library licenses, to going through the license goal with someone from, for example, debian-legal who has some experience in GPL compatibility engineering, and coming up with a license scheme that does what they want but in a clean and compatible way. The intent of the change is not necessarily incompatible with the GPL.
As shipped with the various vendors, yes. If you look through them you'll find they're either not GPL, or they have a specific exception for the SSL library.
Operating system exception clause.
In the slightly painful wording of the GPL:
"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."
That's why you can run GPL programs on, and ship them for, proprietary OS's. That clause is also why the commercial UNIX vendors ship most free software separately from their base OS installs. It's why the Linux and BSD vendors can ship the GPL software with the base OS installs. And it's why the Linux and BSD vendors get a world of pain from system component license changes, conflicts and issues.
"Yet we don't see Linux distributers refusing to include products with those licenses."
It's no problem as long as you arent shipping any GPL applications linking with the incompatible code.
There are a whole bunch of GPL licensed applications that link to the X library code. The desktop environments, for starters.
So the choice is between not shipping the new version of X or not shipping any GPL licensed applications that use X. So you can have new X but no Gnome or KDE, or you can have the older revision of X and KDE and Gnome. Which would you prefer?
It's not that Redhat and the others have to insert acknowledgements, it's that they're not allowed to distribute GPL licensed components linked to code that requires them to insert acknowledgements.
Of course, there are ways around the problem. One I've seen would be to distribute the X libraries of a forked X linked with the GPL applications, and distribute the new X server as a completely standalone X server (which is how you can distribute commercial X servers with GPL applications). That would require double installs of a lot of things but it would probably be legal.
"Copyright law forbids removing copyright notices, but it does not require you to include additional ones.. this does."
And the stated purpose of the license change was to prevent others from claiming to have written it... so why doesnt Dawes just slap the notices where he wants them and trust copyright to do his job for him without charging straight into a random license change he cant have run by anyone?
"Second, this has nothing to do with trademark. If I write "DogOS" I can license it to you under the condition that you do not call your version "DogOS"."
But I can still do whatever I want as far as regards the name with the older licensed code. Which makes the entire clause completely contratictory as you can freely use the name as long as you're not using the code? They change the license to get more credit then they try to limit the use of the name in advertising?
Without a trademark I just cant see the point. It appears to follow no form of ordinary logic.
So I guess you're not including GNOME and KDE then? Or you may be in breach of GPL if you link them to X libs with the new license, you know...
Apart from the fact that the license changes are completely redundant as copyright law already forbids removing copyright notices, and that the use of the name should be controlled through a trademark (as it's dubious wether you can control the name usage without one), the clauses may be incompatible with the GPL. That means you risk infringing on GPL software you may distribute like KDE, Qt, Gnome, etc, if you link with X libraries under the new license.
It's not a big deal for the average user, but it's a problem for the distributors. The last year has shown that nutcases can pop out of the woodwork and file lawsuits based on exceptionally odd reasoning. To ship software with the possibility of real licensing issues in such a situation would be a bad idea.
The Itanium is just surfacing in the enterprise market. Last year was when the Itanium proved itself in benchmarks, and this year is when it comes up on the upgrade cycle for enterprise systems. Before now it just hasnt been worth the bother to migrate, but with the outstanding Itanium 2 performance it's starting to get traction.
Opteron and/or Xeon arent playing in the same market at all. Sure I'd buy an Opteron for my desktop at home when memory, MB and CPU prices fall into the non-pointless range, but Opteron isnt going to be an alternative that is even discussed in the enterprise for the next several years.
Of course, one can have a thing or two to say about Intels strategy to turn the Itanium into a highend expensive chip only rather than leverage their strength in the mass market with cheaper versions. Good shot in the foot on Intels part. Greed got the better of them and they'll suffer from it.
But the Itanium is here to say and it's only just getting started.
I think it's more about the EU Competition Directorate General actually being serious about competition issues. They're fairly good at ripping new orifices in european corporations too.
Riiight. Go run ldd on your X apps and count the libs from X. Try removing the XFree86 libraries from your system and see how many X application will remain functional with another X server. If you can even get any of them to load. The dynamic loader tends to get a bit upset when it cant find libraries anymore.
Unless you're planning on implementing the X libs in each of your clients you sure as hell are going to link that API to your client.
That is the problem. The networked separation is what allows the commercial X servers, but as most applications use the Xlibs from XFree it's not quite the same issue.
"And is the FSF or some other organization going to sue a Linux distributor over shipping XFree86? They'd have to be on crack to want a test case for the GPL like that."
Um, yeah, and as we all know there are no crackpots in Utah, of course, and even if there were they'd never try to sue anyone anywhere, right?
Who says the FSF would be the one trying to mess around with a linux distributor?
Sure the new XFree86 license isnt unreasonable, it's just pointless (as it's not legal to remove copyright notices anyway, so that part is redundant, and they'd probably need a trademark to have a chance to enforce the name usage clause) and it's very definitely incompatible with the GPL.
Ah, sorry, need to go back to XFree plus xterm then... no GNOME or KDE as you cant link GPL apps to X with the new license.
Which sorta makes X about on par with virtual consoles as far as GUI's go.
Acquiring 59 employees shows they're bloody serious? Mr Haff, the analyst, certainly has an interesting take on the concept of being bloody serious. 59 employees for a company of Suns size is probably less than the average weekly turnover.
Dont get me wrong, I like Sun. But in the x86 space they have _serious_ comittment issues, and they've been going back and forth in years.
If you want my 'analysis' I suspect that the Solaris Opteron idea is a strategic plan to try to derail the Itanium train somewhat more, and to one-up MS in the x86 game. That leaves them free to peddle Sparc in the high-end as the Opteron is no threat there for a long time, and it fits perfectly into their "_Solaris_. On. _Sparc_." overall strategic plan.
Which, of course, leaves any Solaris x86-64 customers high and dry as it's just yet another iteration of Suns "support-x86 but only when it suits our marketing and it's not really a serious product" line.
With that in mind, unless Sun can show a serious long range product plan and strategic shift into the x86 space for a longer period, I think I'll go with one of the several competitors who actually mean buisness when they're talking x86 and/or Linux.
"It means rock-solid 64-bit UNIX on commodity x86 hardware. Very cool..."
Not really. It means a rock-solid 64-bit unix that you should be running on SPARC. And by the way, it's gonna be discontinued next month. Or wait... no, we're gonna support it. Maybe. Or maybe not. You should be running Solaris on SPARC. But wait, you can run it on x86-64. Or SPARC. But we're going to discontinue Solaris on anything but SPARC next month. Or not. Well, hey, run x86 Solaris! No, it's not supported. Yes it is. Etc. Etc. Etc.
The fact is, until Sun can get their story straight for 6 consecutive months I wont ever consider running Solaris on anything but SPARC. As long as they cant commit for more than the attention span of a stoned gnat with split personality syndrome I have serious doubts about both the stability and the level of support one will recieve for non-SPARC platforms.
Apart from the controversy over wether SCO can or can not sell any rights to their unix code at all, they most definitely cant sell the right to call something UNIX, as UNIX is a registered trademark which is not in SCO's possession.
So, no, the rights they bought from SCO do not convey the right to call it UNIX.
Mmm... no. It was the communists who were into idea and thought control. The democratic system leans more towards freedom of ideas, thoughts and expression.
Well, unless someone else has the exclusive rights to those thoughts.
"For example, without patents, companies that develop new drugs would quickly disappear."
Heh. They already have. The remaining ones arent developing any new drugs, they're developing new proprietary versions of aspirins that arent better than the old ones except they're patented. Then they send the doctors on golfing trips so they'll prescribe new expensive versions of the same old shit instead of cheap generics.
Well, except the ones that are developing various organ enlargment pills.
I'd place a bet that we'd get more useful medical research done if we scrapped the patent system, kicked the pharmaceutical corps out and relied on public and charity funding for research.
I think you have a bad monitor or a horrid video card in that case (or maybe you should check your convergence settings on the monitor). I have yet to see an LCD screen come even close to the display quality I'm used to looking at.
Not to mention I have a serious problem with LCD viewing angle. Even with the better ones you still get color shifts in various screen areas if you're sitting close enough to them, and if you have a setup with loads of terminals and small fonts, you tend to get fairly close to them.
So, no, until the quality on LCDs improve quite some bit it's CRT all the way for me.
"Which is, uh, basically what I just said. If someone wants to build and distribute a product using GPL code, they also have to GPL their work."
No they dont. They can license their code under a BSD type license or release it as public domain. Only the combined work needs to be distributable under the terms of the GPL, which means the license has to be compatible with the GPL (but not _the_ GPL), to allow distribution of the GPL code itself.
You claimed that the GPL was not meant to make the code stay free, saying people could just as well release it under BSD in that case. The point I'm trying to make is that no, the BSD license is not good enough to protect the freedom of my code.
If someone recieves code that was under BSD license but has been proprietarized, they cannot change that proprietary code. Even if what they wish to change or adjust in the program is part of the BSD portion of the code they cannot change the product they have recieved. The BSD portion of the code is no longer free in that derivative, even if it was in the original. And even if the original remains free, that does not do the recepient of my (proprietarized) code any good, as he still will not be allowed to change my code in the proprietary product.
The GPL preserves the freedom of _my_ code. Any recepient of my code, by any distributor, in any derivative, will be able to change my code.
If you wish to combine my code with your code and license your code under a compatible license, that's ok. I'm only concerned that users should be able to modify _my_ code when they recieve it. If someone wants to release a proprietary version they're free to use your part of the code (which they can separate from mine) if they're allowed by you, as long as they dont distribute my part.
Do you get what I mean?
"Trashing users is not really productive. Unless they live and breathe computers they are not going to keep up on every new variation of probelms, and shouldn't be expected to."
Agreed. And MyDoom showed very clearly how totally flawed the 'dont open attachments unless you're expecting them' idea is. The reason it got the level of spread it did is exactly because it emulated expected attachments. People expect various automated returns on unsuccessful mails, so this one got most of the 'responsible' users too.
Allowing execution of binaries from untrusted sources like the internet without active user action is the problem. If Outlook merely forced users to save the attachment and change permissions on the file to executable the whole trojan problem would be _gone_. The number of users who'd not get the warning bells then would number in the thousands, rather than the millions. And most of those wouldnt know how to make the attachment executable anyway.
The whole trojan problems fault lies squarely on the application manufacturers. Userfriendliness is a good idea, but TV's dont have a 'blow tube' button on the remote, nor do cars have a 'set fire to my gas-tank' button. Mail programs should not have the equivalent, just for the sake of simplicity.
"remember, 802.11b is compatible with 802.11g, just slower"
Yep. Slower, as in _everyone_ is slower. All 11g devices will degrade to 11b in the presense of an 11b device.
"The point of releasing under the GPL is to require other people using GPLed code as a base to develop and distribute their own work to also GPL *their* code."
Not at all. They can distribute their code under whatever license they want, but they cant distribute my code in proprietary form, nor can they distribute my code together with proprietary code.
There is no legal basis for the GPL to force any form of license onto any other code. It only affects the code under the GPL.
If that means some proprietary developer doesnt want to use the GPL code because they wont be allowed to distribute it in a proprietary form or together with their proprietary code, well, that's their problem, not mine.