Compatibility in this context means the ability to mix the code, not necessarily the ability to remove the text of the other license.
Any code, regardless of licensing conditions, can be mixed, the problem that comes up is the legality, particularly of distribution. The problem with the GPLv2 and the BSD license is that, if your upstream code is under those licenses, there are no legal terms that you are authorized to distribute the combined work under. If you don't include the BSD-required terms, you violate the BSD license. If you include the BSD terms and the GPLv2 terms, you violate the GPLv2 license, which specifically prohibits adding any additional terms to the GPLv2 terms. If you omit the GPLv2 terms, you violate the GPLv2 again. In either case, since you cannot comply with at least one of the necessary licenses, any distribution is a violation of copyright law.
Any of the common "Linux distributions" do consist largely of the GNU System.
Please provide a quantitative definition of "largely" and evidence that this is true for any significant number of the common Linux distributions.
It's not just "some tools"... it's the entire set of software on top of the kernel that take the system to the level of a Unix-like OS.
Even granting, arguendo, that the "entire set of software on top of the kernel" on any popular Linux distribution was from the GNU project (which is rather emphatic not the case for any actual popular Linux distribution), the fact remains that the product as a whole is not the GNU OS, because, whatever is on top of the kernely, the kernel is not the GNU kernel. Its a different OS sharing components.
If you wanted to build a Unix-like OS on top of Linux without GNU, your only other option would be to take vast chunks of some other Unix-like OS like Solaris or *BSD.
Perhaps. But then...
Sure, there's a component here or there that's from somewhere else - a good example would be init - but GNU/Linux without GNU wouldn't be a Unix-like OS anymore.
You just contradicted yourself, in one hand pointing to free alternatives to GNU that could be used with the Linux kernel, and in the next saying that this is impossible.
At any point, all that's irrelevant to what I said. I never said that Linux distributions weren't Unix-like largely because they incorporated tools from the GNU project. Nor did I say that using the Linux kernel was the only way a Unix-like OS could be built incorporating GNU tools. So I'm not sure why you've spent so much effort making these points, which don't contradict anything I've said.
All I've said is that none of the various Linux distributions are not an operating system created by the GNU project, they are operating systems that incorporate GNU tools with the Linux kernel. And you've provided no reason to believe anything differently.
Just note that the FSF considers just about every BSD/ISC/MIT-type license compatible with both the GPLv2 and 3.
I am aware that the FSF considers that to be the case. I am also aware that the FSF has an ideological interest in people relicensing code under the GPL, and is hardly a neutral expert on the matter. Now, I'm not saying that the BSD is definitively incompatible with the GPLv2, but it seems pretty strongly on its face to be.
I think the difference is that you're using compatible in a strict licensing context while I generally use in in terms of mixing GPL and BSD code, and distrbuting derived works.
If you mix GPL and BSD code and distribute derived works, it is a copyright violation of at least one of the upstream works if the two license are not compatible "in a strict licensing context".
The problem though is that over time many risks people previously deemed as theoretical have come to pass.
That's a problem for people for whom GPL violations, theoretical or actual, are a serious ideological concern, rather than a legal concern only where the GPL actually applies. I would suggests that the developers, maintainers, and distributers of xBSD operating systems do not, as a rule, fall into that category.
The GNU System is an OS developed by the GNU project, therefore it would be polite to refer to it by its name. (the RMS position)
No, the RMS position is not that, since Linux is not the OS developed by the GNU project. It is an OS that's common feature is the Linux kernel; as usually distributed, it includes various tools from the GNU project. The RMS position is, roughly, "The GNU System is an OS developed by the GNU Project, and therefore every project that incorporates any components from that system is also morally obligated to include 'GNU' in the name of there product, even though they have express written permission to distribute the product without doing so."
But even that's not exactly right, because this argument is only applied to Linux, not to other products that incorporate GNU tools.
The GNU project's own OS doesn't have a general release yet, though its been coming Real Soon Now for my entire adult life.
The GNU System is an OS developed by the GNU project, but people who redistribute it can call it whatever they want. (the jerk position)
Actually, that is, properly speaking, "the GPL position", since the GPL does not have any provision requiring adhering to upstream naming conventions or request. If the GNU project had wanted to make that a condition of distribution, they ought to have incorporated it into the license under which they authorized people to redistribute their code and create derivative works.
Complaining about people doing something you've given them express, written legal permission to do is somewhat childish, especially when you've (since you began complaining) revised the legal terms offered more than once without addressing the thing you keep complaining about.
The idea of "the GNU system" is foolish. The GNU project just wrote some tools. Operating System is just another word for Kernel anyway. (the Linus position)
The GNU project may or may not have written an operating system, but Linux isn't it. An operating system is more than a kernel, but a kernel is an indispensable portion of the operating system. Using some OS components GNU developed and some other OS components doesn't make the result the same OS GNU developed. Its something else. Distributors are free to call it things that highlight the kernel by including its name ("Red Hat Enterprise Linux"), things that evoke the name of the kernel without actually using it exactly ("Lindows"), or things that don't mention the kernel at all ("Knoppix"). They could do the same thing with the GNU toolchain. The fact that none of the distributors wan't to label the OS in a way that highlights the GNU toolchain may be disappointing to the members of the GNU project, but since they've expressly (and repeatedly, given the revisions to the GPL) given distributors permission to do exactly what they are doing, they don't really have any leg to stand on in complaining about it.
I'd be interested in seeing exactly what constitutes their 'boilerplate' level of evidence.
Evidence isn't at issue; this is a complaint, evidence hadn't even been presented yet. What this ruling says is that they didn't make specific enough allegations to even have a complaint that the defendant was obligated to respond to.
Must they now provide solid evidence of a crime verses their word that one occurred?
Its not a criminal case, but a civil one so "crime" is mostly irrelevant. This isn't about proof, either. This is about the degree of specificity required in the allegations in the original filing for there even to be a case.
All BSD derived work (binary, source, etc) must be redistributable?
I believe not; the conditions that must be included restrict distribution (requiring any distribution to include the appropriate terms, disclaimers, and notices), and additional terms (including ones prohibiting redistribution) can be imposed.
Of all the different movements you mentioned, except for the organic foods movement the specific product is not important to the goals of the movement.
That's certainly not true, in many cases, of the religious movements, where the particular goods and services produced are often (though not always exclusively) those central to the ideological mission of the movement, rather than merely instrumental to the economic life of the movement. OTOH, even granting that that's a valid difference, that's not the respect in which Free Software was originally held out as "almost unique". I'll agree that the Free Software movement (along with the organic foods movement) is at least distinct (though, still, I think far from unique) in being a movememt that is about a particular kind of product where the major form of activism is directly producing and/or consuming the product (there are plenty of other movements that produce goods and services, and plenty of other movements that are about goods and services, but not so many that combine both.)
The alternative fuels movement has some features of this (lots of ideological grassroots industry), though a lot more public policy activism than the Free Software movement. On the service side, the microcredit movement could be viewed as an example of this.
Since the manufacturer (ex: Tivo) is actually making the device, the doctrine of first sale is irrelevant.
It is irrelevant to the specific scenario currently used by TiVo. But it is quite easy to conceive a system whereby no legal person who was doing anything requiring a copyright license to GPL software was creating a locked-down product, and yet a locked down product containing GPL software was the end product. It just requires contracting out for the production of the module containing the software (the module itself wouldn't be locked down) and then physically modifying it to make it locked down. The GPLv3 is very narrowly crafted to attack the specific way TiVo was making locked down products, but doesn't (and as a copyright license really can't) do much to stop locked down products using GPL software from being made.
No matter how many times the software changes hands and you have to step up the ladder to find the original source, somewhere a derived work was made, and at that point of distribution the terms of the GPL apply.
Right. So whoever makes the derivative work and distributes copies of it can't incorporate it in a locked down product with a foreseeable consumer use. The person to whom they supply the module containing a copy of that derivative work (perhaps under an exclusive contract), however, can.
This seems to imply that all GPLv3 would need to do is to forbid the transfer of GPL software onto any device that doesn't allow running modified versions of the software.
No, because physical module could be made which is not locked down (and which allows changes) that is then sold to a third party and either (a) incorporated (no software transfer, the physical module is hardwired into a larger device) into another device which does not allow changes, or (b) physically modified to remove the functionality which allows changes. Then the resulting product is sold to the public. Presumably, the company contracting out to have the modules made would contract to be the exclusive recipient.
At no point is there any software copying into a locked-down device, or even by anyone who produces and sells a locked down device.
Is the attribution requirement of the BSD license really a GPL killer?
If you mean the requirement to retain the original copyright notice, yes, that and the requirement to include, verbatim, the BSD conditions and disclaimers make it impossible to comply with the BSD license and the GPLv2 (which has differently worded disclaimers and different copyright notice terms and specifically forbids additional restrictions) and the BSD license simultaneous.
The GPLv3 is written specifically to allow the BSD license terms (and those of other similarly-written licenses) to be included as Section 7 additional terms.
Maybe someone from the BSD camp could jump in and explain (without more flaming, it's an honest question). Assuming the BSD is as permissive as I'd always understood (or misunderstood) it to be how does the redistribution clauses work?
Any redistribution must include the BSD license terms. It may include additional terms, as well. Redistribution can be in source or binary form, and the BSD terms do not (though additional terms added by a redistributor may) require making source available.
The BSD terms can be included as Section 7 additional terms with the GPLv3.
Which would require all subsequent work to either remain BSD or dual license with BSD (opening commercial projects which include code written under the BSD to be redistributable):
Derivative works must be either BSD or BSD (+other restrictions). Dual-licensing (unless the options are BSD and BSD+) doesn't seem to be kosher (for redistributors of software that came to them under the BSD; clearly, the original copyright holder can offer as many licensing alternatives as he wants, even if they are mutually incompatible.)
The GPL(v3 and probably earlier) version of originally BSD-licensed code would necessarily contain the BSD copyright notices (as you pointed out) as an additional term (see section 7b) plus the standard GPL license stuff, none of which you would be allowed to remove if you intended to redistribute.
The GPLv2 specifically forbids additional terms, and, therefore, the BSD license is incompatible with it.
The GPLv3 allows certain additional terms. Some of the categories were, IIRC, designed specifically to allow BSD-licensed software to be incorporated into GPL software without violating either license. So the BSD license is compatible with the GPLv3 by incoporating its terms as Section 7 additional terms with the GPL.
The BSD is, from reading the licenses, incompatible with the GPLv2 but not the GPLv3, provided the BSD-required terms are included along with the GPL terms. The BSD license has specific requirements as to copyright notice, conditions that must be included, and disclaimers that must be included. The GPL has different provisions in each of those areas, its included disclaimers are similar in effect but different in language, and it copyright notice provisions are substantially different and do not require preservation of the original notice. Further, the GPL allows terms (the "or any later version" clause) which would allow redistribution under unknown future terms that might delete, rather than merely add, terms to those existing. The BSD license would seem open to additional terms on derived works, but doesn't allow deleting terms. The GPLv2 specifically excludes additional terms (so the BSD terms cannot be imposed along with the GPL terms), where the GPLv3 allows additional terms of the type necessary to accommodate the BSD license. The BSD license appears to be compatible with the GPLv3 so long as all of the BSD terms are incorporated as Section 7 additional terms along with the GPLv3. There may be additional problems with using "or any later version" even in the GPLv3.
Anyone can take BSD code, change it however they desire, and they don't have to give anything back if they don't want to.
They don't have to release source code.
They do have to include the original copyright notice, the BSD conditions, and the BSD disclaimer along with any derivative work, whether in source or binary form.
The altered code can then be used in a closed source proprietary product if desired.
That's true. It can't, however, be released without the original copyright notice, the BSD conditions, and the BSD disclaimer. Even if such a release is under a license that includes, among other terms, substantively similar (by different in wording) terms to the conditions and disclaimer required by the BSD license except for the copyright notice condition, and a similar but substantially different copyright notice provision.
If Theo didn't want people copying his code and redistributing it under another license, he should have used the GPL...
If Theo didn't want people copying his code and redistributing under the GPL without the original copyright notice, conditions, and disclaimers, he should have used another license which requires its conditions and disclaimers and the original copyright notice be included with any modified source or binary version, so that it's just as viral as the GPL despite being more friendly to additional terms on derivative works.
someone who writes code under BSD licence knows that this could be used for commercial projects without returning ANY source at all. one could argue that thus wirting code under BSD licence is stupid in the first place. but why do these people complain when someone uses it under GPL if they would even allow use it for bloody comercial, binary only products?
In general, because if its released under the BSD license only (which, apparently, may not actually be the case here), you can't release it under the GPL alone without the BSD conditions and copyright notice without violating the terms of the BSD license. You could release a binary-only modified version as part of commercial software, but you still must include the original copyright notice, BSD conditions, and disclaimer.
The BSD license does not prevent derivative works from being distributed with additional terms, even GPL-like terms. But, while the FSF claims that the BSD license without the advertising clause is "GPL compatible", that's far from clearly true. The required disclaimers in the GPL are similar in effect but different in language to those in the BSD license, and the BSD license strictly requires that the BSD disclaimers and conditions being included with copies or derivatives (whether in source or binary form): it is, in that respect, as viral as the GPL in the "stickyness" of its conditions to code, its just imposes fewer restrictions with its conditions. Of course, the FSF has an incentive to claim that the license is compatible, since that encourages people to rely on that declaration and take BSD-licensed code, modify it, and release the resulting code under the GPL alone. But, unless you include both the GPL and BSD conditions and disclaimers with such code, you would seem to violate the BSD license at least technically (since the substance of the GPLv2 and even GPLv3 seem to be almost entirely compatible with the BSD license to the extent that the substantive terms could be imposed on a BSD derivative work [the GPL copyright notice requires an "appropriate" copyright notice, while the BSD license requires retaining the original copyright notice, which is an incompatibility], this is probably largely a harmless kind of violation unless the "or any later version" clause is used in a work relicensed under the GPL alone; as there is no guarantee that a future GPL derivative would be even remotely compatible with the BSD license, however, use of the "or any later version" clause in the GPL without also including the BSD conditions would be a more dangerous violation.)
In short, people have every right to object to people stripping the BSD conditions from BSD licensed software to release it (without any legal right to do so) under the GPL even if they wouldn't complain if people did commercial, binary-only releases that included the BSD conditions and disclaimers and, therefore, did not violate the license.
I don't think you can; for one thing, the Free Software movement is hardly even "close to unique" among social movements in making real products on the scale it does.
Care to name some?
Off the top of my head, and without expressing any particular judgements as to the moral worth of any of the involved movements, a few obvious examples would include the workplace democracy/labor cooperative movement (which was mentioned in the post you were responding to as such an example), the organic foods movement, various communist and socialist movements worldwide, many religious movements (mostly, in many cases, producing services and other intangible but real products, but then software isn't exactly heavy industry, either), etc.
If "Tivoization" is allowed, anyone can just burn their proprietary code into hardware, and avoid the effect of GPL2.
The GPLv3 still allows this, as long as the person burning the GPL-covered code into hardware and the person incorporating that bit of hardware into a device which is, as a whole, locked down aren't the same person.
And no GPL-like license could stop that, since all it relies on rights outside the control of the copyright holder under the doctrine of first sale: you'd have to have something like a sales contract that had to be accepted as a condition of receiving the software rather than an optional gratuitous copyright license to do that, and that would tend to be at odds with other values the FSF espouses.
if you distribute hardware that runs GPL'd software (whatever, call it firmware), then you are also distributing that software and you have to follow the terms of the GPL.
At least in the US, under the doctrine of first sale and 17 USC Section 109, as long as you are distributing a physical copy you have lawfully received (not making a copy or derivative work) you don't need permission of the copyright holder to do so, so the terms of an offered gratuitous copyright license (like the GPL) don't restrict you because you don't need a license to distribute in the first place.
This is in direct contradiction to your interpretation, since it expressly specifies that in order to distribute you need a license.
What the GPL says about distribution is irrelevant, because the doctrine of first sale (applicable in US copyright law but not in all other jurisdictions) means you are free to transfer possession, ownership, and the right to use physical copies of copyright-protected items you receive (but not rent, lease, or lend them, generally) without a copyright license. If the GPL were a sales contract that were accepted prior to taking possession of a GPL-protected work rather than a gratuitous copyright license (which is both how it is mostly used in practice--though it sometimes used as if it were an EULA in binary distributions--and what the FSF itself claims the GPL is exclusively), of course, a declaration that it applied to redistribution of the physical copy you received under the contract would potentially be enforceable even if no copyright license were normally required. But since the right involved is not a protected exclusive right under copyright (at least in US law), no copyright license is necessary to exercise the right, and a limitation in an offered copyright license has no effect on your ability to exercise the right.
This principle is codified in US statute law at 17 U.S.C. 109.
Either the GPL is flat wrong when it says that those actions are prohibited by law, or your interpretation of what copyright means is wrong.
The GPL is either wrong as a description of US law (it may be a correct statement of the law in some other jurisdiction in which the GPL is used) or it is referring to distributing copies of the program other than the original physical copy you received.
You talk about a license that is more free, but the GPL is about giving the freedom to the person who obtains your software under the GPL.
No, its about giving those "freedoms" the FSF deems important to the person that obtains your software without needing to worry about the GPL. It does so by restricting those who use it under (i.e., subject to the restrictions of) the GPL, which only applies to copying or creating derivative works. The GPL is not a sales contract or EULA and a recipient or user of your software that is distributed along with the GPL as the offered license terms does not "obtain your software under the GPL".
The BSD license (and similar licenses) are about giving freedom to those using software under the license, and they do so at the cost (compared to the GPL) of reduced control over what "freedom" those users will choose to give to other users to whom they distribute new copies or derivative works.
I think you can consider that Richard is the leading philosopher of a social movement that is close to unique in that it makes real products, and in large scale.
I don't think you can; for one thing, the Free Software movement is hardly even "close to unique" among social movements in making real products on the scale it does. Its also debatable how many products are made by the movement versus how many are made by people who merely accede to (or exploit) the terms offered by the movement, rather than having any ideological affiliation with it, but then that's equally true of other social movements (like, say, the workplace democracy/labor cooperative movement, which also engages in industry on a substantial scale.)
The philosophy was critically important to the folks who did the actual production
Excluding, quite visibly, Linus Torvalds, and quite likely a very large number of others that are doing the "actual production" of Free Software.
Slashdot Mirror
Any code, regardless of licensing conditions, can be mixed, the problem that comes up is the legality, particularly of distribution. The problem with the GPLv2 and the BSD license is that, if your upstream code is under those licenses, there are no legal terms that you are authorized to distribute the combined work under. If you don't include the BSD-required terms, you violate the BSD license. If you include the BSD terms and the GPLv2 terms, you violate the GPLv2 license, which specifically prohibits adding any additional terms to the GPLv2 terms. If you omit the GPLv2 terms, you violate the GPLv2 again. In either case, since you cannot comply with at least one of the necessary licenses, any distribution is a violation of copyright law.
Please provide a quantitative definition of "largely" and evidence that this is true for any significant number of the common Linux distributions.
Even granting, arguendo, that the "entire set of software on top of the kernel" on any popular Linux distribution was from the GNU project (which is rather emphatic not the case for any actual popular Linux distribution), the fact remains that the product as a whole is not the GNU OS, because, whatever is on top of the kernely, the kernel is not the GNU kernel. Its a different OS sharing components.
Perhaps. But then...
You just contradicted yourself, in one hand pointing to free alternatives to GNU that could be used with the Linux kernel, and in the next saying that this is impossible.
At any point, all that's irrelevant to what I said. I never said that Linux distributions weren't Unix-like largely because they incorporated tools from the GNU project. Nor did I say that using the Linux kernel was the only way a Unix-like OS could be built incorporating GNU tools. So I'm not sure why you've spent so much effort making these points, which don't contradict anything I've said.
All I've said is that none of the various Linux distributions are not an operating system created by the GNU project, they are operating systems that incorporate GNU tools with the Linux kernel. And you've provided no reason to believe anything differently.
I am aware that the FSF considers that to be the case. I am also aware that the FSF has an ideological interest in people relicensing code under the GPL, and is hardly a neutral expert on the matter. Now, I'm not saying that the BSD is definitively incompatible with the GPLv2, but it seems pretty strongly on its face to be.
If you mix GPL and BSD code and distribute derived works, it is a copyright violation of at least one of the upstream works if the two license are not compatible "in a strict licensing context".
That's a problem for people for whom GPL violations, theoretical or actual, are a serious ideological concern, rather than a legal concern only where the GPL actually applies. I would suggests that the developers, maintainers, and distributers of xBSD operating systems do not, as a rule, fall into that category.
No, the RMS position is not that, since Linux is not the OS developed by the GNU project. It is an OS that's common feature is the Linux kernel; as usually distributed, it includes various tools from the GNU project. The RMS position is, roughly, "The GNU System is an OS developed by the GNU Project, and therefore every project that incorporates any components from that system is also morally obligated to include 'GNU' in the name of there product, even though they have express written permission to distribute the product without doing so."
But even that's not exactly right, because this argument is only applied to Linux, not to other products that incorporate GNU tools.
The GNU project's own OS doesn't have a general release yet, though its been coming Real Soon Now for my entire adult life.
Actually, that is, properly speaking, "the GPL position", since the GPL does not have any provision requiring adhering to upstream naming conventions or request. If the GNU project had wanted to make that a condition of distribution, they ought to have incorporated it into the license under which they authorized people to redistribute their code and create derivative works.
Complaining about people doing something you've given them express, written legal permission to do is somewhat childish, especially when you've (since you began complaining) revised the legal terms offered more than once without addressing the thing you keep complaining about.
The GNU project may or may not have written an operating system, but Linux isn't it. An operating system is more than a kernel, but a kernel is an indispensable portion of the operating system. Using some OS components GNU developed and some other OS components doesn't make the result the same OS GNU developed. Its something else. Distributors are free to call it things that highlight the kernel by including its name ("Red Hat Enterprise Linux"), things that evoke the name of the kernel without actually using it exactly ("Lindows"), or things that don't mention the kernel at all ("Knoppix"). They could do the same thing with the GNU toolchain. The fact that none of the distributors wan't to label the OS in a way that highlights the GNU toolchain may be disappointing to the members of the GNU project, but since they've expressly (and repeatedly, given the revisions to the GPL) given distributors permission to do exactly what they are doing, they don't really have any leg to stand on in complaining about it.
Evidence isn't at issue; this is a complaint, evidence hadn't even been presented yet. What this ruling says is that they didn't make specific enough allegations to even have a complaint that the defendant was obligated to respond to.
Its not a criminal case, but a civil one so "crime" is mostly irrelevant. This isn't about proof, either. This is about the degree of specificity required in the allegations in the original filing for there even to be a case.
Outsourcing a component? A lot of work?
This is following the terms of the GPL, though perhaps not the FSF's vision for it.
I believe not; the conditions that must be included restrict distribution (requiring any distribution to include the appropriate terms, disclaimers, and notices), and additional terms (including ones prohibiting redistribution) can be imposed.
That's certainly not true, in many cases, of the religious movements, where the particular goods and services produced are often (though not always exclusively) those central to the ideological mission of the movement, rather than merely instrumental to the economic life of the movement. OTOH, even granting that that's a valid difference, that's not the respect in which Free Software was originally held out as "almost unique". I'll agree that the Free Software movement (along with the organic foods movement) is at least distinct (though, still, I think far from unique) in being a movememt that is about a particular kind of product where the major form of activism is directly producing and/or consuming the product (there are plenty of other movements that produce goods and services, and plenty of other movements that are about goods and services, but not so many that combine both.)
The alternative fuels movement has some features of this (lots of ideological grassroots industry), though a lot more public policy activism than the Free Software movement. On the service side, the microcredit movement could be viewed as an example of this.
It is irrelevant to the specific scenario currently used by TiVo. But it is quite easy to conceive a system whereby no legal person who was doing anything requiring a copyright license to GPL software was creating a locked-down product, and yet a locked down product containing GPL software was the end product. It just requires contracting out for the production of the module containing the software (the module itself wouldn't be locked down) and then physically modifying it to make it locked down. The GPLv3 is very narrowly crafted to attack the specific way TiVo was making locked down products, but doesn't (and as a copyright license really can't) do much to stop locked down products using GPL software from being made.
Right. So whoever makes the derivative work and distributes copies of it can't incorporate it in a locked down product with a foreseeable consumer use. The person to whom they supply the module containing a copy of that derivative work (perhaps under an exclusive contract), however, can.
No, because physical module could be made which is not locked down (and which allows changes) that is then sold to a third party and either (a) incorporated (no software transfer, the physical module is hardwired into a larger device) into another device which does not allow changes, or (b) physically modified to remove the functionality which allows changes. Then the resulting product is sold to the public. Presumably, the company contracting out to have the modules made would contract to be the exclusive recipient.
At no point is there any software copying into a locked-down device, or even by anyone who produces and sells a locked down device.
If you mean the requirement to retain the original copyright notice, yes, that and the requirement to include, verbatim, the BSD conditions and disclaimers make it impossible to comply with the BSD license and the GPLv2 (which has differently worded disclaimers and different copyright notice terms and specifically forbids additional restrictions) and the BSD license simultaneous.
The GPLv3 is written specifically to allow the BSD license terms (and those of other similarly-written licenses) to be included as Section 7 additional terms.
Any redistribution must include the BSD license terms. It may include additional terms, as well. Redistribution can be in source or binary form, and the BSD terms do not (though additional terms added by a redistributor may) require making source available.
The BSD terms can be included as Section 7 additional terms with the GPLv3.
Derivative works must be either BSD or BSD (+other restrictions). Dual-licensing (unless the options are BSD and BSD+) doesn't seem to be kosher (for redistributors of software that came to them under the BSD; clearly, the original copyright holder can offer as many licensing alternatives as he wants, even if they are mutually incompatible.)
The GPLv2 specifically forbids additional terms, and, therefore, the BSD license is incompatible with it.
The GPLv3 allows certain additional terms. Some of the categories were, IIRC, designed specifically to allow BSD-licensed software to be incorporated into GPL software without violating either license. So the BSD license is compatible with the GPLv3 by incoporating its terms as Section 7 additional terms with the GPL.
The BSD is, from reading the licenses, incompatible with the GPLv2 but not the GPLv3, provided the BSD-required terms are included along with the GPL terms. The BSD license has specific requirements as to copyright notice, conditions that must be included, and disclaimers that must be included. The GPL has different provisions in each of those areas, its included disclaimers are similar in effect but different in language, and it copyright notice provisions are substantially different and do not require preservation of the original notice. Further, the GPL allows terms (the "or any later version" clause) which would allow redistribution under unknown future terms that might delete, rather than merely add, terms to those existing. The BSD license would seem open to additional terms on derived works, but doesn't allow deleting terms. The GPLv2 specifically excludes additional terms (so the BSD terms cannot be imposed along with the GPL terms), where the GPLv3 allows additional terms of the type necessary to accommodate the BSD license. The BSD license appears to be compatible with the GPLv3 so long as all of the BSD terms are incorporated as Section 7 additional terms along with the GPLv3. There may be additional problems with using "or any later version" even in the GPLv3.
They don't have to release source code.
They do have to include the original copyright notice, the BSD conditions, and the BSD disclaimer along with any derivative work, whether in source or binary form.
That's true. It can't, however, be released without the original copyright notice, the BSD conditions, and the BSD disclaimer. Even if such a release is under a license that includes, among other terms, substantively similar (by different in wording) terms to the conditions and disclaimer required by the BSD license except for the copyright notice condition, and a similar but substantially different copyright notice provision.
Like, for instance, the GPL.
If Theo didn't want people copying his code and redistributing under the GPL without the original copyright notice, conditions, and disclaimers, he should have used another license which requires its conditions and disclaimers and the original copyright notice be included with any modified source or binary version, so that it's just as viral as the GPL despite being more friendly to additional terms on derivative works.
Something like, I dunno, maybe the BSD license.
In general, because if its released under the BSD license only (which, apparently, may not actually be the case here), you can't release it under the GPL alone without the BSD conditions and copyright notice without violating the terms of the BSD license. You could release a binary-only modified version as part of commercial software, but you still must include the original copyright notice, BSD conditions, and disclaimer.
The BSD license does not prevent derivative works from being distributed with additional terms, even GPL-like terms. But, while the FSF claims that the BSD license without the advertising clause is "GPL compatible", that's far from clearly true. The required disclaimers in the GPL are similar in effect but different in language to those in the BSD license, and the BSD license strictly requires that the BSD disclaimers and conditions being included with copies or derivatives (whether in source or binary form): it is, in that respect, as viral as the GPL in the "stickyness" of its conditions to code, its just imposes fewer restrictions with its conditions. Of course, the FSF has an incentive to claim that the license is compatible, since that encourages people to rely on that declaration and take BSD-licensed code, modify it, and release the resulting code under the GPL alone. But, unless you include both the GPL and BSD conditions and disclaimers with such code, you would seem to violate the BSD license at least technically (since the substance of the GPLv2 and even GPLv3 seem to be almost entirely compatible with the BSD license to the extent that the substantive terms could be imposed on a BSD derivative work [the GPL copyright notice requires an "appropriate" copyright notice, while the BSD license requires retaining the original copyright notice, which is an incompatibility], this is probably largely a harmless kind of violation unless the "or any later version" clause is used in a work relicensed under the GPL alone; as there is no guarantee that a future GPL derivative would be even remotely compatible with the BSD license, however, use of the "or any later version" clause in the GPL without also including the BSD conditions would be a more dangerous violation.)
In short, people have every right to object to people stripping the BSD conditions from BSD licensed software to release it (without any legal right to do so) under the GPL even if they wouldn't complain if people did commercial, binary-only releases that included the BSD conditions and disclaimers and, therefore, did not violate the license.
Off the top of my head, and without expressing any particular judgements as to the moral worth of any of the involved movements, a few obvious examples would include the workplace democracy/labor cooperative movement (which was mentioned in the post you were responding to as such an example), the organic foods movement, various communist and socialist movements worldwide, many religious movements (mostly, in many cases, producing services and other intangible but real products, but then software isn't exactly heavy industry, either), etc.
The GPLv3 still allows this, as long as the person burning the GPL-covered code into hardware and the person incorporating that bit of hardware into a device which is, as a whole, locked down aren't the same person.
And no GPL-like license could stop that, since all it relies on rights outside the control of the copyright holder under the doctrine of first sale: you'd have to have something like a sales contract that had to be accepted as a condition of receiving the software rather than an optional gratuitous copyright license to do that, and that would tend to be at odds with other values the FSF espouses.
At least in the US, under the doctrine of first sale and 17 USC Section 109, as long as you are distributing a physical copy you have lawfully received (not making a copy or derivative work) you don't need permission of the copyright holder to do so, so the terms of an offered gratuitous copyright license (like the GPL) don't restrict you because you don't need a license to distribute in the first place.
What the GPL says about distribution is irrelevant, because the doctrine of first sale (applicable in US copyright law but not in all other jurisdictions) means you are free to transfer possession, ownership, and the right to use physical copies of copyright-protected items you receive (but not rent, lease, or lend them, generally) without a copyright license. If the GPL were a sales contract that were accepted prior to taking possession of a GPL-protected work rather than a gratuitous copyright license (which is both how it is mostly used in practice--though it sometimes used as if it were an EULA in binary distributions--and what the FSF itself claims the GPL is exclusively), of course, a declaration that it applied to redistribution of the physical copy you received under the contract would potentially be enforceable even if no copyright license were normally required. But since the right involved is not a protected exclusive right under copyright (at least in US law), no copyright license is necessary to exercise the right, and a limitation in an offered copyright license has no effect on your ability to exercise the right.
This principle is codified in US statute law at 17 U.S.C. 109.
The GPL is either wrong as a description of US law (it may be a correct statement of the law in some other jurisdiction in which the GPL is used) or it is referring to distributing copies of the program other than the original physical copy you received.
No, its about giving those "freedoms" the FSF deems important to the person that obtains your software without needing to worry about the GPL. It does so by restricting those who use it under (i.e., subject to the restrictions of) the GPL, which only applies to copying or creating derivative works. The GPL is not a sales contract or EULA and a recipient or user of your software that is distributed along with the GPL as the offered license terms does not "obtain your software under the GPL".
The BSD license (and similar licenses) are about giving freedom to those using software under the license, and they do so at the cost (compared to the GPL) of reduced control over what "freedom" those users will choose to give to other users to whom they distribute new copies or derivative works.
I don't think you can; for one thing, the Free Software movement is hardly even "close to unique" among social movements in making real products on the scale it does. Its also debatable how many products are made by the movement versus how many are made by people who merely accede to (or exploit) the terms offered by the movement, rather than having any ideological affiliation with it, but then that's equally true of other social movements (like, say, the workplace democracy/labor cooperative movement, which also engages in industry on a substantial scale.)
Excluding, quite visibly, Linus Torvalds, and quite likely a very large number of others that are doing the "actual production" of Free Software.