|| ||"Bradley M. Kuhn" <bkuhn-AT-ebb.org> |
|| ||busybox-AT-busybox.net |
|| ||Re: Amusing article about busybox |
|| ||Wed, 08 Feb 2012 14:09:14 -0500|
|| ||Article, Thread
Matheus Izvekov wrote at 10:11 (EST) on Monday:
> The first is that I agree with Tim that suspending the license is a
> big issue for any company wishing to ship busybox, much more so if all
> of their other unrelated products are held hostage.
> Any litigation regarding busybox should remain
> confined to the offending product and the enforcement of busybox
> itself only.
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.
> A small list of things we (?) may want in return, in order of
> importance: 1) Code
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.
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.
> Does the product in question ship a patched busybox at all? Is
> there any reason to believe that?
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.
> Now, to see in which position this would put busybox, my question is,
> what has been gained so far from suing?
Note again that very very few enforcement actions involved litigation.
Of hundreds of enforcement actions, only about 17 were lawsuits. Most
enforcement is a more-or-less friendly conversation and assistance given
to help the company into compliance with the GPL.
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy
to post comments)