Where did this “you are permanently barred from distributing” stuff originate? In digging around, I found a post titled “A Practical Guide to GPL Compliance” at the Software Freedom Law Center dated August 26, 2008, written by the team of Bradley M. Kuhn, Aaron Williamson and Karen M. Sandler. It states, in part, that “if you have redistributed an application under GPLv2, but have violated the terms of GPLv2, you must request a reinstatement of rights from the copyright holders before making further distributions, or else cease distribution and modification of the software forever.”
Hi Barbara,
I am the original author of Busybox, and the one who applied the GPL license to it. I am not, however, the person who brings the lawsuits - that's a later developer who chose not to involve me. So, I consult to corporations and law firms and help them bring their infringing devices into compliance with the license on Busybox and other Open Source / Free Software. My customers are about half-and-half parties that already have settlements with the Software Freedom Conservancy, and terms they must fulfill post-settlement, and parties that haven't yet been sued but have an infringement to pre-emptively remedy in order to avoid being sued. Helping them come into compliance with my license on my software is nicer than suing them, and achieves the same result. I might even make more than the folks behind the suit.
The GPL infringement situation is a complex one. First, it's important to realize that if a company is infringing the Busybox license, they have completely failed to exercise due diligence. Since Busybox is a separate executable program from their proprietary software, complying with the GPL doesn't mean distributing any of their proprietary work. So, why didn't they comply? Because they had no process for compliance in their company and never even checked if they had to. Surprisingly, even the planet's largest companies, with the most to lose, have failed to exercise due diligence this way.
In general, the infringement starts with a third-party company that sells a manufacturer a design incorporating GPL software, perhaps along with an ASIC (application-specific integrated circuit) that is part of the design. Usually the device runs Linux.
In the case of private-label companies, like the Insignia brand of Best Buy (not my customer) they buy entire assembly-line runs from (usually) no-name manufacturers. These are marketed as the store brand, but the store might have no access to the engineers who designed the product. Good luck to folks like that when it's discovered that the product is in infringement. I could get them out of the situation, but only by building entirely new (and compliant) firmware for the device.
It is often the case that it takes months for the company to be able to come into technical compliance, or they may never be able to do so because they have no access to the engineers who had the source code any longer. So, whether or not they can resume distributing as soon as they are in compliance, without permission from Software Freedom Conservancy and their client might not be terribly relevant.
Another complexity for them is that they are often also infringing on other LGPL or GPL software. Sometimes, they have static linked proprietary software to uClibc. If they've done that, they've created an untenable situation regarding their own proprietary software, and often the proprietary software of third parties. Then, their main concern is getting formal forgiveness for infringement so that they don't have to distribute their proprietary software under the GPL. Consider how often modern devices contain proprietary software belonging to third parties like content providers. If you've linked that to GPL software, or static-linked it to LGPL software, infringing the GPL is no longer your main concern. The folks who make the proprietary software are after you as well, and you had a real contract with them, and they want real money. They can prevent you from making certain kinds of products forever because you've broken their contract. Again, the fact that you might be able to resume distribution without negotiating with the Software Freedom Conservancy and their client isn't terribly relevant.
But if your situation isn't so complex, can you resume distribution as soon as you come into compliance, without a settlement? You can't tell us, Barbara. A judge can, but none has had the reason to do so, so far. Until then, most violating companies with any sense are settling with the Software Freedom Conservancy, because the conservancy doesn't actually ask for much money. They just want you to be in compliance.
The Software Freedom Conservancy's settlement terms are much, much less than what would be reasonable, really only a token amount, and the engineering costs they charge for checking your compliance are substantially less than most professional engineers would charge for similar consulting. And they give you an exit from the infringement situation, in writing. They require you to put a compliance process in place, but you needed that anyway to keep out of trouble. So, working with the Software Freedom Conservancy is usually much cheaper than attempting to avoid them and having doubt about the legality of your product forever.
I doubt you'll see a response from Software Freedom Conservancy. Your last email to them sounds like baiting for your own purposes. And forgive me for saying so, but arguments with non-experts about this sort of topic are rarely productive. I can't see why SFC would want to extend the dialogue.
The central issue is whether license terminations are permanent. If not, then the FSF and SFLC were engaging in FUD.
So, when you wrote:
"Again, the fact that you might be able to resume distribution without negotiating with the Software Freedom Conservancy and their client isn't terribly relevant."
.. you were, like so many other times this week, evading the real issues.
If the ONLY requirement to resume distribution is to download a new copy of the code and receive and comply with the new license so granted, then the FSF was definitely engaging in FUD when they attacked Android over Linux being GPLv2 only.
They were claiming license terminations were permanent, because they willfully overlooked the granting of a new license under section 6 of the GPL ... and remember, in contracts of adhesion like the GPL, the courts are required to uniformly construe all the terms in favor of the recipient of the license.
For devices that are being imported, the ONLY question is whether the code is in compliance at the time of import, since the ITC makes their determination action based on that. Actions outside the country of import are outside their jurisdiction (See Microsoft vs AT&T).
So, back to our example of a license that was terminated for not shipping the source; they can resume importing if they can get a new license and comply with it - and since they *can* get a new license just by downloading a new copy of the program, that ends that. ALL their devices can now be imported. Both the FSF and the SFLC were in error.
In such cases the manufacturer doesn't have to rip ASICs out, or reprogram FPGAs. No "negotiations" or "agreeing to compliance actions". No payments of "compliance costs."
Of course, they might also decide that next time, it's safer to just use BSD. After all, if it's good enough for Apple ...
BTW, your "new covenant license"? It's really just a rehash of the same old, same old "covenant" from your failed kiloboot project.
"We require copyright assignment to accept modifications to our software. This is necessary so that we can vend a commercial license. Unlike almost everyone else who requires copyright assignment, we covenant with the developer to continue to make an Open Source version of their contribution available as long as we (or our assigns) continue to develop our commercial version. This provides a fair quid-pro-quo for the contributor. Of course, the main incentive for contributing a modification that you have made to our products is that we'll maintain it as part of our main code tree, and you won't have to."
The wayback machine dates it to at least February 2008. That's not "new". It's also disrespectful of the rights of programmers.
FSF's Star Turn in the Android FUDathon, Part 3
Posted by: Barbara Hudson September 8, 2011 09:01 AMWhere did this “you are permanently barred from distributing” stuff originate? In digging around, I found a post titled “A Practical Guide to GPL Compliance” at the Software Freedom Law Center dated August 26, 2008, written by the team of Bradley M. Kuhn, Aaron Williamson and Karen M. Sandler. It states, in part, that “if you have redistributed an application under GPLv2, but have violated the terms of GPLv2, you must request a reinstatement of rights from the copyright holders before making further distributions, or else cease distribution and modification of the software forever.”
I am the original author of Busybox, and the one who applied the GPL license to it. I am not, however, the person who brings the lawsuits - that's a later developer who chose not to involve me. So, I consult to corporations and law firms and help them bring their infringing devices into compliance with the license on Busybox and other Open Source / Free Software. My customers are about half-and-half parties that already have settlements with the Software Freedom Conservancy, and terms they must fulfill post-settlement, and parties that haven't yet been sued but have an infringement to pre-emptively remedy in order to avoid being sued. Helping them come into compliance with my license on my software is nicer than suing them, and achieves the same result. I might even make more than the folks behind the suit.
The GPL infringement situation is a complex one. First, it's important to realize that if a company is infringing the Busybox license, they have completely failed to exercise due diligence. Since Busybox is a separate executable program from their proprietary software, complying with the GPL doesn't mean distributing any of their proprietary work. So, why didn't they comply? Because they had no process for compliance in their company and never even checked if they had to. Surprisingly, even the planet's largest companies, with the most to lose, have failed to exercise due diligence this way.
In general, the infringement starts with a third-party company that sells a manufacturer a design incorporating GPL software, perhaps along with an ASIC (application-specific integrated circuit) that is part of the design. Usually the device runs Linux.
In the case of private-label companies, like the Insignia brand of Best Buy (not my customer) they buy entire assembly-line runs from (usually) no-name manufacturers. These are marketed as the store brand, but the store might have no access to the engineers who designed the product. Good luck to folks like that when it's discovered that the product is in infringement. I could get them out of the situation, but only by building entirely new (and compliant) firmware for the device.
It is often the case that it takes months for the company to be able to come into technical compliance, or they may never be able to do so because they have no access to the engineers who had the source code any longer. So, whether or not they can resume distributing as soon as they are in compliance, without permission from Software Freedom Conservancy and their client might not be terribly relevant.
Another complexity for them is that they are often also infringing on other LGPL or GPL software. Sometimes, they have static linked proprietary software to uClibc. If they've done that, they've created an untenable situation regarding their own proprietary software, and often the proprietary software of third parties. Then, their main concern is getting formal forgiveness for infringement so that they don't have to distribute their proprietary software under the GPL. Consider how often modern devices contain proprietary software belonging to third parties like content providers. If you've linked that to GPL software, or static-linked it to LGPL software, infringing the GPL is no longer your main concern. The folks who make the proprietary software are after you as well, and you had a real contract with them, and they want real money. They can prevent you from making certain kinds of products forever because you've broken their contract. Again, the fact that you might be able to resume distribution without negotiating with the Software Freedom Conservancy and their client isn't terribly relevant.
But if your situation isn't so complex, can you resume distribution as soon as you come into compliance, without a settlement? You can't tell us, Barbara. A judge can, but none has had the reason to do so, so far. Until then, most violating companies with any sense are settling with the Software Freedom Conservancy, because the conservancy doesn't actually ask for much money. They just want you to be in compliance.
The Software Freedom Conservancy's settlement terms are much, much less than what would be reasonable, really only a token amount, and the engineering costs they charge for checking your compliance are substantially less than most professional engineers would charge for similar consulting. And they give you an exit from the infringement situation, in writing. They require you to put a compliance process in place, but you needed that anyway to keep out of trouble. So, working with the Software Freedom Conservancy is usually much cheaper than attempting to avoid them and having doubt about the legality of your product forever.
I doubt you'll see a response from Software Freedom Conservancy. Your last email to them sounds like baiting for your own purposes. And forgive me for saying so, but arguments with non-experts about this sort of topic are rarely productive. I can't see why SFC would want to extend the dialogue.
Thanks
Bruce Perens
So, when you wrote:
"Again, the fact that you might be able to resume distribution without negotiating with the Software Freedom Conservancy and their client isn't terribly relevant."
.. you were, like so many other times this week, evading the real issues.
If the ONLY requirement to resume distribution is to download a new copy of the code and receive and comply with the new license so granted, then the FSF was definitely engaging in FUD when they attacked Android over Linux being GPLv2 only.
They were claiming license terminations were permanent, because they willfully overlooked the granting of a new license under section 6 of the GPL ... and remember, in contracts of adhesion like the GPL, the courts are required to uniformly construe all the terms in favor of the recipient of the license.
For devices that are being imported, the ONLY question is whether the code is in compliance at the time of import, since the ITC makes their determination action based on that. Actions outside the country of import are outside their jurisdiction (See Microsoft vs AT&T).
So, back to our example of a license that was terminated for not shipping the source; they can resume importing if they can get a new license and comply with it - and since they *can* get a new license just by downloading a new copy of the program, that ends that. ALL their devices can now be imported. Both the FSF and the SFLC were in error.
In such cases the manufacturer doesn't have to rip ASICs out, or reprogram FPGAs. No "negotiations" or "agreeing to compliance actions". No payments of "compliance costs."
Of course, they might also decide that next time, it's safer to just use BSD. After all, if it's good enough for Apple ...
BTW, your "new covenant license"? It's really just a rehash of the same old, same old "covenant" from your failed kiloboot project.
"We require copyright assignment to accept modifications to our software. This is necessary so that we can vend a commercial license. Unlike almost everyone else who requires copyright assignment, we covenant with the developer to continue to make an Open Source version of their contribution available as long as we (or our assigns) continue to develop our commercial version. This provides a fair quid-pro-quo for the contributor. Of course, the main incentive for contributing a modification that you have made to our products is that we'll maintain it as part of our main code tree, and you won't have to."
The wayback machine dates it to at least February 2008. That's not "new". It's also disrespectful of the rights of programmers.
You really outdid yourself this week ...