On Wed, Feb 8, 2012 at 5:09 PM, Bradley M. Kuhn <[email protected]> wrote: > As mentioned elsewhere in this thread, 99.999% of enforcement actions > never go to litigation, and Conservancy always allows and even > encourages the company to continue distributing the products out of > compliance, as long as the company is actively working to come into > compliance in a verifiable way. The goal is to convince the company to > be a compliant redistributor of GPL'd software, and demanding a stop of > shipment would not help toward that goal.
The problem here is not that you rarely use the 'big stick', but that you can use it at all. The license is not very clear about how far it can be suspended, and how can it be reinstated. The text can not be changed now for clarification because it's too complicated, too many copyright holders would have to be tracked and asked to consent to it. Next best thing is to assure potential adopters that we have a very lenient interpretation of the license, and give them reason to believe that using GPLed code is not as a huge liability as they are led to believe it is now, which I think is about what the position of the linux foundation is. > One of the important things to note is that, while GPL enforcement is > typically done *by* the upstream copyright holders, it is done *on > behalf* of the users who got the product with BusyBox in it. Most of > our violation reports come from frustrated users who found BusyBox in a > product that they bought. > > In the embedded market, the biggest problem is that the distributions of > BusyBox fail to include the "scripts to control compilation and > installation of the executable", which the GPLv2 requires. > > As such, users who wish to take a new upstream version of BusyBox and > install it on their device are left without any hope of doing so. Most > embedded-market GPL enforcement centers around remedying this. And this is a second problem I am seeing with the whole thing. The busybox copyright is being used to enforce a whole set of ideologies about 'platform hackability' that are not clearly implied in the license text and not every copyright holder agrees. The very fact that busybox positions itself as GPLv2 only and not 'or later' should be a very big clue here. > > Indeed, enforcement has brought some great successes in this regard. As > I wrote on in my blog post on this subject (at > http://sfconservancy.org/blog/2012/feb/01/gpl-enforcement/ ), both the > OpenWRT and SamyGo firmware modification communities were launched > because of source releases yielded in past BusyBox enforcement actions. > Getting the "scripts to control compilation and installation of the > executable" for those specific devices are what enabled these new > upstream firmware projects to get started. Again, don't think everyone is onboard with this idea of using busybox copyright to achieve this. While I very much would like that all these products were developed with the intent of making it easier to be hacked by the users, I don't think it's fair to require them to be so, and neither is the GPLv2 generally understood to require it. > This is hard to know when an enforcement actions begins; we don't > normally find out until the end, because, of course, initially, there's > no source to examine. Detailed and time-consuming analysis of the > binary would be the only way to determine that up-front. Not necessarily that hard to figure out. A lot can be gained from just seeing how it is being called, given that any modifications are probably going to be used, or else they wouldn't have any reason to modify the code in the first place. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
