What you've said is true, it just misses some of the subtleties (which, admittedly, were not fleshed out in my comment). For instance:
Let's first assume that the GPLed code for project XYZZY has multiple owners, since multiple people had been contributing to it. Let's further assume that the majority owner of the software, Plugh, had made binary distributions that did not include source (the GPL provides a license to do this even though the code is not 100% owned by Plugh). Finally, let's assume that Plugh has now purchased some of these copyrighted chunks and replaced the rest with their own code so that they can take the remaining source for XYZZY private. The GPL states that for the prior binary distributions to be in compliance with the GPL that the source for that distribution must be made available on request for a certain number of years. This obligation would still be in effect or the minority copyright holders would be able to claim that the conditions of the GPL had not been met, and thus the prior distribution of a binary was in violation of their copyright. Remember this is just the old code as used to make old binaries, not anything that was added after the code went private.
Of course, if there were no minority copyright holders in the GPLed source, then the full owner of the source didn't need the GPL for their prior binary distributions, so they are not obligated to provide the old source code on request. Alternately, if they never made binary distributions (just released the source), their obligations to any minority copyright holders would have already been fullfilled by the fact that they had been providing the source all along.
I believe that the original poster meant that, if they had distributed some binaries based on GPL-software to some folks before the code when private, there is still an obligation to provide that old version of the source code (not any new code) as per the licence it was distributed under. In other words, a buy-out to make the code proprietary doesn't affect access to prior Open Source distributions of the code.
Git was not created to be a general-purpose SCM system -- it is designed to handle the Linux source code only, so it has design decisions that make that task fast (and to make development easy too). I believe that git is a stop-gap, "good enough for now" system that will be abandoned when one of the open-source (real) SCM systems is fast enough to handle what Linus needs it to do (e.g. both Monotone and darcs are coming out with performance releases in an attempt to meet this need).
"sometimes going with non-open-source software is a good temporary solution" is not a good solution, temporary or not.
This is the crux of the disagreement with the hard-line Free Software crowd (such as RMS and, apparently, yourself), and Open Software advocates (such as Linus and myself) -- if you believe that the lack of source code is somehow immoral (as RMS does), then nothing that anyone argues about making sensible decisions based on balancing your needs will ever make you decide that using closed-source software was actually a good idea.
I think that having source is a huge benefit, but it is one benefit that needs to be balanced against your other needs. Sometimes the lack of source outweighs the benefits of some software, and sometimes the benefits are so great that they outweigh the lack of source. It's as simple as that. This was one of the latter cases, IMO.
Linus himself has said that using Bitkeeper for these last few years was very valuable, even in light of the current events. Linus needed a powerful SCM system, and the open-source alternatives just weren't good enough at the time to fit the bill, so BK was definitely a good choice at the time, and continues to have been a good choice even in retrospect.
Even today, the alternatives to BK aren't quite good enough to handle what is needed for developing Linux, but they are getting much closer. Linus is currently planning to use a non-SCM tool for the final "logging" of what goes into the official kernel, but this is only possible because most of the hard work of merging changes into the kernel from a wide variety of sources will be done by other people, including those who will still be running licensed versions of BK (at least for the near future, if not for some time to come).
Yes, the most recent events do demonstrate how open-source tools are a clearly superior in preventing getting abandoned by a proprietary vendor, but sometimes going with non-open-source software is a good temporary solution while waiting for open-source software to catch up with your needs.
the particular way that API is expressed in the headers is copyrightable.
When SCO was claiming that errno.h was too similar to the file in Linux, some folks made the claim that "define" lists of names and values was not copyrightable (similar to how name/phone-number pairs are not copyrightable). I do know that this was a separate claim from those who were saying that the files had been too widely distributed to be copyrighted in total. I don't know if the reason for that defined-list claim was that the values were a part of a standard or for some other reason, so I'll be quiet on this topic now.
suppose you had an existing infringement [...] you could apply a GPL-compatible license to your work.
Exactly -- it is the person that can choose to make a work GPLed since the GPL has no power to do this itself. This is an important point for folks to keep in mind since I have seen so many other people erroneousy assume that someone's work became GPLed just by the (illegal) inclusion of GPLed code in their work, and this mistaken belief is played up by Microsoft in their FUD that the GPL is "viral". So, it sounds like we're in agreement here.
The most serious misconception you have is that there is no requirement to GPL one's derivative code since the GPL isn't a contract.
That's not my misconception, that's your misinterpretation of what I said. I said that there would be no need to GPL one's derivative code of a non-copyrighted part of a GPLed work if the interfaces turn out to be non-copyrightable. In that case anyone can freely use those portions of the code, including making derivative works, without needing the GPL. It is only if the interfaces are copyrightable that the GPL would be needed to grant permission to copy someone else's copyrighted work. I only mentioned the non-contractual basis of the GPL because there is a pervasive belief by some (though not necessarily you) that the GPL can make someone else's work GPLed just by coming in contact with it (which it cannot).
The part of the SCO trials I was referring to was when SCO brought up allegations that Linus had copied Unix header files in the creation of Linux. Part of the community's response to that claim was that such header files were not copyrightable.
It is an unauthorized derived work, even though nVidia wrote the whole thing. It incorporates a significant amount of copyrighted information on kernel internals that it must connect to.
In the SCO vs IBM case, people have been saying that such interface code (such as header files) is not copyrightable. If that is the case, then there is no GPL violation because the person using the GPLed code is not breaking copyright to include such derived interface information, and thus they don't need the license provided by the GPL to allow them to distribute. (Remember that
the
GPL is not a contract, so there is no requirement for someone to GPL their derivative code -- they normally need to abide by the GPL in order to get the right to distribute someone else's copyrighted work.)
Allow me to quote from the Wikipedia page you referenced:
Hyphenation is also common with adjective-noun compound modifiers, but arguably less generally.
So, the phrase doesn't need to be a compound word to be hyphenated--it forms a compound modifer, and thus needs to be hyphenated to convey the proper meaning.
Malicious Software Removal Tool, The software-removal tool is malicious.
Malicious-Software Removal Tool, The tool removes malicious software.
It's apparently a result of MS flunking out of their English-syntax classes. The title of their page clearly states that their software is "Malicious" (and it's refreshing to see them freely admit that). It also claims to be a tool that removes software, though the title doesn't tell you what kind. Judging from the text of the rest of the page, the title should have been this:
Malicious-Software Removal Tool
A dropped hyphen often makes a big difference in the meaning of a sentence.
How about instead of 2.7 being the groundwork for 2.8, why don't we put changes into 2.7, let the early adopters and kernel hackers use it, and when we find bugs like the Cd-burning problem, we can fix them before we release into 2.6
What you have just described is the workings of the -mm patchset that Andrew Morton maintains. So, the process is already in place--maybe it just needs to be refined a bit more (and perhaps more folks need to be actively testing it).
I think he was intentionally more reckless than normal with his daily double wagers, especially considering how close the woman (Nancy?) was to him both times he lost the daily doubles.
I agree with you. In his earlier days he would have never wagered an amount that could have brought him down to near parity with an opponent. In such a situation earlier on in his run, he had risked very small amounts in order to protect his lead.
I find it interesting that the Final Jeopardy answer was more of a "guess the answer by deductive reasoning" style of question rather than a "known trivia" question, so it's certainly possible that Ken just didn't think of the tax season when trying to deduce the correct answer.
The Supreme Court was very clear in its ruling that copyright infringement is not theft:
Dowling v. United States, 473 U.S. 207 (1985): copyright infringement does not equal theft
These are different actions which have different effects and different penalties. Thus, it behooves us to be clear in the speech we use when we're talking about them.
Your argument is flawed. The OS can use any package system it wants for its own packages, it just needs to be able to install LSB packages from venders that will be in RPM format. Debian already has support for this through the "alien" software. In fact, Progeny Componentized Linux is already very far along in implementing LSB 2.0 support for their Debian-based release, so the format of LSB packages is not a barrier for Debian at all.
Here's my counter suggestion to your "perfect flag" idea:
Add release versions to pages where one or more editor/bureaucrat empowered users would take the current work of everyone (plus any personal edits) and release a new version of the page. The latest released version of a page would be the one that the public sees when browsing the wikipedia (by default), with an option to click through to the latest scratch-pad version (if no released version of a page existed, the user would see the wiki page with some appropriate marking to distinguish the different page forms). Only the free-for-all wiki version of the article is editable, and everyone is free to continue to collaborate on a new version at any time.
This editorial model is closer to what is achieved by an open source software project--peoples ideas, suggestions, and patches are filtered through a release mechanism to generate a more authoritative and consistent end result. This also gives the reader more choices, since they can continue to browse the current wiki pages if they so desire, but they would also have access to "blessed" pages that would have gone through a quality review process to achieve their new release status.
Of course, the big problem with this idea is one of resources. Where do you get the people who are ready, willing, and able to do some editor roles and rove through the raw pages, creating the newest release pages? Some sort of cooperative process would probably be needed where pages that were nominated as ready for a new release would be reviewed by multiple people of various disciplines, including those that can fact-check the information (perhaps choosing several from a pool of volunteers in the required area of expertise) and those that can check for mistakes in grammar, spelling, and such.
I think that the current wikipedia is a wonderful resource, but if it wants to achieve the reliability part of their stated goals, an extra process such as the one suggested above will need to be enacted to make that goal possible.
Blue Origin is "currently working to develop a crewed, suborbital launch system that emphasizes safety and low cost of operations."
I think we should start a new urban myth around this line (akin to the tales such as the Nova not selling well in Mexico). Let's hope that the end result of their work is something really ugly, then we can tell everyone about a conversation that must have gone like this:
Mr. X: I want to develop a crewed, suborbital launch system.
Mr. Y: No worries there! We can make it as crude as you like.
Some moderator must be confused -- I replied to a message that mentioned that the site is slashdotted with a message that provided a mirror link and a long-term solution to avoid slashdotting of small sites in the future and that is somehow off-topic?
Note that the site has changed their content due to the increased traffic, so the mirror link is now different. That mirror is now working fine.
It would be good if the Slashdot editor posting a story would insert a (mirror) link in the original article for any site that might get slashdotted. The example link I just used makes use of the Coral NYU Distribution Network, which will mirror any site as long as you add ".nyud.net:8090" onto the end of the hostname (of course, the/. editor would also need to follow the link to get the site into the cache).
If the editors only want to add a mirror link for sites that actually need it, I'd suggest having each editor prepare the mirror link in advance, visit the Coral-mirrored version of the site (to get it into the cache), and then update the article with the mirror link if the site bogs down. (Unfortunately, the Powers That Be may be against this idea since they'd like to sell/. subscriptions, and having a site get slashdotted probably helps to sell more of them.)
As it stands currently, the Coral caching system can't access the slashdotted site any more than we can, but if everyone will try to access the site using the mirror instead of the main article's link, the slashdotted site should become available more quickly than if everyone continues to pound on the site directly.
The UI used by the CGI is pretty horrible. I can imagine a much easier one given a drag-and-drop toolkit:
Start with all the names below a line. The voter grabs a name and drags it up into the vote area above the line. The voter can drop a name above or below any other name already in the vote area and the existing names move appropriately to create the numbered list. Any name left below the line is not voted for (which is OK -- everyone you voted for is preferred over the names you didn't move, which all tie for last place in your estimation).
This would make it easy to see who you've ranked so far, and let you easily move the names around into the proper order without having to manually renumber anything or twiddle a bunch of buttons.
There's something very wrong about the results page of that poll CGI you cite.
For one thing, the results don't mirror each other across the diagonal like they should (e.g. in one intersection for Kerry and Bush it said A=151,B=152,NP=9 while in the other intersection it said A=112,B=191,NP=9).
Another problem is that the legend says that "A" votes are for the person in the column headers, but if you read down the Nader column, every single item lists a higher "B" value (for the person in the row) but the results claim that Nader is undefeated.
OK, so if we assume that they got A and B backwards, we then notice that in some boxes when "A" is the winner it is colored blue, while in other boxes when "B" is the winner it is colored blue but the win-loss summary at the bottom matches the colors, not the values.
So, it looks like there is a very big problem with the program they are using to either calculate or display the results.
Actually, I believe such a derived work is automatically GPL'd.
A lot of people seem to believe this, but it isn't so. The problem stems from the idea that the GPL has some kind of contractual power to cause something to happen to derived code and it does not. It's just a license, and a license grants extra rights to someone that follows its stipulatons. It tells you how you can gain the ability to redistribute some code without violating its copyright (by following the GPL and choosing to license derivative changes under the GPL as well), but it has no power to force that to happen.
So, what happens when someone takes a GPLed work, modifies it, and distributes the changes with a license that says "This work is under the GPL except for the changes made by Joe Bloe, which are proprietory and not for redistribution except by Joe Bloe"? What happens is that the copyright holders of the GPLed code have had their copyrights violated. No code is ever automatically GPLed because the GPL doesn't have the power to coerce anything -- it's just a license that conditionally grants rights.
If by default employing an off-site contractor you automatically are considered under the GPL to be distributing the work, then yes, he distributed it
That isn't what the GPL FAQ is talking about. It is talking about GPL code that has been modified in-house to create a program that is run in-house. If that program is given to a contractor "for use off-site" (emphasis added), that is considered distribution. Having a contractor modify some GPL code for you to use in an in-house application is not distribution. Of course, to obey the full letter of the law and not just its spirit, you should have the contractor create the modified version for you using an editor on your own system (i.e. not have the contractor create the modifications off-site and then copy them to your system).
If you get a 503 error, delete the slashdot cookies your browser has stored and reload the page. Apparently there is (was?) some kind of a database bug that could be triggered in a number of different ways, and one of them happened when slashdot was trying to load up the user prefs referenced in a login cookie. Some folks have had success re-logging in after getting to the main page in this manner. YMMV.
This also appears to be the reason that some folks report that they have success using IE (it's not logged in) but not in Firefox (it is logged it).
On the other hand, they know that if this was an IE vulnerability, they'd be all over it and crying out about "why would anybody still be using IE, especially if this was known for five years!!"
This is a vulnerability in IE, and in Opera, and in every other web browser on the planet that has any kind of image+scripting support (DHTML support is needed for a really convincing spoof, but less convincing spoofs can still be effective).
For a good example of a spoof that affects IE, go to this web page and scroll down to the links in the "Spoofing" section (not the links in the "Misleading URLs" section).
So, the only thing that is Firefox-specific about this bug is that the originally cited implementation used XUL (instead of more generic DHTML) and mimicked the look of Firefox (instead of IE's or Opera's look).
Slashdot Mirror
What you've said is true, it just misses some of the subtleties (which, admittedly, were not fleshed out in my comment). For instance:
Let's first assume that the GPLed code for project XYZZY has multiple owners, since multiple people had been contributing to it. Let's further assume that the majority owner of the software, Plugh, had made binary distributions that did not include source (the GPL provides a license to do this even though the code is not 100% owned by Plugh). Finally, let's assume that Plugh has now purchased some of these copyrighted chunks and replaced the rest with their own code so that they can take the remaining source for XYZZY private. The GPL states that for the prior binary distributions to be in compliance with the GPL that the source for that distribution must be made available on request for a certain number of years. This obligation would still be in effect or the minority copyright holders would be able to claim that the conditions of the GPL had not been met, and thus the prior distribution of a binary was in violation of their copyright. Remember this is just the old code as used to make old binaries, not anything that was added after the code went private.
Of course, if there were no minority copyright holders in the GPLed source, then the full owner of the source didn't need the GPL for their prior binary distributions, so they are not obligated to provide the old source code on request. Alternately, if they never made binary distributions (just released the source), their obligations to any minority copyright holders would have already been fullfilled by the fact that they had been providing the source all along.
I believe that the original poster meant that, if they had distributed some binaries based on GPL-software to some folks before the code when private, there is still an obligation to provide that old version of the source code (not any new code) as per the licence it was distributed under. In other words, a buy-out to make the code proprietary doesn't affect access to prior Open Source distributions of the code.
Git was not created to be a general-purpose SCM system -- it is designed to handle the Linux source code only, so it has design decisions that make that task fast (and to make development easy too). I believe that git is a stop-gap, "good enough for now" system that will be abandoned when one of the open-source (real) SCM systems is fast enough to handle what Linus needs it to do (e.g. both Monotone and darcs are coming out with performance releases in an attempt to meet this need).
This is the crux of the disagreement with the hard-line Free Software crowd (such as RMS and, apparently, yourself), and Open Software advocates (such as Linus and myself) -- if you believe that the lack of source code is somehow immoral (as RMS does), then nothing that anyone argues about making sensible decisions based on balancing your needs will ever make you decide that using closed-source software was actually a good idea.
I think that having source is a huge benefit, but it is one benefit that needs to be balanced against your other needs. Sometimes the lack of source outweighs the benefits of some software, and sometimes the benefits are so great that they outweigh the lack of source. It's as simple as that. This was one of the latter cases, IMO.
Even today, the alternatives to BK aren't quite good enough to handle what is needed for developing Linux, but they are getting much closer. Linus is currently planning to use a non-SCM tool for the final "logging" of what goes into the official kernel, but this is only possible because most of the hard work of merging changes into the kernel from a wide variety of sources will be done by other people, including those who will still be running licensed versions of BK (at least for the near future, if not for some time to come).
Yes, the most recent events do demonstrate how open-source tools are a clearly superior in preventing getting abandoned by a proprietary vendor, but sometimes going with non-open-source software is a good temporary solution while waiting for open-source software to catch up with your needs.
When SCO was claiming that errno.h was too similar to the file in Linux, some folks made the claim that "define" lists of names and values was not copyrightable (similar to how name/phone-number pairs are not copyrightable). I do know that this was a separate claim from those who were saying that the files had been too widely distributed to be copyrighted in total. I don't know if the reason for that defined-list claim was that the values were a part of a standard or for some other reason, so I'll be quiet on this topic now.
suppose you had an existing infringement [...] you could apply a GPL-compatible license to your work.
Exactly -- it is the person that can choose to make a work GPLed since the GPL has no power to do this itself. This is an important point for folks to keep in mind since I have seen so many other people erroneousy assume that someone's work became GPLed just by the (illegal) inclusion of GPLed code in their work, and this mistaken belief is played up by Microsoft in their FUD that the GPL is "viral". So, it sounds like we're in agreement here.
That's not my misconception, that's your misinterpretation of what I said. I said that there would be no need to GPL one's derivative code of a non-copyrighted part of a GPLed work if the interfaces turn out to be non-copyrightable. In that case anyone can freely use those portions of the code, including making derivative works, without needing the GPL. It is only if the interfaces are copyrightable that the GPL would be needed to grant permission to copy someone else's copyrighted work. I only mentioned the non-contractual basis of the GPL because there is a pervasive belief by some (though not necessarily you) that the GPL can make someone else's work GPLed just by coming in contact with it (which it cannot).
The part of the SCO trials I was referring to was when SCO brought up allegations that Linus had copied Unix header files in the creation of Linux. Part of the community's response to that claim was that such header files were not copyrightable.
In the SCO vs IBM case, people have been saying that such interface code (such as header files) is not copyrightable. If that is the case, then there is no GPL violation because the person using the GPLed code is not breaking copyright to include such derived interface information, and thus they don't need the license provided by the GPL to allow them to distribute. (Remember that the GPL is not a contract, so there is no requirement for someone to GPL their derivative code -- they normally need to abide by the GPL in order to get the right to distribute someone else's copyrighted work.)
So, the phrase doesn't need to be a compound word to be hyphenated--it forms a compound modifer, and thus needs to be hyphenated to convey the proper meaning.
It's apparently a result of MS flunking out of their English-syntax classes. The title of their page clearly states that their software is "Malicious" (and it's refreshing to see them freely admit that). It also claims to be a tool that removes software, though the title doesn't tell you what kind. Judging from the text of the rest of the page, the title should have been this:
Malicious-Software Removal Tool
A dropped hyphen often makes a big difference in the meaning of a sentence.
What you have just described is the workings of the -mm patchset that Andrew Morton maintains. So, the process is already in place--maybe it just needs to be refined a bit more (and perhaps more folks need to be actively testing it).
I agree with you. In his earlier days he would have never wagered an amount that could have brought him down to near parity with an opponent. In such a situation earlier on in his run, he had risked very small amounts in order to protect his lead.
I find it interesting that the Final Jeopardy answer was more of a "guess the answer by deductive reasoning" style of question rather than a "known trivia" question, so it's certainly possible that Ken just didn't think of the tax season when trying to deduce the correct answer.
The Supreme Court was very clear in its ruling that copyright infringement is not theft:
Dowling v. United States, 473 U.S. 207 (1985): copyright infringement does not equal theft
These are different actions which have different effects and different penalties. Thus, it behooves us to be clear in the speech we use when we're talking about them.
Your argument is flawed. The OS can use any package system it wants for its own packages, it just needs to be able to install LSB packages from venders that will be in RPM format. Debian already has support for this through the "alien" software. In fact, Progeny Componentized Linux is already very far along in implementing LSB 2.0 support for their Debian-based release, so the format of LSB packages is not a barrier for Debian at all.
Add release versions to pages where one or more editor/bureaucrat empowered users would take the current work of everyone (plus any personal edits) and release a new version of the page. The latest released version of a page would be the one that the public sees when browsing the wikipedia (by default), with an option to click through to the latest scratch-pad version (if no released version of a page existed, the user would see the wiki page with some appropriate marking to distinguish the different page forms). Only the free-for-all wiki version of the article is editable, and everyone is free to continue to collaborate on a new version at any time.
This editorial model is closer to what is achieved by an open source software project--peoples ideas, suggestions, and patches are filtered through a release mechanism to generate a more authoritative and consistent end result. This also gives the reader more choices, since they can continue to browse the current wiki pages if they so desire, but they would also have access to "blessed" pages that would have gone through a quality review process to achieve their new release status.
Of course, the big problem with this idea is one of resources. Where do you get the people who are ready, willing, and able to do some editor roles and rove through the raw pages, creating the newest release pages? Some sort of cooperative process would probably be needed where pages that were nominated as ready for a new release would be reviewed by multiple people of various disciplines, including those that can fact-check the information (perhaps choosing several from a pool of volunteers in the required area of expertise) and those that can check for mistakes in grammar, spelling, and such.
I think that the current wikipedia is a wonderful resource, but if it wants to achieve the reliability part of their stated goals, an extra process such as the one suggested above will need to be enacted to make that goal possible.
I think we should start a new urban myth around this line (akin to the tales such as the Nova not selling well in Mexico). Let's hope that the end result of their work is something really ugly, then we can tell everyone about a conversation that must have gone like this:
Mr. X: I want to develop a crewed, suborbital launch system.
Mr. Y: No worries there! We can make it as crude as you like.
Note that the site has changed their content due to the increased traffic, so the mirror link is now different. That mirror is now working fine.
If the editors only want to add a mirror link for sites that actually need it, I'd suggest having each editor prepare the mirror link in advance, visit the Coral-mirrored version of the site (to get it into the cache), and then update the article with the mirror link if the site bogs down. (Unfortunately, the Powers That Be may be against this idea since they'd like to sell /. subscriptions, and having a site get slashdotted probably helps to sell more of them.)
As it stands currently, the Coral caching system can't access the slashdotted site any more than we can, but if everyone will try to access the site using the mirror instead of the main article's link, the slashdotted site should become available more quickly than if everyone continues to pound on the site directly.
I think the site's moderator will sign his missives as "Prosco P. Coltraine" and post stories such as the following:
Dem [Open Source] Duke Boys has got to be up to something low down, and I'm gonna find out what!
I can almost hear them laughing now...
Start with all the names below a line. The voter grabs a name and drags it up into the vote area above the line. The voter can drop a name above or below any other name already in the vote area and the existing names move appropriately to create the numbered list. Any name left below the line is not voted for (which is OK -- everyone you voted for is preferred over the names you didn't move, which all tie for last place in your estimation).
This would make it easy to see who you've ranked so far, and let you easily move the names around into the proper order without having to manually renumber anything or twiddle a bunch of buttons.
For one thing, the results don't mirror each other across the diagonal like they should (e.g. in one intersection for Kerry and Bush it said A=151,B=152,NP=9 while in the other intersection it said A=112,B=191,NP=9).
Another problem is that the legend says that "A" votes are for the person in the column headers, but if you read down the Nader column, every single item lists a higher "B" value (for the person in the row) but the results claim that Nader is undefeated.
OK, so if we assume that they got A and B backwards, we then notice that in some boxes when "A" is the winner it is colored blue, while in other boxes when "B" is the winner it is colored blue but the win-loss summary at the bottom matches the colors, not the values.
So, it looks like there is a very big problem with the program they are using to either calculate or display the results.
A lot of people seem to believe this, but it isn't so. The problem stems from the idea that the GPL has some kind of contractual power to cause something to happen to derived code and it does not. It's just a license, and a license grants extra rights to someone that follows its stipulatons. It tells you how you can gain the ability to redistribute some code without violating its copyright (by following the GPL and choosing to license derivative changes under the GPL as well), but it has no power to force that to happen.
So, what happens when someone takes a GPLed work, modifies it, and distributes the changes with a license that says "This work is under the GPL except for the changes made by Joe Bloe, which are proprietory and not for redistribution except by Joe Bloe"? What happens is that the copyright holders of the GPLed code have had their copyrights violated. No code is ever automatically GPLed because the GPL doesn't have the power to coerce anything -- it's just a license that conditionally grants rights.
To read about this in greater detail, see PJ's excellent article on Groklaw entitled The GPL is a license, not a contract.
That isn't what the GPL FAQ is talking about. It is talking about GPL code that has been modified in-house to create a program that is run in-house. If that program is given to a contractor "for use off-site" (emphasis added), that is considered distribution. Having a contractor modify some GPL code for you to use in an in-house application is not distribution. Of course, to obey the full letter of the law and not just its spirit, you should have the contractor create the modified version for you using an editor on your own system (i.e. not have the contractor create the modifications off-site and then copy them to your system).
If you get a 503 error, delete the slashdot cookies your browser has stored and reload the page. Apparently there is (was?) some kind of a database bug that could be triggered in a number of different ways, and one of them happened when slashdot was trying to load up the user prefs referenced in a login cookie. Some folks have had success re-logging in after getting to the main page in this manner. YMMV.
This also appears to be the reason that some folks report that they have success using IE (it's not logged in) but not in Firefox (it is logged it).
This is a vulnerability in IE, and in Opera, and in every other web browser on the planet that has any kind of image+scripting support (DHTML support is needed for a really convincing spoof, but less convincing spoofs can still be effective).
For a good example of a spoof that affects IE, go to this web page and scroll down to the links in the "Spoofing" section (not the links in the "Misleading URLs" section).
So, the only thing that is Firefox-specific about this bug is that the originally cited implementation used XUL (instead of more generic DHTML) and mimicked the look of Firefox (instead of IE's or Opera's look).