A tempest in a toybox [LWN.net]

By Jonathan Corbet
February 1, 2012

The eLinux.org web site is currently promoting a project to write a replacement for Busybox under a permissive license. Normally, the writing of more free software is seen as a good thing, but, in this case, there have been complaints about the perceived motivation behind the project. What this discussion shows is that there are some divisions within our community on how our licenses should be enforced - and even what those licenses say.

One could imagine a number of reasons for wanting to rewrite Busybox. Over time, that package has grown to the point that it's not quite the minimal-footprint tool kit that it once was. Android-based systems can certainly benefit from the addition of Busybox, but the Android world tends to be allergic to GPL-licensed software; a non-GPL Busybox might even find a place in the standard Android distribution. But the project page makes another reason abundantly clear:

Busybox is arguably the most litigated piece of GPL software in the world. Unfortunately, it is unclear what the remedy should be when a GPL violation occurs with busybox. Litigants have sometimes requested remedies outside the scope of busybox itself, such as review authority over unrelated products, or right of refusal over non-busybox modules. This causes concern among chip vendors and suppliers.

What seems to be happening in particular is that the primary Busybox litigant - the Software Freedom Conservancy (SFC) - has taken the termination language in GPLv2 to mean that somebody who fails to comply with the license loses all rights to the relevant software, even after they fix their compliance problems. (See Android and the GPLv2 death penalty for more information on this interpretation of the license, which is not universally held). Under this interpretation, they are withholding the restoration of a license to use and distribute Busybox based on conditions that are not directly related to Busybox; among other things, they require compliance for all other free software products shipped by that company, including the Linux kernel.

Thus, according to Matthew Garrett:

The reason to replace Busybox isn't because they don't want to hand over the source to Busybox - it's because Busybox is being used as a proxy to obtain the source code for more interesting GPLed works. People want a Busybox replacement in order to make it easier to infringe the kernel's license.

There is some truth to the notion that, on its own, license enforcement for Busybox is not hugely interesting. Encouraging compliance with the GPL is a good thing, but, beyond that, there is little to be gained by prying the source for a Busybox distribution from a vendor's hands. There just isn't anything interesting being added to Busybox by those vendors. Rob Landley, who was once one of the Software Freedom Law Center's plaintiffs (before the enforcement work moved to the Software Freedom Conservancy) once wrote:

From a purely pragmatic perspective: I spent over a year doing busybox license enforcement, and a dozen lawsuits later I'm still unaware of a SINGLE LINE OF CODE added to the busybox repository as a result...

Rob has been working on the Toybox project, which happens to be the effort that would someday like to replace Busybox, since 2006.

So, beyond the generation of bad publicity for a violator and some cash for the litigants, Busybox enforcement on its own could perhaps be said to achieve relatively little for the community. But a vendor that can't be bothered to provide a tarball for an unmodified Busybox distribution is highly unlikely to have its act together with regard to other projects, starting with the kernel. And that vendor's kernel code can often be the key to understanding their hardware and supporting it in free software. So it is not surprising that a group engaging in GPL enforcement would insist on the release of the kernel source as well.

On its face, it does seem surprising that vendors would object to this requirement - unless they overtly wish to get away with GPL infringement. Tim Bird, who is promoting the Busybox replacement project, has stated that this is not the case. Instead, Tim says:

It is NOT the goal of this to help people violate the GPL, but rather to decrease the risk of some nuclear outcome, should a mistake be made somewhere in the supply chain for a product. For example, it is possible for a mistake made by an ODM (like providing the wrong busybox source version) could result in the recall of millions of unrelated products. As it stands, the demands made by the SFC in order to bring a company back into compliance are beyond the value that busybox provides to a company.

Mistakes do happen. Companies are often surprisingly unaware of where their code comes from or what version they may have shipped in a given product. Often, the initial violation comes from upstream suppliers, with the final vendor being entirely unaware that they are shipping GPL-licensed software at all. What is being claimed here is that SFC's demands are causing the consequences of any such mistakes to be more than companies are willing to risk.

What does the SFC require of infringers? The SFC demands, naturally enough, that the requirements of the GPL be met for the version of Busybox shipped by an infringer. There are also demands for an unknown amount of financial compensation, both to the SFC (The SFC's FY2010 IRS filings show just over $200,000 in revenue from legal settlements) and to the Busybox developer (Erik Andersen) that the SFC is representing. Then there are the demands for compliance for all other GPL-licensed products shipped by the vendor, demands that, it is alleged, extend to the source for binary-only kernel modules. The SFC also evidently demands that future products be submitted to them for a compliance audit before being shipped to customers.

Such demands may well be appropriate for habitual GPL infringers; they are, arguably, a heavy penalty for a mistake. Whether the cases filed by the SFC relate to habitual behavior or mistakes is not necessarily clear; there have been plenty of allegations either way. One person's mistake is another person's intentional abuse.

If Busybox is, for whatever reason, especially mistake-prone, then replacing it with a mistake-proof, BSD-licensed version might make sense. Not using the software at all is certainly a way to avoid infringing its license. What is a bit more surprising is that some developers are lamenting the potential loss of Busybox as a lever for the enforcement of conditions on the use of the kernel. There are a couple of concerns here:

The use of the GPL death penalty is worrisome, in that it gives any copyright holder extreme power over anybody who can be said to have infringed the license in any trivial way. Even if one is fully in agreement with the SFC's use of the termination clause, there are, beyond doubt, entities out there who would like to use it in ways that are not in the interests of the free software community.
One could argue that enforcement of the licenses for other software packages should be left up to the developers who wrote that code. They may have different ideas about how it should be done or even what compliance means. Any developer with copyrights in the kernel (or any other product) is entirely capable of going to the SFC if they want SFC-style enforcement of their rights.

For such a developer to go to the SFC is exactly what Matthew is asking for in his post. Thus far, despite a search for plaintiffs on the SFC's part, that has not happened. Why that might be is not entirely clear. Perhaps kernel developers are not comfortable with how the SFC goes about its business, or perhaps it's something else. It's worth noting that most kernel developers are employed by companies these days, with the result that much of their output is owned by their employers. For whatever reason, companies have shown remarkably little taste for GPL enforcement in any form, so a lot of kernel code is not available to be put into play in an enforcement action.

That last point is, arguably, a real flaw in the corporate-sponsored free software development model - at least, if the viability of copyleft licenses matters. The GPL, like almost any set of rules, will require occasional enforcement if its rules are to be respected; if corporations own the bulk of the code, and they are unwilling to be part of that enforcement effort, respect for the GPL will decrease. One could argue that scenario is exactly what is playing out now; one could also argue that it is causing Busybox, by virtue of being the only project for which active enforcement is happening, to be unfairly highlighted as the bad guy. If GPL enforcement were spread across a broader range of projects, it would be harder for companies to route around - unless, as some fear, that enforcement would drive companies away from GPL-licensed software altogether.

Situations like this one show that there is an increasing amount of frustration building in our community. Some vendors and some developers are clearly unhappy with how some license enforcement is being done, and they are taking action in response. But there is also a lot of anger over the blatant disregard for the requirements of the GPL at many companies; that, too, is inspiring people to act. There are a number of undesirable worst-case outcomes that could result. On one side, GPL infringement could reach a point where projects like the kernel are, for all practical effect, BSD-licensed. Or GPL enforcement could become so oppressive that vendors flee to code that is truly BSD licensed. Avoiding these outcomes will almost certainly require finding a way to enforce our licenses that most of us can agree with.

to post comments

A tempest in a toybox

Posted Feb 1, 2012 17:05 UTC (Wed) by Uraeus (guest, #33755) [Link] (6 responses)

I hope they do find some kernel devs willing to enforce their GPL rights, device makers need to understand that respecting the (L)GPL is just as important as respecting a proprietary license. I think we should try to be accommodating when companies makes what seems like honest mistakes and are making serious effort to remedy the situation, but regardless of what Tim Bird thinks here, the end result of busybox being replaced and no kernel developers filling the space is that device makers will stop caring about respecting open source licenses and just treat them all as MIT style licenses.

A tempest in a toybox

Posted Feb 1, 2012 18:33 UTC (Wed) by dlang (guest, #313) [Link] (5 responses)

you have obviously never heard of gpl-violations.org

they've been enforcing the GPL (including court cases) on the linux kernel for a long time.

A tempest in a toybox

Posted Feb 2, 2012 1:20 UTC (Thu) by rahvin (guest, #16953) [Link]

Of course gpl-violations operates out of Germany and only can litigate to products in Germany and is subject to German law. In effect meaning that they only have to comply with the license for products sold in Germany, and could in theory mean they only provide source to Germans.

A tempest in a toybox

Posted Feb 2, 2012 1:59 UTC (Thu) by rickmoen (subscriber, #6943) [Link] (3 responses)

Harald has ceased doing that work, for the foreseeable future, because his time is fully occupied writing a fully open-source GSM stack. That leaves approximately nobody, unfortunately. It's a real problem.

Rick Moen
rick@linuxmafia.com

A tempest in a toybox

Posted Feb 2, 2012 22:51 UTC (Thu) by armijn (subscriber, #3653) [Link]

As said in an earlier comment: this work has definitely *not* stopped :-)

A tempest in a toybox

Posted Feb 9, 2012 13:41 UTC (Thu) by landley (guest, #6789) [Link] (1 responses)

I've noticed that the people who really care about license enforcement are the people who've _stopped_ coding. Nobody else has time.

I offloaded BusyBox license enforcement onto a third party because Erik Andersen's old "hall of shame" was simultaneously useless and too much work, but the real action on enforcement happened _after_ I left BusyBox. Erik is the one still doing it, and he hasn't been involved with BusyBox since 2005.

Harald didn't have time to code while he was doing license enforcement, and stopped doing license enforcement again when he got busy coding.

As far as I can tell, the kernel guys can't be bothered beyond the occasional gripe in conference slides and mailing lists that binary only modules aren't kosher unless you actually ported a driver initially writen for another OS).

And of course The Failure of Open Source (http://lwn.net/Articles/475742) is all about license advocacy, and as far as I can tell the last new code he wrote is almost old enough to vote.

The people who write code can write _more_ code. We've reverse engineered everything from 3D video drivers to forcedeth:

http://lwn.net/Articles/191900/
http://liquidat.wordpress.com/2007/03/04/the-forcedeth-st...

(Neither reverse engineering nor license enforcement is fun, but which of the two is a programmer likely to be more comfortable with and better at?)

The real threat to Linux's continued viability has always been loss of interest in Linus's tree (and thus fragmentation), in 2002 because Linus couldn't keep up with patches before he started using Bitkeeper, and more recently because more people used Android and we weren't merging the patches they published so vanilla wasn't interesting to the Android guys. But in both of those cases the patches/trees in question were public (binary-only isn't _interesting_ anymore).

http://linuxmafia.com/faq/Licensing_and_Law/forking.html

The open source community has put serious effort into keeping _itself_ together (around Linus and kernel.org) using social and technical methods, not legal ones.

One of my original motivations for doing license enforcement was that people who tried their OWN license enforcement (like Glenn McGrath on BusyBox) tended to burn out so badly they stopped coding:

http://www.mail-archive.com/gnu-misc-discuss@gnu.org/msg0...

I wanted to make it so they didn't have to, so we wouldn't loose good developers to the legal system anymore.

But I ran the experiment, and learned from it, and that's why I _stopped_doing_it_. I no longer think the problem is _insufficient_ license enforcement, I think the problem is just license enforcement.

I think getting the legal system all over code is bad for the code, and there's no real _difference_ between MPAA/RIAA/SOPA, decss and DVDCCA, crypto export regulations, software patents, or the FSF/SFLC/GPLv3. It's all corrosive to doing the engineering parts right. GPLv2 works great as a social contract and statement of values, but bringing the legal system into my development cycle does not end well.

Rob

A tempest in a toybox

Posted Feb 9, 2012 17:12 UTC (Thu) by khim (subscriber, #9252) [Link]

I think getting the legal system all over code is bad for the code, and there's no real _difference_ between MPAA/RIAA/SOPA, decss and DVDCCA, crypto export regulations, software patents, or the FSF/SFLC/GPLv3.

There are large practical difference: MPAA/RIAA/SOPA/etc try to make devices closed, FSF/SFLC/GPLv3/etc try to keep them open. In a world without MPAA/RIAA/SOPA/etc the efforts of FSF/SFLC/GPLv3/etc will be useless and pointless. Sadly we don't live in such a world, we live in a world where MPAA/RIAA/etc is reality and every small victory (like SOPA death) is immediately replaced with something else (like ACTA). In this world efforts of FSF/SFLC/GPLv3/etc are important.

On the 'death penalty' thing

Posted Feb 1, 2012 17:11 UTC (Wed) by pizza (subscriber, #46) [Link] (45 responses)

Keep in mind that while the 'death penalty' and/or SFC's demands may seem extreme, they're pretty darn reasonable when viewed from the perspective of copyright law, which (at least in the US) allows for $150K *per copy* penalties, on top of an injunction preventing further distribution.

So if you violate the GPL, your product is already facing death row. The SFC's demands on top of that are several orders of mangitude less onerous than the law says they can ask for.

Even when taken to a more reasonable $2K per copy (as some of the end-user music piracy lawsuits have resulted in), that's still a penalty an order of magnitude larger than the probable retail value of the widget.

Anyway.

I used to work for an outfit that provided software ("BSPs") for access points and other wifi-enabled widgets. we delivered everything in source form, and the build system included a 'gplpackage' target that neatly packaged up every GPL component into a tarball, alongside the binary images. It's really not that hard to do, but one has to make that step a part of the release process.

On the 'death penalty' thing

Posted Feb 1, 2012 17:17 UTC (Wed) by hummassa (guest, #307) [Link] (7 responses)

> I used to work for an outfit that provided software ("BSPs") for access points and other wifi-enabled widgets. we delivered everything in source form, and the build system included a 'gplpackage' target that neatly packaged up every GPL component into a tarball, alongside the binary images. It's really not that hard to do, but one has to make that step a part of the release process.

It's not only "not hard", if you think about it (you ought to have a release process in place, no?) it's just plainly trivial to do so.

On the 'death penalty' thing

Posted Feb 1, 2012 17:24 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

Another thing to keep in mind is that the software in these things is (more often than not) done by a subcontractor of a subcontractor. This is commonly done to shield the parent from direct liability from the actual work. Each step in the chain they just package it up and toss it over the fence as a "finished" black-box item.

But the GPL trumps that hierarchy and short-circuits things -- the parent company (whose name is on the box and who the end-user has a relationship with) is the one ultimately responsible for adhering to the GPL, and can't legally pass the buck by saying "we didn't get the source from our suppliers".

On the 'death penalty' thing

Posted Feb 2, 2012 1:25 UTC (Thu) by rahvin (guest, #16953) [Link] (1 responses)

Even with commercial software, if a piece of the product infringes copyright (even a minuscule part of the product) whether it came from a subcontractor or not isn't going to matter in US courts. Microsoft has been sued numerous times for code they didn't even write. This is because even though it was supplied by a third party it was included in their product and they were the company violating copyright by distributing it.

From the courts point of view the infringer is the one distributing it, if you got the code from a third party your only recourse is to sue the supplier for the damages and costs associated with curing the copyright infringement.

On the 'death penalty' thing

Posted Feb 2, 2012 9:19 UTC (Thu) by marcH (subscriber, #57642) [Link]

And rightly so.

Imagine you get ill from eating some prepared food. Then the retailer claims its not its fault because the poor thing bought rotten eggs and did not notice. Would you accept that as an excuse?

On the 'death penalty' thing

Posted Feb 1, 2012 22:22 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

It's not only "not hard", if you think about it (you ought to have a release process in place, no?) it's just plainly trivial to do so.

Release process usually just pull some data from repository and builds everything. If developers committed stuff to the repository without due diligence then it may be non-trivial.

Actually it's usually non-trivial in the interesting case (where source was modified). The fact that you can obtain yet another copy of the busybox tarball is not all that interesting, people want modified copies (if something was changed at all) - this case tends to be exactly the case where it's hard to separate GPL code from non-GPL code.

On the 'death penalty' thing

Posted Feb 2, 2012 7:42 UTC (Thu) by hummassa (guest, #307) [Link] (2 responses)

> If developers committed stuff to the repository without due diligence then it may be non-trivial.

This just does not happen... or should not happen. In any case, if people commit *proprietary* stuff to the repository without due dilligence, the stakes are really higher.

> people want modified copies (if something was changed at all) - this case tends to be exactly the case where it's hard to separate GPL code from non-GPL code.

Not really. Abtraction, filtration, comparison -- is it a derivative work? If so, the "modified code" must also be GPLd, mark it as necessary in the "make gpl compliance tarball for upload" Makefile and be happy forever. Again, everyone should just act -- in the prep of a software-including product -- just as they would if free-licensed software pieces were proprietary-licensed software pieces: with due dilligence.

On the 'death penalty' thing

Posted Feb 2, 2012 14:07 UTC (Thu) by NAR (subscriber, #1313) [Link]

I've seen binary blobs in source repositories: there are quite few not so bright developers who download random stuff from the 'Net and put it there, because it's a lot easier than going through the company 3PP-inclusion process. Of course, they don't think about it if this ends up in the end product...

Moreover, projects can be transferred inside a multinational country between developer teams, countries or even continents, so it's perfectly plausible that a developer can be genuinely surprised if someone tells him that his product contains unlicensed binaries.

On the 'death penalty' thing

Posted Feb 2, 2012 14:37 UTC (Thu) by khim (subscriber, #9252) [Link]

This just does not happen... or should not happen. In any case, if people commit *proprietary* stuff to the repository without due dilligence, the stakes are really higher.

Absolutely not. In fact this is standard industry practice™: You commit everything to repository - SDKs, all the tools, compilers, etc. Everything. This may be formal violation of the license for some tools, but even this is not enforceable in most jurisdictions (if you have enough licenses to cover all the developers then you can just say you use repository for backup purposes). As long you don't distribute content of your repo everything is fine. But if you want to publish GPLed part then you need to separate the wheat from the lentil!

Again, everyone should just act -- in the prep of a software-including product -- just as they would if free-licensed software pieces were proprietary-licensed software pieces: with due dilligence.

It's much harder with free software. With proprietary software you usually don't have sources to modify, thus chance of mistakes is small. In some rare cases you do - but even then you mostly use vendor-supplied binaries and use sources only as reference. With free software not only you have sources - you often need to modify them slightly to make them usable (compileable, for example)! This raises risk of accidental violation hundredfold (if not thousandfold).

I can't in good conscience call the process which requires strict rules and serious effort "trivial", sorry. It's not that hard (some proprietary tools require significantly more work if you want to stay compliant), but it's not "trivial" either.

On the 'death penalty' thing

Posted Feb 1, 2012 18:04 UTC (Wed) by armijn (subscriber, #3653) [Link] (26 responses)

The problem that I (and others) have is that SFC demands things to be fixed that are outside of their own direct copyright (which is BusyBox), like binary kernel modules.

I have talked to various lawyers in the free software world about this (under Chatham House Rules, so I can't explicitely name them), but all of them have frowned upon this, or dismissed it outright.

Before this turns into another flamefest about whether or not it is immoral or not for companies to violate the GPL, this is *the* core question: can you demand things outside of your own direct copyright?

Perhaps the editor could poll some lawyers about this subject, and get permission to quote them? It would be very helpful.

On the 'death penalty' thing

Posted Feb 1, 2012 18:09 UTC (Wed) by corbet (editor, #1) [Link] (4 responses)

"The editor" has found it frustratingly difficult to get lawyers to say anything useful about subjects like this. It's unfortunate. There are, in fact, a lot of high-clue lawyers out there; they understand and support what we're doing. But the nature of their profession makes them unwilling to say much of anything interesting outside of the most private situations.

On the 'death penalty' thing

Posted Feb 1, 2012 22:21 UTC (Wed) by marcH (subscriber, #57642) [Link]

Is this a problem to quote these private discussions anonymously? I know it looks bad from a journalistic perspective but, journalists with enough credit can rely on that credit to do it.

On the 'death penalty' thing

Posted Feb 2, 2012 12:52 UTC (Thu) by ortalo (guest, #4654) [Link]

Would it be feasible (interesting?) to try a summary of the various cases and decisions actually judged on this topic? After all, lawyers opinions are less interesting than actual courts judgments on the topic.
However, such work would probably be extremely cumbersome (esp. for a technically-oriented writer): so do not take that for a request. But I am curious if such survey is simply feasible - it seems few trials on the topic have been brought to an actual end. (That's not necessarily a bad thing, but in the meantime, endless discussion goes on.)

On the 'death penalty' thing

Posted Feb 2, 2012 14:38 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] (1 responses)

Lawyers say what they're paid to say.

When the module thing comes to court, as I'm sure it will, you'll find that there are "high-clue" lawyers on both sides.

In cases like this, lawyers don't tell you what the law is; a judge does.

On the 'death penalty' thing

Posted Feb 3, 2012 10:32 UTC (Fri) by marcH (subscriber, #57642) [Link]

This might sound surprising but I think some lawyers can also be human beings sometimes and have private, honest conversations. For free.

On the 'death penalty' thing

Posted Feb 1, 2012 18:11 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (7 responses)

From a purely practical viewpoint, you obviously can - the SFC have done so on multiple occasions.

On the 'death penalty' thing

Posted Feb 1, 2012 18:24 UTC (Wed) by armijn (subscriber, #3653) [Link] (6 responses)

Please don't confuse an end result with something being legally sound.

I talked to several companies and lawyers and the pretty harsh terms (veto, review, binary kernel modules) are only pretty recent (Best Buy case, end of 2009). Before that it was indeed just as Bruce said: "not that bad" and reasonable terms.

Every company so far that has settled in the Best Buy case has settled under undisclosed terms but there is no *actual* judgement.

Perhaps the end result is indeed the same and companies said they would disclose source code, plus agree to something else (perhaps money, perhaps something else, but since those terms are not disclosed we don't know), just to get the lawsuits of their backs. But that still does not answer the core question whether or not it is actually legal to do so, which is what I am most interested in.

So far I have not heard a single lawyer (except from the ones from SFC) speak in support of the demands of SFC.

On the 'death penalty' thing

Posted Feb 1, 2012 18:36 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (2 responses)

Just to make sure we're on the same page here - are you saying that you've received legal advice to the effect that it's actively illegal for the SFC to make demands on unrelated software as a condition of restoring a Busybox license, or merely that there's no law saying that they can?

On the 'death penalty' thing

Posted Feb 2, 2012 2:56 UTC (Thu) by rahvin (guest, #16953) [Link]

I think anyone with at least the basic understanding of the legal system in the US should know that a plaintiff could demand the CEO of the defendant dress up in a bunny suit and play in traffic and there is nothing illegal about the request. The judge isn't likely to award such a thing in the event infringement is found but they can still claim it and demand it as part of a settlement AND the other side can agree to it as part of the settlement and it would be binding as long as the clause itself isn't illegal (such as requiring the murder of some other person).

IANAL, but there is nothing illegal about what SFC is doing. They can only make these claims and requests because the companies in question open the door by infringing the GPL.

I'd also like to point something else out which unfortunately wasn't in the article. It should go without saying that if a Kernel developer steps forward to work with SFC as the plaintiff they will be the one in the driver seat and if they disagree with certain actions SFC is taking they would be in a position to stop that and prevent SFC from doing whatever it is that the developer disagreed with. The only thing SFC could do would be to refuse to work for the plaintiff.

If you don't like how SFC is engaging in these actions and the terms and conditions they demand for closure the best way to stop them is to become their plaintiff and work with them.

On the 'death penalty' thing

Posted Feb 2, 2012 14:32 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

They most definitely can. They can require whatever they like in "payment" for granting a licence to use their code.

Some people grant a licence in return for money; some grant a licence in return for postcards. There's absolutely no reason that they can't grant a licence on the condition that the licensee complies with the licence of the *other* software they use. Or stops beating their wife. Or stands on their head and asks nicely.

I believe that the standing on the head example was actually made by a judge in a recent ruling.

On the 'death penalty' thing

Posted Feb 1, 2012 19:44 UTC (Wed) by jku (subscriber, #42379) [Link]

I understand the discussion on whether this the right thing to do or not, but why on earth would SFCs actions be illegal? Remember that we're talking about a settlement, something that the infringer chooses to take part in. They always have the option of not settling.

On the 'death penalty' thing

Posted Feb 2, 2012 2:07 UTC (Thu) by Trelane (guest, #56877) [Link]

How is the veto different from the "we may audit you for compliance at any time" terms of most proprietary software?

Aside from the obvious issue of the SFC not auditing you until you've allegedly violated the terms once.

On the 'death penalty' thing

Posted Feb 11, 2012 12:21 UTC (Sat) by Wol (subscriber, #4433) [Link]

I think the problem here is that, in most cases, once the SFLC get through to someone senior who understands the problem, the offender caves pretty quick and says "how can we put it right?".

Once the SFLC has got hold of someone who (a) has the clout to fix things, and (b) has the determination to fix things, it's pretty easy to come to an amicable solution.

The problem with Best Buy, as far as I can make out, was the only response the SFLC got was "not our problem". To the point they were finally exasperated enough to say "well it is your problem and we're going to court to make you face up to it!"

I don't know whether you have the same thing in America, but over here we have a position called "Company Secretary", of which most companies *M*U*S*T* legally have one. And one of the "perks" of the post is that if the company breaks the law, the Secretary is - *PERSONALLY* - legally liable and can be fined or imprisoned.

So over here, the equivalent of the SFLC could go to Companies House (the relevant public records office), find out who the Secretary is, and send them a registered letter. At which point he is personally on notice that he could end up in jail. He now has two choices. Pass the buck to the rest of the board, placing them on notice of jail terms, or resign. What do you think it's going to do to confidence in the Company if the Secretary resigns, giving as his reason that he doesn't want to go to jail?

Cheers,
Wol

On the 'death penalty' thing

Posted Feb 1, 2012 18:41 UTC (Wed) by raven667 (guest, #5198) [Link]

> for companies to violate the GPL, this is *the* core question: can you demand things outside of your own direct copyright?

If it came down to the technicality of it then probably no, the case would be thrown out (see RightHaven) but why wouldn't you ask for and help implement a comprehensive compliance program rather than playing monkey hear-no-evil, see-no-evil, speak-no-evil? Compliance is the ultimate goal, not punishment. Unless you think being forced to comply with the licenses of the software you ship is "punishment".

On the 'death penalty' thing

Posted Feb 1, 2012 18:53 UTC (Wed) by mjw (subscriber, #16740) [Link]

I was under the impression that this is a fairly standard settlement deal to avoid a full lawsuit and damages. The FSF also asks for something like this when they settle with a company and drop their lawsuit over GPL violations. In return for dropping the lawsuit the company that settles agrees to appoint something like a Free Software Director that periodically reports to the FSF about compliance with the free software licenses used by the company. It seems cheaper and more productive than having to fight a lawsuit, pay penalties and possibly having to terminate a whole product line. All parties win. I assume in return for not enforcing your copyrights you can ask (demand) anything, the other party doesn't have to agree of course, but if it is cheaper why wouldn't they? Or is this what the lawyers object to?

On the 'death penalty' thing

Posted Feb 1, 2012 19:04 UTC (Wed) by Otus (subscriber, #67685) [Link] (2 responses)

> Before this turns into another flamefest about whether or not it is
> immoral or not for companies to violate the GPL, this is *the* core
> question: can you demand things outside of your own direct copyright?

Correct me if I'm wrong, but isn't the SFC doing this via settlements? I though settlements allow the two parties to decide on whatever terms both accept, with basically no legal limits.

If the sued companies don't see the terms as acceptable they can continue the court case, where the SFC would presumably ask for a payment or whatever the law allows them to ask for.

On the 'death penalty' thing

Posted Feb 2, 2012 3:06 UTC (Thu) by rahvin (guest, #16953) [Link]

The law allows statutory damages for copyright at $150K per incident. Ship 10,000 widgets and statutory penalties for violation are going to max out at $1,500,000,000 (or $1.5 Billion).

Considering juries have been handing max statutory damages to poor single mothers who downloaded music off the internet (Jamie Thomas in her first trial for 21 songs was ordered to pay more than $1.5 million dollars) I think it's fairly probable that if a corporation was foolish enough to take this to the Jury they would end up with the max statutory damages the law allows but in reality the Jury can award damages anywhere between $0 and the max the law allows per infringement.

On the 'death penalty' thing

Posted Feb 5, 2012 20:42 UTC (Sun) by dwmw2 (subscriber, #2063) [Link]

"If the sued companies don't see the terms as acceptable they can continue the court case, where the SFC would presumably ask for a payment or whatever the law allows them to ask for."

Indeed. It seems rather odd to complain that a settlement is unfair to them, and then to accept it anyway because it costs them less than the penalty that the court would have imposed for their crimes.

I find it particularly strange given that the type of settlements they're talking about bear so little relation to the things that the SFC say they do ask for (see here).

If the likes of Sony really want to reduce their risk, perhaps they should lobby the government to reduce the statutory damages for copyright infringement?

On the 'death penalty' thing

Posted Feb 1, 2012 21:43 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

"this is *the* core question: can you demand things outside of your own direct copyright?"

Oh, sure you can. If you don't agree, take it to court. The fact that noone has dared to, speaks volumes about the legitimacy of the request.

On the 'death penalty' thing

Posted Feb 2, 2012 2:12 UTC (Thu) by Trelane (guest, #56877) [Link] (3 responses)

Do BSA auditors also audit for non-member software?

On the 'death penalty' thing

Posted Feb 2, 2012 2:16 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

I have no idea and don't care at all. BSA has nothing to do with Free software licenses which don't try to control use.

On the 'death penalty' thing

Posted Feb 2, 2012 2:51 UTC (Thu) by raven667 (guest, #5198) [Link] (1 responses)

Personally I think a comparison with what the BSA does would be instructive because they are very broadly doing the same kind of thing, enforcing copyright licenses.

On the 'death penalty' thing

Posted Feb 2, 2012 3:09 UTC (Thu) by rahvin (guest, #16953) [Link]

I don't think they venture outside their members though they may tip of a company and ask them to join. The problem would be that I doubt there is a software company with more than 1 employee that isn't a member of BSA.

On the 'death penalty' thing

Posted Feb 11, 2012 12:27 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

Well, if said defendant is shipping a box containing, amongst other things, busybox, AND THE SFC HAS BOUGHT ONE OF THOSE BOXES, then per the GPL they are entitled to a copy of the source of all the GPL programs on it.

So what they are demanding is "give us all the source we are legally entitled to".

Where it becomes a problem, and where Sony :-( has a problem with it, is they are also asking for the source for other products they may not have bought (that may well not even be on sale!).

Cheers,
Wol

On the 'death penalty' thing

Posted Feb 11, 2012 18:18 UTC (Sat) by corbet (editor, #1) [Link]

In the interest of clarity, it's worth repeating an important point here:

If somebody is shipping Busybox (or another GPL-licensed program), and they did not ship the source along with a binary distribution, then any third party is entitled to ask for the source. Having bought the box (or not) does not play into the picture in any way.

That said, third parties have no standing to legally enforce that requirement. Only the copyright holders can do that. The SFC, by virtue of representing copyright holders (and, possibly, being a copyright holder itself), has the standing to initiate this sort of action.

On the 'death penalty' thing

Posted Feb 9, 2012 8:06 UTC (Thu) by kevinm (guest, #69913) [Link]

They can "demand things outside their own copyright" because they are negotiating a new contract to restore the infringer's license to distribute the busybox code being represented. Almost any obligation can be written into a contract.

On the 'death penalty' thing

Posted Feb 1, 2012 20:07 UTC (Wed) by kripkenstein (guest, #43281) [Link] (9 responses)

> Keep in mind that while the 'death penalty' and/or SFC's demands may seem extreme, they're pretty darn reasonable when viewed from the perspective of copyright law, which (at least in the US) allows for $150K *per copy* penalties, on top of an injunction preventing further distribution.

This is a valid point.

However, that copyright law is insane doesn't excuse us in the FOSS community doing anything insane as well (even if it is much less insane).

It is *very* hard to convince corporations to use FOSS if the risk is that a single mistake by one of their teams means that the entire company can no longer use that specific FOSS until the copyright owner agrees for them to. The main problem is uncertainty: The corporation does not know ahead of time exactly what the copyright owner will demand. At least with a proprietary license, you know ahead of times the costs involved in a clear (well, clear-er) manner.

If I had believed the GPL did actually assume such a "death penalty" event - I prefer to call it a "hostage situation" - I would never have released the GPL code I did (I would have used another FOSS license). It strikes me as counter to the intent of the GPL, and very dangerous to the FOSS community as I said above.

It is more than sufficient to protect GPL code to interpret it in the more reasonable way, which is that distributing GPL code grants a new license each time. So that you have a license if you comply with the GPL. If you don't comply, you lose that license until you download a new copy, and are in compliance with that license. In this situation, violating the GPL is still very bad - you cannot use the code any more - but at least you know ahead of time exactly what you need to do to be able to use it again - come into compliance.

That the SFC does basically that - but for all FOSS projects the company uses, not the one whose license they violated - is not as bad as things *could* be, because in theory the license enforcer could ask for anything at all (hence I prefer the term "hostage situation"). But again, the problem is that corporations don't know for sure in advance what the SFC will require, if one of their teams makes a mistake and doesn't fully comply with the license of one of the FOSS projects they use. This is one of the biggest problems for FOSS adoption today.

On the 'death penalty' thing

Posted Feb 1, 2012 20:23 UTC (Wed) by raven667 (guest, #5198) [Link]

> distributing GPL code grants a new license each time

I'm not sure that it's been tested in court but that seems like a reasonable interpretation, you don't have the right to distribute at all if you are not compliant and every compliant distribution doesn't require individual authorization by the copyright owner.

> corporations don't know for sure in advance what the SFC will require

That doesn't really seem to be true, the SFC has stated many times that all they require is that general compliance efforts be undertaken and that their expenses be paid.

> The main problem is uncertainty

If that were the main problem then no one would every go into business, businesses deal with uncertainty and risk all day long. Unless you think there should be some government-mandated certainty of risk, certainty of profits, etc. there is going to be some amount of risk and uncertainty in business.

On the 'death penalty' thing

Posted Feb 1, 2012 20:27 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (4 responses)

You can certainly choose to interpret it as requiring that downloading a new copy grants you a new license, but given that GPLv3 uses almost identical language in a way that makes it clear you *don't* it's difficult to argue that that was the intent of the license authors. But as with all things legal, it's what a court decides that's important here.

On the 'death penalty' thing

Posted Feb 2, 2012 4:18 UTC (Thu) by kripkenstein (guest, #43281) [Link] (1 responses)

Actually the GPL3 wording, with the FSF's reasons for the wording, support the opposite: The GPL3 wording is there in order to clarify in a precise way what was always intended in the GPL2. There was a lack of clarity in the GPL2 which led to additional explanations in the GPL3.

On the 'death penalty' thing

Posted Feb 2, 2012 14:05 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

From the rationale for the first draft of GPLv3 (http://gplv3.fsf.org/gpl-rationale-2006-01-16.html#SECTIO...)

"GPLv2 provided for automatic termination of the rights of a person who copied, modified, sublicensed, or distributed a work in violation of the license. Automatic termination can be too harsh for those who have committed an inadvertent violation, particularly in cases involving distribution of large collections of software having numerous copyright holders. A violator who resumes compliance with GPLv2 would need to obtain forgiveness from all copyright holders, but even to contact them all might be impossible"

GPLv3 doesn't clarify the termination clause. It materially changes it.

On the 'death penalty' thing

Posted Feb 2, 2012 4:19 UTC (Thu) by rahvin (guest, #16953) [Link] (1 responses)

From what I know of Contract law it's not the intent of the author of contract that matters, it's the intent of the parties of the contract that does. It's that "meeting of the minds" that defines the contract, but only when the language is ambiguous.

In theory the author could mean something completely different than both the parties to the contract meant and it wouldn't be the authors interpretation that mattered. The caveat here is that if the two parties to the contract had different intentions, then the Judge is tasked with finding a middle ground and could in theory use the contract authors intentions to reach that point even if it was diametrically opposed to the intentions of both parties. But I don't think it's very common that a contract exists where the two parties to the contract have opposite interpretations to what the contact meant AND the author had a third interpretation that was different to both parties intentions. That would be some brutally awful contract language to reach that point.

a license is not a contract

Posted Feb 2, 2012 4:46 UTC (Thu) by ncm (guest, #165) [Link]

Copyright licenses are not contracts, and copyright law is not contract law. In a copyright license there is no "agreement" to be mediated; aside from "fair use", the only intentions that matter are those of the copyright holder. A judge who holds that the violator reasonably misunderstood the license terms can reduce the award accordingly -- after the violator has lost the case.

On the 'death penalty' thing

Posted Feb 2, 2012 2:30 UTC (Thu) by faramir (subscriber, #2327) [Link] (2 responses)

I don't see there is any more risk with the GPL then with a proprietary license. If you violate the license then you have no right to distribute.
The owner of the copyright (whether licensed under GPL or proprietary) may or may not elect to give you a new license to distribute under whatever terms they decide. The violator either accepts those new terms, stops distributing it, or gets sued for copyright violation.

Now it may be the case that companies violate the GPL license more often then they do proprietary licenses. Or maybe they just get caught more often. I really couldn't say, but I don't see how that matters.

On the 'death penalty' thing

Posted Feb 4, 2012 19:43 UTC (Sat) by krake (guest, #55996) [Link]

"I don't see there is any more risk with the GPL then with a proprietary license."

It seems kripkenstein has reason to believe that proprietary licenses come with details on how one would get a new license if one loses the current one due to violating its terms.

Sounds weird to me as well but that's what their posting says.

On the 'death penalty' thing

Posted Feb 9, 2012 20:03 UTC (Thu) by landley (guest, #6789) [Link]

> I don't see there is any more risk with the GPL then with a proprietary
> license.

Well, it's a _touch_ harder to invoke First Sale Doctrine. :)

Rob

A tempest in a toybox

Posted Feb 1, 2012 18:02 UTC (Wed) by deater (subscriber, #11746) [Link] (15 responses)

I find it shocking how many people are willing to make demands about what kind of projects people should be allowed to work on, or what kind of license they should use. Especially as the end argument seems to be "don't work on that new project, as it will reduce our ability to sue people". This has what Free Software has become?

I wonder what the reactions would be if some $BIGCOMPANY made demands that other companies found infringing its product $X had to stop using all open-source software and submit all future products to be audited for compliance.

I have written a lot of GPLv2 code over the years, but this whole situation has seriously made me reconsider my license choices.

A tempest in a toybox

Posted Feb 1, 2012 20:09 UTC (Wed) by ovitters (guest, #27950) [Link] (1 responses)

If the new project solely is started to get around the license of the new project, why not?

A tempest in a toybox

Posted Feb 9, 2012 20:15 UTC (Thu) by landley (guest, #6789) [Link]

And if it was instead started by an ex-maintainer of busybox who was so disgusted with a troll he couldn't stand to work on that project anymore and started over from scratch to ensure said troll could never take credit for any of his work ever again? And documented this extensively?

http://landley.net/notes-2006.html#18-09-2006

If it was started by the guy who set off the busybox license enforcement actions in the first place? March 27, 2006 entry from here:

http://busybox.net/oldnews.html

If the project was GPLv2 for the first few years and switched for reasons again publicly explained?

http://landley.net/notes-2011.html#13-11-2011

By the way, your position says that making FreeDOS or ReactOS are evil acts.

A tempest in a toybox

Posted Feb 1, 2012 23:56 UTC (Wed) by geertj (guest, #4116) [Link] (4 responses)

I fully agree. It seems that the once peaceful open source community has become invaded with angry individuals. A few years back i switched to the MIT license for most of my projects, and it will stay that way.

A tempest in a toybox

Posted Feb 2, 2012 13:06 UTC (Thu) by robert_s (subscriber, #42402) [Link] (3 responses)

So you like the GPL as long as it's not enforced then?

A tempest in a toybox

Posted Feb 2, 2012 15:38 UTC (Thu) by deater (subscriber, #11746) [Link] (1 responses)

Define enforced.

If GPL software is being shipped without source, I want that fixed.

I don't think the fix should involve all kinds of crazy strings attached.

Yes, it would be nice if the kernel GPL violations are fixed too. That's really unrelated to the busybox GPL enforcement. I mean, it would be nice if the infringing company would give all Linux developers candy and ponies too, but it seems like a silly demand to make.

If the Linux kernel developers want to enforce their GPL, let them. I don't see why it's the busybox lawyer's business at all though.

I'm saying this as someone who has a (very small) amount of GPL'd code in the linux-kernel tree.

A tempest in a toybox

Posted Feb 3, 2012 11:24 UTC (Fri) by dwmw2 (subscriber, #2063) [Link]

Seriously?

When they contact a router manufacturer who is shipping a Linux-based device without any source code at all, and they come to an out-of-court settlement… you'd rather they only made sure the offending company publishes their Busybox source code, and nothing else?

You don't want them asking the company to comply with the law for all software they use in that specific product?

For my part, I disagree strongly with you. I am grateful that they have been asking these companies to stop violating my copyright too.

I just don't understand your point of view at all. See the example I gave elsewhere about beating my children.

A tempest in a toybox

Posted Feb 9, 2012 20:19 UTC (Thu) by landley (guest, #6789) [Link]

I didn't leave the GPL, the GPL left me.

http://landley.net/notes-2006.html#03-12-2006

The FSF couldn't make me write GPLv3 code, but they _could_ make me stop writing GPLv2 code. And I'm not alone:

http://developers.slashdot.org/story/11/12/17/1735253/gpl...

A tempest in a toybox

Posted Feb 2, 2012 0:32 UTC (Thu) by mitchskin (subscriber, #32405) [Link] (3 responses)

That's just a strawman. No one is talking about "what kind of projects people should be allowed to work on, or what kind of license they should use".

It's just that *if* you agree with the GPL enforcement work, then we should work together to find ways to continue it even if there's a permissive replacement for busybox. It's not an attempt to control projects or licenses, it's an attempt to coordinate with other like-minded people.

A tempest in a toybox

Posted Feb 2, 2012 15:48 UTC (Thu) by deater (subscriber, #11746) [Link] (2 responses)

> No one is talking about "what kind of projects people should be
> allowed to work on, or what kind of license they should use".

Sure they are, I'm pretty sure that's Garrett's whole point.
See the thread here: http://lwn.net/Articles/478257/ .
He personally frowns upon the new project and its license, and is
discouraging anyone from helping.

A tempest in a toybox

Posted Feb 2, 2012 16:40 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (1 responses)

I don't object to the project or its license. I object to the motivation of certain people involved with it.

A tempest in a toybox

Posted Feb 9, 2012 20:50 UTC (Thu) by landley (guest, #6789) [Link]

I really must thank you for the Streisand Effect publicity: more developers have signed up to the toybox mailing list in the past 2 weeks than in the previous 2 years. I labored on this thing in complete obscurity in 2006-2010 (under GPLv2, no less) for 377 repository commits. Now I've merged three new externally submitted commands in the past week, all from new developers who found out about it from lwn and h-online and such. In fact I should probably cut a release this weekend...

So thanks for the signal boost. If you really want to personally pick up the sisyphos role of scaring developers away from open source via the legal system, good luck with it. Android's already written GPL off but I'm sure you can squeeze more out. I found it's easy to find lawyers happy to take companies' money, and really hard to get useful code out of the process. (Way, way, way more time and work than just writing it yourself.)

It's pretty easy to go after small fry and declare them "no longer in violation" after they go out of business or give your lawyers a lot of money and a random useless tarball of stuff you've already got to become technically compliant without ever actually producing any useful code because there _wasn't_ any. And you can draw it out _forever_ by suing "Board Support Package" customers, but not the BSP vendors who added the new drivers and never gave their customers complete source in the first place, and rack up an endless string of meaningless "victories" that way.

Personally? Been there. Done that. It gets old.

Rob

(I asked the SFLC why they sued Cisco instead of Broadcom, since they were complaining about a Broadcom BSP toolchain Cisco never _had_ the source code to. I never did get a clear answer to that one. I believe they said the FSF was the plaintiff not the busybox developers, so they couldn't discuss details of the case with me, or something like that.)

A tempest in a toybox

Posted Feb 2, 2012 3:17 UTC (Thu) by rahvin (guest, #16953) [Link] (3 responses)

Should I point out that when Microsoft threatened Barnes and Nobel with a patent infringement lawsuit and entered into negotiations they demanded the ability to veto future products, veto any of their features and even what hardware was included along with some other equally distasteful terms. The end result was that had B&N agreed to the terms they would have had to ask MS for permission for any new products and allow MS to make design decisions.

A tempest in a toybox

Posted Feb 2, 2012 10:06 UTC (Thu) by Trelane (guest, #56877) [Link] (2 responses)

Do you have links to supporting documents?

A tempest in a toybox

Posted Feb 2, 2012 11:34 UTC (Thu) by tterribe (guest, #66972) [Link] (1 responses)

http://web.archive.org/web/20191122135204/http://groklaw.net/article.php?story=2011111122291296

A tempest in a toybox

Posted Feb 3, 2012 1:10 UTC (Fri) by Trelane (guest, #56877) [Link]

Thanks! It's always great to have supporting evidence. It's sadly lacking in so many place, and if you don't have support, you don't have an argument.

A tempest in a toybox

Posted Feb 1, 2012 18:48 UTC (Wed) by jra (subscriber, #55261) [Link] (3 responses)

Conservancy position on GPL enforcement:

http://sfconservancy.org/blog/2012/feb/01/gpl-enforcement/

From the horse's mouth, as it were :-).

A tempest in a toybox

Posted Feb 1, 2012 19:15 UTC (Wed) by jra (subscriber, #55261) [Link] (2 responses)

Full disclosure - I'm a member of the Board of Directors of the SFC.

Jeremy.

A tempest in a toybox

Posted Feb 2, 2012 3:24 UTC (Thu) by rahvin (guest, #16953) [Link] (1 responses)

Thanks for posting that. I like in particular that the biggest complaint in this discussion seems to be that SFC is auditing all FOSS software but in reality those complaining are missing the point that by doing so you are protecting them against suit by others.

A tempest in a toybox

Posted Feb 9, 2012 20:52 UTC (Thu) by landley (guest, #6789) [Link]

So you're paying them for "protection".

Got it.

About the calculus for the project

Posted Feb 1, 2012 19:03 UTC (Wed) by tbird20d (subscriber, #1901) [Link] (120 responses)

I understand that GPL violators make people upset. They upset me as well. Sony is not involved in this project (other than that I work for Sony), so please take my Sony examples as explanatory only. I wanted to explain something that I haven't communicated very well.

People have said that the cost of compliance is small. This is true, but it can be difficult to enforce across a large organization, especially with lots of sub-contractors and suppliers.

Imagine if you were mayor of a town of 300,000 people, and you had to pay a million dollar fine if someone was caught stealing. You have implemented a set of policies to prevent stealing, and to encourage people not to steal. Could you guarantee that no one ever stole? As mayor, would you pay $1,000 for an insurance policy against the fine? That's similar to the cost/benefit calculus for this project, for large enterprises. It's not that executives are unwilling to enforce compliance, or are actively undermining the license of the code their company ships. They just want to reduce risk.

Some people have said that what the SFC requests in remedies is not that costly, but I can assure you that large corporations see it very differently. Matthew, in particular, keeps asserting that the real reason for this project is "to make it easier to infringe the kernel's license." This is simply not true.

For a large company that is compliant with the GPL, the biggest worry is that a 3rd party (and a legally hostile one at that) would be given the right to review (and therefore delay) the shipment of its products. Bruce Perens said that the SFC requirement to audit the software for all GPL-based products was a "reasonable request". It certainly sounds like an appropriate thing to do for a repeat offender. But in terms of perceived cost, for Sony this would delay, and worse, add uncertainty to the release dates of hundreds of products each year. Time to market is an exceedingly big deal in consumer electronics. Products have lived or died by hitting or missing their launch windows. Marketing budgets are in the millions of dollars, with product releases designed to coincide with the holidays, or other specific events. The paltry figure of $5000 per audit seems small, but when multiplied by hundreds of products adds up to well over half a million a year in potential costs. But even worse is the time uncertainty that such an audit adds to the release cycle.

It is a shame that a few non-compliers have poisoned the well for those who take their GPL compliance seriously. I think that the SFC is over-reaching, and I'm sorry to say that I believe they will continue to over-reach. Given the scope of the remedies requested by the SFC, I believe eliminating the possibility of a license violation is a valid, although not ideal, solution.

About the calculus for the project

Posted Feb 1, 2012 19:22 UTC (Wed) by cmorgan (guest, #71980) [Link] (1 responses)

I've heard of the same thing happening with proprietary software. Some disgruntled employee lets it slip that software X is being used without a license and the company ends up having to buy a bunch of licenses or a site license or face legal action.

Most companies take care to have an appropriate number of licenses for their software. They should do the same if its my software or big company X's software and I'm glad to see people like the SFC sticking up for the little guy.

About the calculus for the project

Posted Feb 1, 2012 20:09 UTC (Wed) by raven667 (guest, #5198) [Link]

I have not gone through one but I understand that BSA audits are no picnic and compliance efforts tend to be more expensive and complex than for Free Software licenses. Certainly the organizations I've worked for were far more concerned about the cost of a BSA audit and compliance action on proprietary software than GPL software, for example you don't need to track each copy of GPL software you use, only the provenance of software thats shipped to customers.

About the calculus for the project

Posted Feb 1, 2012 20:12 UTC (Wed) by ovitters (guest, #27950) [Link]

SFC is doing far less than what they could do.

The legal bits are important; you cannot just ignore it, then complain that SFC is somehow bad. It started with ignoring copyright and the license of the code. I thought there was some kind of thing where people are assumed to know the law. Meaning: ignorance is no excuse.

About the calculus for the project

Posted Feb 1, 2012 21:39 UTC (Wed) by jimparis (guest, #38647) [Link] (33 responses)

Imagine if you were mayor of a town of 300,000 people, and you had to pay a million dollar fine if someone was caught stealing. You have implemented a set of policies to prevent stealing, and to encourage people not to steal. Could you guarantee that no one ever stole? As mayor, would you pay $1,000 for an insurance policy against the fine? That's similar to the cost/benefit calculus for this project, for large enterprises. It's not that executives are unwilling to enforce compliance, or are actively undermining the license of the code their company ships. They just want to reduce risk.

Logical, but I don't buy it.

Your argument is "We try our best, but we're worried that one mistake will cost us." That's easy to avoid. Put a link on your product page, "Open-source licenses and source code". Put another link on that page, "Contact us if you have any concerns". And then just respond to those concerns. Have someone actually answer those emails, someone who has the authority to actually do something about it. If there's a mistake, someone will point it out, you will address it, and you are done. If it takes a long time to address, put up a new webpage explaining all of the issues and how you're addressing them and why it's taking so long, and update it regularly. We are not stupid; we recognize a good-faith effort when we see one. That's how it usually works. The lawsuits and settlements and veto powers and product delays have always come after a company has failed to actually solve the problem.

Even the SFLC doesn't file lawsuits until they have to. In the announcement of the big Best Buy suit:

The First Rule of GPL Compliance: “Be Responsive When Contacted”
The SFLC has dealt with over a hundred compliance matters since its inception on behalf of various clients, including BusyBox and developers of significant portions of the GNU/Linux operating system. The vast majority of these matters usually end with violators voluntarily coming into compliance. In the rare cases when a company refuses to cooperate in good faith, the SFLC has been forced to take legal action on behalf of its clients to enforce FOSS requirements.

About the calculus for the project

Posted Feb 1, 2012 21:49 UTC (Wed) by raven667 (guest, #5198) [Link]

> We are not stupid; we recognize a good-faith effort when we see one

I think the disagreement is that tbird doesn't believe you when you say that the SFC will operate in good faith

https://lwn.net/Articles/478770/

Without making a judgement about the merits I'm not sure this is a reconcilable difference of opinion.

About the calculus for the project

Posted Feb 1, 2012 23:39 UTC (Wed) by tbird20d (subscriber, #1901) [Link] (31 responses)

Put a link on your product page, "Open-source licenses and source code". Put another link on that page, "Contact us if you have any concerns". And then just respond to those concerns. Have someone actually answer those emails, someone who has the authority to actually do something about it.

The site address is: http://www.sony.net/Products/Linux/common/search.html
The e-mail address is: tim dot bird at am dot sony dot com.
That's me.

The lawsuits and settlements and veto powers and product delays have always come after a company has failed to actually solve the problem.

So say you.

About the calculus for the project

Posted Feb 2, 2012 0:30 UTC (Thu) by jubal (subscriber, #67202) [Link]

two words: onus probandi

About the calculus for the project

Posted Feb 2, 2012 0:38 UTC (Thu) by mitchskin (subscriber, #32405) [Link]

> So say you.

I haven't seen you give a specific example that contradicts what he said.

About the calculus for the project

Posted Feb 2, 2012 3:33 UTC (Thu) by rahvin (guest, #16953) [Link] (28 responses)

>So say you.

Nothing like publicly calling someone a liar.

About the calculus for the project

Posted Feb 2, 2012 4:24 UTC (Thu) by tbird20d (subscriber, #1901) [Link] (27 responses)

Nothing like publicly calling someone a liar.

That was not my intent, and I apologize if it came out that way. I intended to convey that I don't think this is guaranteed to be the case, and that I doubt the author can certify this assertion. What the author states is certainly what the SFC reports.

I have no reason to believe that the author (jimparis) does not believe the assertion.

About the calculus for the project

Posted Feb 2, 2012 7:47 UTC (Thu) by ekj (guest, #1524) [Link] (26 responses)

It's not -guaranteed- if you violate the license, even accidentally, there's no *guarantee* that you won't run into a hostile and agressive litigant.

But it's not been the trend. I don't think I recall even a single case where a company has openly admitted to their mistake, *responded* and made a good-faith effort to rectify the problem, yet nevertheless ended up in court.

Yes, in principle it could happen. In practice, it does not seem likely.

About the calculus for the project

Posted Feb 2, 2012 10:03 UTC (Thu) by khim (subscriber, #9252) [Link] (25 responses)

Looks like this is about definitions...

I don't think I recall even a single case where a company has openly admitted to their mistake, *responded* and made a good-faith effort to rectify the problem, yet nevertheless ended up in court.

It all depends on the definition of "good faith". The whole tempest started boiling when FSF sued CISCO. And as Rob Landley claimed it happened while CISCO was doing the honest good-faith effort to rectify the problem. It's just, you know, five years is not enough for them to get their house in order, that's all.

Well, got that: if you try to reach compliance but that's hard then you can spend years and that's Ok, because it's hard, you know. Hmm... Home come Youtube was sued when it spent less then three years trying to solve similar problem? Home come Megaupload was not given five years? Somehow when copyrights of "big boys" are violated "good faith" is "you must do everything you could to stop that... pronto... today, or, better yet, yesterday". Youtube won in the end, but not because Google installed new copyright protection system, but because it already did what the law required at the beginning of the lawsuit. Even so: Google went to great lengths to make sure they do not only the bare minimum law requires, but they go above and beyond. Because, you know, they are large and powerful and so must be held to higher standards. Yet somehow CISCO, SONY and other large companies should be given years before they'll do even bare minimum? Gosh.

P.S. I'm not happy to live is this super-litigious world. I'd much prefer to live without copyright at all (and yes, I know that in this case it'll be harder for me to sell my own work, too). But as long as large companies continue to raise stakes WRT to copyright violations we have no recourse but to respond. IMNSHO what SFC is doing is relatively mild response to this copyright escalation. The whole "tempest" looks silly for me: it's as if Bacterian complained after the fight that Krillin should be disqualified because he used dirty tricks.

About the calculus for the project

Posted Feb 9, 2012 21:26 UTC (Thu) by landley (guest, #6789) [Link] (24 responses)

Actually Cisco outsourced the old linksys Linux stuff to a taiwanese company after the first lawsuit, washed their hands of Linux, and switched the Linksys router line to using some other embedded OS. (PNX? I forget.)

They had just taken Linux development back in-house for new routers (like the WRT610n) that had the capability to do a lot more in software. The guys in taiwan had monkey-patched the old broadcom build system into a horrible mess, all the package versions were 5 years old, and they were creating a while new build system (code-names "Bruschetta" and "Prosciutto" for minor variants of the same thing), and the new one came with a whole open source methodology they were setting up with public websites and participation on public lists and engagement in the community and a dedicated code auditing period between GM and actual production where the developers did NOTHING but confirm source versions and license info and ship the _source_ before shipping the _product_.

And then the FSF came in sock-puppeted the SFLC to go "you know that thing you outsourced to Taiwan after the first lawsuit, and haven't touched in 5 years, which the entire new development effort is aimed at obsoleting and replacing with current vanilla versions of everything? We're suing you over it AGAIN!"

And senior management went "Open Source is Not To Be Trusted", killed off the new in-house Linux effort, and outsourced support of existing WRT610n units to... Red Hat, I think.

The toolchain the FSF was suing over was A) from 2003 or so (gcc 3.2.3, binutils 2.13.2.1, linux-2.4.20, glibc-2.2.5. In 2008), B) from broadcom (cisco never had the source), C) a generic mips toolchain for a 5 year old hardware architecture. I'm fairly certain a toolchain built from all the vanilla sources would have happily worked as a drop-in replacement, but it was so old old nobody could build it on modern distros (and linux-2.4.20 wouldn't compile with gcc 4.x):

http://landley.net/notes-2008.html#21-12-2008

But by all means, consider the FSF's actions _useful_. After all, the end result was that all the guys working on getting vanilla Linux working well on the WRT610n were transferred off of Linux development to do Windows and IOS...

By the way, the only reason I know _this_ story in such detail is I was (purely coincidentally) on the other side of it. I expect the other enforcement actions were often equally pointless and/or counter productve, I just didn't get inside details from the engineers impacted by them. I just heard from lawyers and managers, and got code drops through intermediaries (which never had anything in them we would want, but I had to trawl through anyway to confirm that it did in fact reproduce the binary and identify random source control snapshot X plus backports of these 15 random commits out of the same source control system, plus debug printfs that really shouldn't have shipped, and they hardwired in these constants instead of learning how to use the config system...) All I really know about those _other_ actions is they were a complete waste of time from the perspective of BusyBox development.

(P.S. When I told the SFLC/SFC to stop representing me, they raised the fact I was giving up settlement money to try to convince me to stay. But money was _never_ why I did it, and it's not why I stopped either. I started the busybox enforcement actions because I thought it was the right thing to do and would help BusyBox and embedded Linux development and adoption, and I stopped when I figured out it was at _best_ useless, and most likely doing real harm to the goal of getting the most people to use the best software, harming _both_ the "most" and "best" parts of that goal.)

Rob

About the calculus for the project

Posted Feb 9, 2012 22:13 UTC (Thu) by khim (subscriber, #9252) [Link] (21 responses)

Well, if you are correct then your heart-rending story just reiforced the the ekj's point:

I don't think I recall even a single case where a company has openly admitted to their mistake, *responded* and made a good-faith effort to rectify the problem, yet nevertheless ended up in court.

because

The guys in taiwan had monkey-patched the old broadcom build system into a horrible mess, all the package versions were 5 years old, and…

they still had no plans to ever produce sources for the devices they continued to ship.

But by all means, consider the FSF's actions _useful_. After all, the end result was that all the guys working on getting vanilla Linux working well on the WRT610n were transferred off of Linux development to do Windows and IOS...

This is obviously unfortunate but alternative is to basically give the CISCOs of the world right to ignore license requirements for as long as they want and to only participate in the development when they want. This is basically what Apache, BSD and MIT licenses are doing. Well, who knows, may be this is indeed the best way - but then the way to do this is not to ignore GPL and pretend you can treat it like the BSD license, but to actually rewrite or relicense all the GPLed code under BSD license.

Do you plan to rewrite Linux kernel you or do you plan to use *BSD kernel instead? This is honest question: inquiring minds want to know. Because the whole point of the aforementioned exercise was to show that "drag your feet, ignore old compliance issues and they will go away in time" does not work. Toybox by itself will not be sufficient to protect the companies.

About the calculus for the project

Posted Feb 10, 2012 1:56 UTC (Fri) by landley (guest, #6789) [Link] (20 responses)

I've never been a kernel developer. I've patched it occasionally, but it's never been something I write new chunks of for fun. So _I_ don't personally plan to do anything there.

But if the linux kernel becomes the nest of lawsuits busybox has, how hard would it really be to replace?

Context: the iPhone is running a bsd derivative already, and it didn't take apple all that long to switch from MacOS 9 to MacOS X (and that was porting the whole of MacOS userspace on top of it, _and_ there was a crazy divergence onto microkernels with mach they had to back out again)? Remember how Darwin is technically OpenDarwin?

The amount of engineering effort Google's already devoted to the Android kernel would let it fork a BSD kernel (net, open, free, dragonfly, darwin, doesn't really matter which), port all their new driver stuff to it, and get it reasonably working with their userspace in about 18 months.

Keep in mind, all _they_ want to do is run dalvik. Most of the stuff that Linux _has_, from massive SMP scalability through I/O elevators to container support... isn't really used on Android phones. Heck, bionic couldn't getpwnam() anybody but root last I checked...

Intellectual exercise: what would it take to port Linux 0.0.1 to android hardware? (Linus wrote that in 3 months, as a student. And when he started he didn't know how.) Now what would it take to extend that to where it could run Dalvik, drive an LCD touchscreen, a speaker and microphone, talk to the flash hardware, and control a dozen GPIO pins for buttons and LEDs and such? (The radio's already a binary blob running on another processor. Basically we're talking "u-boot with a scheduler".) How _small_ a team could do this? How long would it take? Now, does Google have the ability to do _better_ than that? How much better?

I'd say the android guys clearly _could_ replace the Linux kernel, if pushed. I don't think they _want_ to, and I'd like to be clear that I would not consider this a good outcome. But lawsuits are a nuclear option. You rattle sabers all you want, use them for leverage and negotiation. But stabbing somebody with them is an act of war. Flinging lawsuits around on a regular basis like the SFLC is doing means you're a rogue state, and must be dealt with. It's gone beyond "counterproductive".

I did not suddenly suggest "hey, I wonder if anybody would want a BSD licensed embedded command line" to other people. Neither did Tim. "No GPL in userspace" was NOT OUR IDEA.

Lots of people approached _Tim_ in his capacity as CELF dude. (Tim runs the Consumer Electronic Linux Forum and the Embedded Linux Conference that the Linux Foundation recently consumed. That's why people come to him and go "do you know of an X, I'm looking for one".) Tim wasn't the only one sniffing around, he's just the one who was willing to go _public_ about it, and take the heat for doing so. He was _responding_ to lots of people out there.

Everybody's flipping out about toybox but totally ignorant of the other projects out there also working on this:

http://beastiebox.sourceforge.net/
http://hg.suckless.org/sbase/

And so on and so forth. Toolbox itself would be one if Google put any work into it. The demand for a non-GPL busybox is something out there that _exists_, due to the SFLC and SFC's overuse of lawsuits. It's like antibotic resistance: use your "defense" stupidly and aggressively enough for long enough and the ecosystem adapts to render it irreelvant.

If it wasn't for the GPL aspect, wouldn't the busybox lawsuit factory be lumped in with the patent trolls and the BSA? You just seem to think the goals justify the means. I don't.

About the calculus for the project

Posted Feb 10, 2012 9:47 UTC (Fri) by khim (subscriber, #9252) [Link] (19 responses)

Context: the iPhone is running a bsd derivative already, and it didn't take apple all that long to switch from MacOS 9 to MacOS X

Yup. Measly ten years (NextStep was bought in 1996 and MacOS Classic was abandoned in 2006).

and that was porting the whole of MacOS userspace on top of it, _and_ there was a crazy divergence onto microkernels with mach they had to back out again

They have not ported the whole of MacOS userspace. They ran old system and new system side-by-side. Similar to dosbox or KVM.

Sure, they kept some APIs, but ultimately MacOS X and MacOS Classic share very little (besides the name).

Remember how Darwin is technically OpenDarwin?

That's prehistory - and another ten years of development (from about 1985 to 1996).

The amount of engineering effort Google's already devoted to the Android kernel would let it fork a BSD kernel (net, open, free, dragonfly, darwin, doesn't really matter which), port all their new driver stuff to it, and get it reasonably working with their userspace in about 18 months.

I sincerely doubt it. They will need to port all the hardware drivers first and talk with partners, etc. Realistically speaking it'll be about three-four years till the first raw port (this is how long it took to produce the first version of MacOS X: porting started in 1997, first version of MacOS X was released in 2001 - and it was poor sight, it was incomplete, buggy, etc).

Keep in mind, all _they_ want to do is run dalvik. Most of the stuff that Linux _has_, from massive SMP scalability through I/O elevators to container support... isn't really used on Android phones.

...today. But with 8-cores on the horizon and other similar development it may become important before long.

Intellectual exercise: what would it take to port Linux 0.0.1 to android hardware? (Linus wrote that in 3 months, as a student. And when he started he didn't know how.)

You'll need to find the right kind of guy, but yes, it's doable in similar time. Give or take. Of course (unlike PC) you'll need to keep porting thing to new versions of phones again and again, but that's doable.

Now what would it take to extend that to where it could run Dalvik, drive an LCD touchscreen, a speaker and microphone, talk to the flash hardware, and control a dozen GPIO pins for buttons and LEDs and such?

That's where it gets hairy: Android uses surprising amount of very modern features. It's not clear how fast you can implement them from scratch. It's obvious that you'll need years, but if you'll need fifteen years, five years, or three years is interesting question.

I'd say the android guys clearly _could_ replace the Linux kernel, if pushed.

Not really. They can replace it if this will be strategic goal and development will need to start well in advance (think Apple's switch to Intel), but not if pushed: even three years delay will be enough to kill the platform (ask PalmOS guys).

You rattle sabers all you want, use them for leverage and negotiation. But stabbing somebody with them is an act of war.

Bullshit. Have you looked on number of Android-related lawsuits lately? How many of them lead to total abandonment of the platform and switch to something else?

Flinging lawsuits around on a regular basis like the SFLC is doing means you're a rogue state, and must be dealt with.

Actually flinging lawsuits around on a regular basis is "business as usual" in mobile space. Think Apple and Samsung: they are partners yet they sue each other anyway.

Everybody's flipping out about toybox but totally ignorant of the other projects out there also working on this:

These people are not developing software designed to make GPL violation painless. Toybox was in the same bucket for years, it only become controversial when Tim basically said: our subcontractors like to violate GPL and this is a problem because pesky SFC likes to enforce it - we must make sure these violations are painless for us. Note that this is from a guy who works for a company which goes to great lengths to sue people which help others violate their valuable IP (AFAIK Geohot never pirated anything SONY-related himself).

Of course when faced with blatant hypocrisy (when Geohot helps other people to violate SONYs copyright then he should go to jail, but when SONY's subcontractors violate GPL then we should help them) people flipped.

It's like antibotic resistance: use your "defense" stupidly and aggressively enough for long enough and the ecosystem adapts to render it irreelvant.

Perhaps. That's why I asked what you plan to do to replace Linux kernel. It looks like you have no plans in this area which makes the whole thing supremely disgusting.

If it wasn't for the GPL aspect, wouldn't the busybox lawsuit factory be lumped in with the patent trolls and the BSA?

If you lump BSA together with trolls then you already lost the ball. These are entirely different menaces. As for SFC… yes, it's here because BSA is here, but last time I've checked BSA had no plans to disband itself any time soon.

About the calculus for the project

Posted Feb 10, 2012 16:05 UTC (Fri) by landley (guest, #6789) [Link]

> Perhaps. That's why I asked what you plan to do to replace Linux kernel.

I honestly hadn't thought about it before you brought it up, but I could install one of the BSDs in QEMU and regression test under that the same way I occasionally pull out my old Red Hat 9 image and see what subset of the functionality works under that. In theory I'm programming to posix (largely because bionic is a vague port of the OpenBSD libc).

You might as well be asking how I plan to keep kosher. This is not my fight. I don't personally like pork, but I don't avoid cheeseburgers either. I can make sure to _regularly_ have milk whenever I have meat, just to make sure you lose, but my goal here is to get you to go away and stop bothering me.

So ok, Toybox should make sure at least a subset of the commands can also build and run on BSD. Right, I'll throw it on the todo heap...

Rob

About the calculus for the project

Posted Feb 10, 2012 18:32 UTC (Fri) by dlang (guest, #313) [Link] (17 responses)

be very careful about your argument that a project may be illegal if it exists to let people avoid complying with the license for some other application.

with that argument just about all opensource project are illegal.

after all, what's linux but a project to let people have a unix-like system without complying with the proprietary licenses of the commercial unix systems?

what's openoffice but a project to let people have an alternative to microsoft office without complying with the proprietary licenses that microsoft sells?

if you go hunting for it, every opensource project can be framed in a way as to be encouraging people to avoid complying with some commercial license (the free as in beer part of freedom), and this is frequently touted as a significant reason for the open software existing by the project itself (not just a third party talking about the project like in the case of toybox)

About the calculus for the project

Posted Feb 10, 2012 18:50 UTC (Fri) by raven667 (guest, #5198) [Link] (6 responses)

> if you go hunting for it, every opensource project can be framed in a way as to be encouraging people to avoid complying with some commercial license (the free as in beer part of freedom), and this is frequently touted as a significant reason for the open software existing by the project itself (not just a third party talking about the project like in the case of toybox)

This is clearly a nonsense interpretation of what was asserted and I'm disappointed that you'd choose to bring it up this way. The assertion was that because the software only ran on a GPLv2 system and was only useful in this context that building a system using this software for the sole purpose of not complying with the source sharing requirements of the GPLv2 was abetting software piracy even though this software itself is not GPLv2 and does not, itself, have source sharing requirements. This exactly has zero parallels with your examples.

About the calculus for the project

Posted Feb 10, 2012 19:03 UTC (Fri) by dlang (guest, #313) [Link] (5 responses)

I think it makes as much sense as the argument that it's illegal for Rob to write toybox under a BSD license because it allows people to avoid complying with the GPLv2 because toybox can be used to replace the Busybox code that Rob also wrote.

I think that both arguments are nonsense, but if you believe in one, the other comes along as baggage.

About the calculus for the project

Posted Feb 10, 2012 19:27 UTC (Fri) by jake (editor, #205) [Link] (3 responses)

> argument that it's illegal for Rob to write toybox under a BSD license

and who on earth has made this argument? not liking him doing so is hardly a claim that it's "illegal" ...

jake

About the calculus for the project

Posted Feb 10, 2012 19:37 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

there are posts in this topic claiming that toybox is illegal code on the basis that it is being written to contribute to copyright infringement. Raven667 is one of the people making this argument and is using the example of napster as justification.

if you load the full series of comments and search for 'illegal' you will see it being introduced.

About the calculus for the project

Posted Feb 10, 2012 20:12 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

if you load the full series of comments and search for 'illegal' you will see it being introduced.

Please try to actually do that, Ok. You'll find that the first post is mine and it clearly states I have no problems with Rob's work.

Rob wrote busybox replacement to solve some problems with busybox. No problem so far. Then later Tim comes along and convinces Rob to change the license citing SFC as the reason. This is the point when the whole outrage started and at this point it stopped being about technically interesting rewrite of busybox and started being about legally questionable GPL infringement easement.

Only court may say for sure if such thing is legal or not, but the very fact that it's sold under "let's make sure SFC can not sue us for the violation of GPL while we continue to use identically-licensed other pieces of code" is not just morally wrong, it's highly questionable on legal grounds, too.

About the calculus for the project

Posted Feb 11, 2012 22:30 UTC (Sat) by landley (guest, #6789) [Link]

> Rob wrote busybox replacement to solve some problems with busybox. No
> problem so far. Then later Tim comes along and convinces Rob to change the
> license citing SFC as the reason.

Except that's not what happened.

Tim was trying to start a project called "BentoBox", which most likely would extend Android's Toolbox, and if not would start over from scratch. He was doing so in his capacity as CELF guy (not a Sony guy) because a number of different manufacturers had approached _him_ looking for such a thing, and he thought that pooling their resources was better than each of them writing yet another half-assed bsd-licensed not-busybox (toolbox, bsdbox, beastiebox, sbase, who knows how many private ones behind closed doors?)

Initially, I told him I wasn't interested. And then I thought about it and went "A _billion_ android devices. They've already had five years to ship busybox and didn't. Something is going to fill that market vacuum, and when it does it will be BIG."

I also thought: I really liked working on toybox, I only stopped because I didn't think anybody would ever use the result, because no matter how technically better I make it, it would have to displace an existing "good enough" solution with a ten year headstart including years of my own work. But... market vacuum. Billions of seats. They're going to use SOMETHING...

Tim still hasn't paid me a dime, and may never do so. (I'd love it if he _did_, but that's not why I restarted Toybox.)

I am the one who chose to relicense toybox. I didn't wait for Tim to decide to redirect his bentobox thing, I didn't wait for anybody to come up with any money, or a marketing campaign, or even a promise to use it instead of going off and doing something else that would compete with it.

I decided that Toybox should be restarted as a BSD-licensed project (Tim was proposing Apache license for bentobox). It was my code, I'm the only one who _could_ relicense it, and I'm certainly the only one who could make me work on it.

I am not Tim's puppet. And I'm not your puppet either. I've been programming since I was 12, releasing the results for free since almost that long (300 baud modem to BBS's: the first program I wrote and uploaded was "The Bard's Tailor", an editor for C64 bard's tale game save files), and doing so as open source since 1998. I didn't even MEET Tim until 2006.

That's the annoying assumption here, that some large company is pulling the strings, it's a conspiracy! In reality, large companies haven't had time to REACT to any of this. Tim made a proposal Sony has yet to even _evaluate_, and he works for them! Fortune 500 corporations move very, very slowly. They haven't noticed this project EXISTS yet. I may have 1.0 out before they do.

Rob

P.S. And please: Tim citing SFC at _me_? I fell out with SFLC before SFC forked off from them, I was very public about it in my blog, and have linked those old blog entries here ad nauseam. The no GPL in userspace thing is an Android policy which my _current_ employer (Polycom, I work in board bringup which has nothing to do with any of this) has adopted itself for Android products it ships (basically all new ones). I.E. the team I personally work on at my day job does board bringup in vanilla-ish Linux (A TI fork thereof, anyway; we recently got to upgrade to 2.6.37!), and then once we've made all the hardware work the prototypes get reformatted and handed off to a completely separate set of developers who install an android kernel (again from TI) and userspace, and write a Java GUI that runs in Dalvik and gets packaged into an apk file to install into Android. Those guys can't use _any_ GPL stuff in userspace. The only reason _we_ get to is that none of the userspace code we write ever _ships_. We're mostly just figuring out which wires aren't connected up right and which existing drivers don't do what we need them to so the vendor (TI) can fix 'em.

About the calculus for the project

Posted Feb 10, 2012 19:33 UTC (Fri) by raven667 (guest, #5198) [Link]

The argument is that this does not happen in a vacuum, context matters and that this might be argued to be similar to the Napster case. I'm pretty doubtful that either a lawsuit or this interpretation of the situation will ever be realized. In any event I objected to the ridiculous straw man arguments chosen in favor of just arguing on-point since you clearly do understand what was intended.

About the calculus for the project

Posted Feb 10, 2012 19:49 UTC (Fri) by khim (subscriber, #9252) [Link] (9 responses)

after all, what's linux but a project to let people have a unix-like system without complying with the proprietary licenses of the commercial unix systems?

… and without using any code from said unix systems. The very first goal was to make Linux self-hosted and make sure you can use it without buying license for Minix.

what's openoffice but a project to let people have an alternative to microsoft office without complying with the proprietary licenses that microsoft sells?

… and without use of any proprietary code at all. Important milestone was reached when openoffice was freed from all binary blobs.

if you go hunting for it, every opensource project can be framed in a way as to be encouraging people to avoid complying with some commercial license (the free as in beer part of freedom), and this is frequently touted as a significant reason for the open software existing by the project itself (not just a third party talking about the project like in the case of toybox)

Wow. That's certainly bold statement. What kind of proprietary software will you need to use Linux, OpenOffice.org, GCC or any other tool? All FOSS projects I know strive very hard to make sure they can be used without any proprietary software at all. And when they need some binary blob it's always a problem which is considered quite serious - and this is not the new phenomenon. Number of drivers are not in Linux's mainstream kernel simply because they need binary blobs with questionable licenses.

Compare it with project under discussion which quite explicitly is useless without GPLed components. And when asked about replacement for the other piece of puzzle the author itself noted that he honestly hadn't thought about it before. Sorry, but I find it quite hard to believe it's the same thing when people explicitly say that they want to make sure all the licenses are followed to a T and when they say "here is pile of identically licensed code which license is often violated but where some piece is more often in spotlight, let's make sure this piece is removed but keep everything else under the very some terms".

If you'll show me bazillion of companies which complied with GPL WRT to linux kernel but were still hurt by SFC then I'll take all my words back and readily admit that SFC really goes to far. So far I've not seen even one such company.

About the calculus for the project

Posted Feb 10, 2012 20:09 UTC (Fri) by dlang (guest, #313) [Link] (8 responses)

so if toybox can run on BSD it's legal, but if it only runs on linux it's a circumvention tool and illegal

suuuuure.....

About the calculus for the project

Posted Feb 10, 2012 20:26 UTC (Fri) by khim (subscriber, #9252) [Link] (7 responses)

so if toybox can run on BSD it's legal

Oh no. To make it run on BSD is only a first step. Then you need to convince people to actually use it in such configuration :-)

If BSD port will just be a curiosity then court will [rightfully] say that it's existence is just a window dressing. Napster was capable of commercially significant non-infringing use - yet it was not enough, after all. But if BSD port will be used often enough then, sure, it'll mean that toybox relicense happened for other reasons besides copyright infringement facilitation.

but if it only runs on linux it's a circumvention tool and illegal

Again: nope. It's only illegal if it's only runs on linux and if a lot of companies continue to use it to violate GPL license for Linux kernel in [relative] safety.

We'll see what happens. Perhaps now, when toybox is available and SFC can not use busybox to sue shady contractors, they will suddenly wise up and all start voluntarily comply with GPL license for kernel or may be they all will switch to BSD... but I somehow doubt it'll happen.

About the calculus for the project

Posted Feb 12, 2012 16:55 UTC (Sun) by landley (guest, #6789) [Link]

> > so if toybox can run on BSD it's legal
>
> Oh no. To make it run on BSD is only a first step. Then you need to
> convince people to actually use it in such configuration :-)
>
> If BSD port will just be a curiosity then court will [rightfully] say

*plonk*

Rob

P.S. http://lmgtfy.com/?q=plonk+usenet

About the calculus for the project

Posted Feb 12, 2012 18:59 UTC (Sun) by armijn (subscriber, #3653) [Link] (3 responses)

So reimplementing standard UNIX commands under a BSD license if they only run on Linux is illegal? You lost me.

About the calculus for the project

Posted Feb 12, 2012 19:17 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

The license under which you develop you software has nothing to do with legality of such activity as I've already explained.

If this project is supposed to solve problem of GPL copyright violation in one way or another (or if it's created to solve some other problems, not related to licensing at all) - then it's good, lawful project. If it's goal is to conceal an infringement - then it's illegal.

Now, it's easy to claim "out goals are noble and if someone will use our work for unlawful purposes then it's not our problem", but this defense will fly only if statistic will support you. If most users of your project are using it to violate rights of someone else (for example Linux kernel developers) then you'll find yourself in a hot water no matter what you'll say. Napster is prime example - and law only becomes strict over time. ACTA is just the last step on this road - and I doubt it's the final one.

The real irony here lies in the fact that SONY which pushes this expansion in the capitol and SONY which tries to "solve" it using morally-questionable tricks like relicensed toybox are the same entity - yet the logical solution (stop trying to stretch power of copyright any further) is somehow not even considered.

About the calculus for the project

Posted Feb 13, 2012 8:18 UTC (Mon) by bronson (subscriber, #4806) [Link]

> If it's goal is to conceal an infringement - then it's illegal.

That's obviously not its goal.

And, even if it were, it still wouldn't be illegal. If you disagree, please state your case law. Napster is only relevant as a trivial example of failing "significant non-infringing" and has nothing to do with software licensing.

About the calculus for the project

Posted Feb 13, 2012 22:15 UTC (Mon) by docwhat (guest, #40373) [Link]

Huh? Your legal theory is pretty out there. Do you have anything to back this up? Anything at all?

About the calculus for the project

Posted Feb 12, 2012 22:57 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

claiming that software is illegal based on how some people (who aren't the authors of the software) choose to use it is a very dangerous thing to do.

This is exactly what the game console and big media companies are trying to do.

There's a very good reason that the "open source definition" requires that there be no limit on the field of use of software for a license to qualify as open source.

It's sad to see GPL proponents playing into their enemies hands by trying to declare competing software to be illegal.

About the calculus for the project

Posted Feb 13, 2012 0:05 UTC (Mon) by dlang (guest, #313) [Link]

this topic has now made it's way onto a very select list, the list of free software / open source related lawsuits that I would like to see happen on the basis that the people making the claim are doing enough harm with their FUD that a lawsuit to set a precedent would be a good thing.

About the calculus for the project

Posted Feb 9, 2012 22:42 UTC (Thu) by raven667 (guest, #5198) [Link]

> the goal of getting the most people to use the best software

That basically describes the BSD family of licenses. It's different than the reciprocity and community building goals of the GPL. For example OpenSSH is used in a number of proprietary systems (such as Cisco IOS) and the BSD TCP/IP stack is used in many places (such as Windows). For large multi-vendor projects reciprocity is very important to encourage sharing otherwise each vendor is unlikely to share and will have their own, incompatible, proprietary fork with a weak central community. Only if you are lucky do those useful proprietary features get rolled into the shared project.

About the calculus for the project

Posted Feb 27, 2012 23:32 UTC (Mon) by gdt (subscriber, #6284) [Link]

Cisco outsourced the old linksys Linux stuff to a taiwanese company after the first lawsuit, washed their hands of Linux...

Cisco is a big company and so generalisations like this are unwise. Cisco's next generation switch and router software uses Linux underneath, so Cisco's views on Linux are not as black and white as you portray.

About the calculus for the project

Posted Feb 1, 2012 21:47 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

"I believe eliminating the possibility of a license violation is a valid, although not ideal, solution. "

You can't do that. GPL still remains in play because everyone who ships busybox also ships the Linux kernel. It takes only one key kernel developer to ask SFC to represent them and you are back to the problem you are trying to get away from. I do wonder whether SFC or FSF would be sending kernel patches in key areas with the sole idea of using it to enforce the GPL at the kernel level directly instead of using busybox as a proxy. At the point, the violators can consider using a BSD kernel. It would be a interesting fight to watch.

About the calculus for the project

Posted Feb 2, 2012 8:54 UTC (Thu) by fb (guest, #53265) [Link]

> GPL still remains in play because everyone who ships busybox also ships the Linux kernel. It takes only one key kernel developer to ask SFC to represent them and you are back to the problem you are trying to get away from. I do wonder whether SFC or FSF would be sending kernel patches in key areas with the sole idea of using it to enforce the GPL at the kernel level directly instead of using busybox as a proxy.

Awesome. If that is the case, why are all this people decrying the possibility of losing their legal proxy?

Why make a big fuss if someone (actually the former Busybox maintainer) is working on a competing project?

About the calculus for the project

Posted Feb 1, 2012 22:19 UTC (Wed) by jonasj (guest, #44344) [Link] (1 responses)

> Matthew, in particular, keeps asserting that the real reason for
> this project is "to make it easier to infringe the kernel's
> license." This is simply not true."

You work for Sony, who thought it acceptable to install rootkits on their customer's machines. Why in the world would I trust a word you say?

About the calculus for the project

Posted Feb 1, 2012 22:28 UTC (Wed) by jonasj (guest, #44344) [Link]

Sorry to reply to myself but I feel I need to point out that I wouldn't be posting such a comment if it wasn't for the fact that your argument relies on your lack of trust in the SFC not to misbehave, which I just find incredibly hypocritical considering the organisation you're working for.

About the calculus for the project

Posted Feb 1, 2012 22:44 UTC (Wed) by marcH (subscriber, #57642) [Link] (2 responses)

> For a large company that is compliant with the GPL, the biggest worry is that a 3rd party (and a legally hostile one at that) would be given the right to review (and therefore delay) the shipment of its products.

It is really hard to feel sorry for a rich multinational company that skips mandatory legal checks in order to be first to market.

It then becomes much much harder to feel sorry when the very same company is lobbying hard to harden copyright law so teenagers illegally downloading music can be put in jail. Compared to this the SFC now look like very nice guys.

Note: this has nothing to do with the GPL. It's about software licensing and legal reviews *in general*.

About the calculus for the project

Posted Feb 9, 2012 21:35 UTC (Thu) by landley (guest, #6789) [Link] (1 responses)

> It is really hard to feel sorry for a rich multinational company that
> skips mandatory legal checks in order to be first to market.
...
> Note: this has nothing to do with the GPL. It's about software licensing
> and legal reviews *in general*.

A quote from: http://www.wired.com/wired/archive/11.11/linus_pr.html

"I do not look up any patents on principle because (a) it's a horrible waste of time and (b) I don't want to know,"

- Linus Torvalds.

Rob

About the calculus for the project

Posted Feb 12, 2012 15:35 UTC (Sun) by nix (subscriber, #2304) [Link]

Quite. Nobody ever looks up patents. Every large software company I have ever worked for specifically forbids its developers from doing patent searches without the cooperation of the corporation's top lawyer, which says something about how common they expect such things to be. (From asking a few such people, the number of patent searches they actually get asked to do by software developers is one or two a *year*. In large multinationals.)

About the calculus for the project

Posted Feb 1, 2012 23:39 UTC (Wed) by PaulWay (guest, #45600) [Link] (5 responses)

> But in terms of perceived cost, for Sony this would delay, and worse, add uncertainty to the release dates of hundreds of products each year.

So, what, GPL authors are supposed to shut up because they might be hurting the company?

That's a harsh way of saying: none of what you say about Sony's concerns have anything to do with what we, as a community of copyrighted code authors, choose to do with our rights. It is no more acceptable for Sony to ignore licensing of FOSS code than it is for them to ignore anyone else's copyright. If anything, the fact that they stand to lose heaps of money if products are late is reason enough for them to get it right the first time. Claiming that it's all very complicated because of sub-contractors and different divisions is about as valid as a child blaming the broken plate on their invisible friend.

Aren't Sony one of the companies that are pushing for tougher penalties when people infringe their copyright? The whole point of a penalty is to provide a disincentive to infringement. At that point it should be a very simple business decision: a potential loss of millions of dollars in lost revenue due to a delayed product, or a certain loss of even more when they are found to be violating their software licenses, get fined for it _and_ have their devices delayed even further. That a company can then choose the latter option shows that they actually think that they can get away with it - their 'calculus' is based on the flawed assumption that the cost of non-compliance is less than the cost of compliance.

I'm not criticising you; I'm pointing out the hypocrisy of Sony's actions.

And I personally think the SFC saying "let us help you with getting all your licenses sorted out now", rather than waiting for compliance on BusyBox and then hitting them with the next lawsuit for the next GPL-violating thing they find, is doing the industry a massive favour. There's already enough legal shenanigans in the computer industry, with companies waiting until the ideal time to hit their competitors with lawsuits.

Ultimately, what galls me here is that Sony isn't ponying up the developers to actually write the bits of Toybox that they want, or even implementing their own BusyBox replacement if they like. They're expecting other people to do the work for them, then they come in and use it for free. All that buys them is a little bit of time: eventually the kernel community will start to enforce its copyrights and the fight will really be on. Either they need to start rewriting everything from scratch, or just harden up and comply with the licenses of the software that they use.

Have fun,

Paul

About the calculus for the project

Posted Feb 1, 2012 23:49 UTC (Wed) by tbird20d (subscriber, #1901) [Link] (4 responses)

Ultimately, what galls me here is that Sony isn't ponying up the developers to actually write the bits of Toybox that they want

I've already contributed personally to the code.

About the calculus for the project

Posted Feb 2, 2012 0:56 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

Personally as in, your own time or Sony? If Sony is supporting the project, you can't deflect criticism directed at Sony for exhibiting a level of hypocrisy. If it is your own time, the original criticism you are responding to, is still valid.

About the calculus for the project

Posted Feb 2, 2012 1:13 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)

Except that, as Tim said before, replacing Busybox is not (at this time) a Sony project. Tim has said this would be a good idea, not Sony. Most of us like to be seen independently of the shadow of our employers, at least some of the time; I think we can grant Tim that favor too.

In a sense, Rahul, this is like us giving Red Hat grief for supporting rpmfusion - or not supporting it.

About the calculus for the project

Posted Feb 2, 2012 1:51 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

I am very well willing to grant the favor to Tim but I want to clarify the details first. If Tim is working on behalf of Sony or if Sony is permitting Tim to work on this project during work hours, then regardless of whose project it is, there is a association which cannot denied and hence the action of the company reflects on the individual or vice versa.

If Tim is working on his own time, then of course, his association with Sony is not as relevant to this discussion but one cannot have it both ways.

About the calculus for the project

Posted Feb 9, 2012 21:48 UTC (Thu) by landley (guest, #6789) [Link]

> Personally as in, your own time or Sony?

Tim's own time:

http://landley.net/hg/toybox/rev/413

He credited his employer, but that's not unusual:

http://landley.net/hg/toybox/rev/436
http://lists.uclibc.org/pipermail/uclibc/2006-July/016032...

What exactly is the logic here in objecting, by the way?

"Oh no, Sony is sponsoring new open source code under a license that would allow the code to be used in the Linux kernel itself! Horrors!"

"Oh no, the guy who started the BusyBox lawsuits in the first place is rendering them irrelevant!"

"Oh no, people are writing BSD licensed command line utilities because w'eve never seen THAT before..."

"Oh no, this code may be actually better than BusyBox and intends to compete on the technical merits and win!"

Rob

(Sheesh, I mothballed the toybox project a couple years back because I didn't think beating busybox on technical merit was _enough_ to displace an entrenched competitor with a 10 year headstart, including several years of my own work. But I wouldn't have bothered in the first place if I didn't think I could do a better job on a purely engineering level.)

About the calculus for the project

Posted Feb 1, 2012 23:51 UTC (Wed) by i3839 (guest, #31386) [Link] (16 responses)

Your arguments sound reasonable, but are rubbish:

Replacing GPL software is harder than just complying with the GPL.

For both approached you need to know which software is GPL and do something specific. All the whining about "we didn't know we were shipping GPL stuff" isn't solved by replacing known GPL stuff with something else. It's always the unknown stuff that bites you, whether GPL or proprietary.

So this doesn't solve any compliance problems except with Busybox itself. But as said above, complying is easier than replacing Busybox when you're already using it, so the only reason to replace Busybox would be because they don't want to comply with the license. Matthew is right to say this stinks, because it does.

About the calculus for the project

Posted Feb 3, 2012 0:24 UTC (Fri) by marcH (subscriber, #57642) [Link] (15 responses)

I think you missed one case: they don't know wether some of their contractors used a modified busybox and which contractors, but they know it is quite likely.

About the calculus for the project

Posted Feb 3, 2012 2:56 UTC (Fri) by i3839 (guest, #31386) [Link] (14 responses)

If you can't find Busybox, you can't replace it either. If you can find it, then you can compare the source to the official one and check if anything was modified. That's just one diff. If that is too much, just tar it up as it is and provide that to comply with the license. But finding a stolen Busybox and either not removing it immediately or not immediately complying with its license is plain wrong.

Knowing that some subcontractor somewhere violates copyright doesn't help to solve the problem if you can't find out which software that is. If you have no access to your own device's source code you're totally screwed, one way or the other. How can you check your (sub)contractor's work if you can't see what they did?

That companies want to avoid GPL software altogether in the future is something I can understand, especially with scare tactics like losing the license forever. The GPL is too often misunderstood, partly because of FUD. But that is only possible if they are in control of the software. If they are then they have no excuses at all to not comply with all licenses. If they aren't, then writing non-GPL replacement software won't change anything.

About the calculus for the project

Posted Feb 3, 2012 9:33 UTC (Fri) by marcH (subscriber, #57642) [Link] (13 responses)

I think you still do not get their approach. While I do not agree with it I do appreciate its logic. It seems to go like this:

1. We do not have time to ask/check what our dodgy contractors are doing, (incredibly wrong in the first place) but:
2. We know that dodgy contractors in general tend to have a strong taste for busybox.
3. Unlike other violations, busybox violations tend to be noticed by people (more thorough than us) and they often have consequences.

Solution: influence the "market" by creating an alternative to busybox attractive enough to be selected by dodgy contractors. This will *statistically* reduce the risk of being caught.

Not moral but perfectly logical.

Think of a prepared food producer trying to introduce stricter farming regulations - even when not doing any farming itself (except this one is of course more likely to be moral).

Wrong anology

Posted Feb 3, 2012 10:45 UTC (Fri) by khim (subscriber, #9252) [Link]

Think of a prepared food producer trying to introduce stricter farming regulations - even when not doing any farming itself (except this one is of course more likely to be moral).

Nope. Stricter farming regulations will be requirements to send the GPL code along with busybox binaries. What happens here is the coercion to replace products produced by farmers with concoction of flavour enhancers potent enough to cover the odour of rotten meat.

Not moral but perfectly logical.

Yup. The same as with food producers. Yet somehow aforementioned practice is universally despised while similar deal WRT software is supposed to be applauded.

About the calculus for the project

Posted Feb 3, 2012 18:30 UTC (Fri) by raven667 (guest, #5198) [Link] (6 responses)

> 1. We do not have time to ask/check what our dodgy contractors are doing, (incredibly wrong in the first place)

I think that is a mischaracterization of the stated concern, its not that they are being willfully ignorant of their suppliers its that in a large organization it's easy for some team to accidentally distribute pirated software by not doing due diligence on the vendor (or the vendor lying). The belief, right or wrong, is that a hostile copyright owner could cause a lot of trouble so to reduce this risk they are going to work on liberally licensed software that they own the copyrights on so that the components they maintain don't have piracy issues and presumed-hostile copyright owners.

Maybe Bradly Kuhn is some moustache twirrling ogre who's just itching to screw over some poor defenseless large manufacturer, the people involved probably know better than I, but I don't see any evidence in the publicly available information to support that hypothesis.

About the calculus for the project

Posted Feb 3, 2012 23:33 UTC (Fri) by marcH (subscriber, #57642) [Link] (5 responses)

> > 1. We do not have time to ask/check what our dodgy contractors are doing, (incredibly wrong in the first place)

> I think that is a mischaracterization of the stated concern, its not that they are being willfully ignorant of their suppliers its that in a large organization it's easy for some team to accidentally distribute pirated software by not doing due diligence on the vendor (or the vendor lying).

I think this is an overly nice way to say the exact same thing.

You MUST carefully select and watch your suppliers, period. Make sure they have a good reputation, tie them in very strict contracts, make sure they are too big too fail (and can pay you any damages back), force them to give you their source code and audit it yourself... this is really just business 101. If the managers of your company cut corners on business 101 in order to be first to market, then I sincerely hope your company dies in copyright litigations (GPL or else) because for sure my company forces us to be thorough and extremely careful, which obviously has a cost, and I would hate you beating us on the market because of that.

[Don't take it personally: it was just easier to give you the role of the bad guy]

> "Hostile Copyright Owner"

Too bad neither Hollywood nor the BSA never cared educating the masses with this new and interesting "HCO" concept.

Anyway I agree with i3839 to some extend. Even assuming that the most HCO owns and defends busybox today and that busybox gets successfully replaced, the most HCO will be someone owning something else in one year time and back to square one.

About the calculus for the project

Posted Feb 4, 2012 14:51 UTC (Sat) by marcH (subscriber, #57642) [Link] (4 responses)

And by the way... http://queue.acm.org/detail.cfm?id=2030258

"Some say the only two products not covered by product liability today are religion and software. For software that has to end;"

"If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then the builder shall be put to death." (Hammurabi's Code, approx. 1700 BC)

About the calculus for the project

Posted Feb 5, 2012 12:35 UTC (Sun) by alankila (guest, #47141) [Link] (3 responses)

I was already ready to say that if such a rule would come to govern free software, then all software I would ever release, regardless of its purpose, would be strictly anonymous and in public domain, because it would be very hard to accept any kind of personal liability for software given out for free.

Then I read the link and observed it advocates liability only for closed source software, where the author of the software must be trusted, and eliminates it for software with source code, where the user could (in theory) become fully informed consumer of the software product.

business

Posted Feb 6, 2012 9:03 UTC (Mon) by marcH (subscriber, #57642) [Link] (2 responses)

Another quote from the same article:

"if you make MONEY selling something, you'd better do it properly, or you will be held responsible for the trouble it causes" (emphasis is mine).

It's really more about *business* rather than closed source. If you sell open source then you are accountable (or should be). If you give closed source software for free then you should not. In the latter case you typically do not even know who is using the software and for what.

business

Posted Feb 6, 2012 11:31 UTC (Mon) by alankila (guest, #47141) [Link] (1 responses)

I think there's no point to make it hinge on money exchanging hands, especially as a liability rule such as this would lead to it being a standard practice to obfuscate this sort of liabilities.

business

Posted Feb 6, 2012 16:47 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

The reason money is a factor (AFAICT) is that in many cases your liability is limited to what you were paid for the product. Ergo, if you give something away for free, your liability is minimal, whereas if you sell it, your liability could potentially be greater than your net profits.

About the calculus for the project

Posted Feb 9, 2012 22:03 UTC (Thu) by landley (guest, #6789) [Link] (4 responses)

Heh. Dodgy contractors.

I worked at a place that checked all the source code into horrors like "Accurev", "Rational", or whatever that one beginning with a P is I've blotted out. Starting with a tarball (no history beyond that) and checking in local changes on top of that.

Then the _fun_ ones go on to check the _result_of the build into a _second_ source control system, populated entirely with binaries and tracking the root filesystem layout (or RPM binaries, or whatever they ship).

Impedence matching between the first source control system and the second source control system is entirely ad-hoc. Bonus points if they're different technologies left over from a department merger and/or partial migration that never removed the "legacy" system. (Adding new one in parallel: easy. Removing old one: hard.)

I didn't fight with this stuff in a license enforcement context. I fought with it in a "I'm working a 3 month contract to fix accumulated customer bugs in a legacy system they've forgotten how to _build_. They have partial source code for their product, but no longer have the context it built in and the people who did this moved on years ago" context.

It's lucrative, yet horrible. (I remember a contract at Dell where they paid Red Hat to support Red Hat Enterprise 2 _after_ it was end of lifed because they'd done shared libraries in C++ which did an "extern C" around all their library exports and then returned a pointer to a class instance, so all the funky name mangling changes between gcc versions bit them on the nose and they either had to upgrade bangalore, raleigh, and austin all at the same time _and_ ship a flag day release to all customers (of this funky high-end SAS array diagnostic/monitoring tool) or stick with the old compiler forevermore. They got _into_ that state because nobody had realized the full ramifications of their build. Getting a handle on the real dependencies and reproduction sequence of modern software builds is _hard_, at least when the FSF was ever involved in any way. Grub 2. *shudder*)

The real world is messy. This is not new. You're talking about BusyBox, a project that at one point had FIVE shell implementations that didn't share code. If _we_ couldn't get that cleaned up in the first decade of the project's existence, why the heck are you holding others to a higher standard?

Rob

About the calculus for the project

Posted Feb 10, 2012 14:30 UTC (Fri) by marcH (subscriber, #57642) [Link] (3 responses)

If your company is messy and messes with licensing then it deserves to die under lawsuits initiated by "Hostile Copyright Owners" (tm). Sooner is better: makes room for slower but more serious companies (like mine). Special bonus points if said company lobbied hard to harden copyright laws.

This is just natural selection. Bye. It will incidentally make room for higher quality software and more interesting jobs - I'm sure you will like it.

This might delay a bit the release of the next great smartphone/set top box/you name it - we will all survive.

Poor attempts to ask the "community" to rewrite this or that piece under a BSD license for you are laughable and you will buy very little time (assuming they succeed in the first place).

Once again: nothing GPL-specific in the above.

About the calculus for the project

Posted Feb 10, 2012 16:11 UTC (Fri) by landley (guest, #6789) [Link] (1 responses)

"s/copyright/patent/"

Let the backpedaling commence.

About the calculus for the project

Posted Feb 10, 2012 16:45 UTC (Fri) by marcH (subscriber, #57642) [Link]

> "s/copyright/patent/"

No.

The copyright system is not perfect and probably too hard but it's fair and basically working. The current patent system is completely broken and totally unfair.

Imagine you write some code, then I copy and massage a few lines of it and bang I get the copyright on the whole thing. This is how the copyright system would look like if it were managed by the USPTO.

About the calculus for the project

Posted Feb 12, 2012 15:44 UTC (Sun) by nix (subscriber, #2304) [Link]

Well, yes, except that *all* companies rapidly become a bloody mess because of accumulating history and staff turnover. It's impossible to keep in license compliance as long as any staff can drop off the face of the earth with a month's notice without documenting anything or ever communicating with the old workplace again (and, alas, that has been the tradition everywhere I've ever worked: they've routinely been shocked when I've presented them with an email address they can send queries to, FFS. Is supporting your own old stuff so radical? Apparently it is, to many people.)

So the real problem is FUD?

Posted Feb 2, 2012 1:29 UTC (Thu) by neilbrown (subscriber, #359) [Link] (4 responses)

If I understand you correctly, the real problem here is FUD.

Companies want to comply and try to comply, but there is uncertainty and doubt as to whether they will do so successfully and fear of the possible costs imposed to restore their license.

Does the GPLv3 address this? It gives a guaranteed re-instatement if you become compliant with 30 days (as long as you aren't a repeat offender). Is that enough to reduce the FUD?

That wouldn't help with BusyBox or Linux as they are v2 only, but maybe understanding if the v3 clause is helpful would give us a better perspective on the issues.

So the real problem is FUD?

Posted Feb 2, 2012 1:36 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

GPLv3 bring in several other clauses that cause even more fear.

Plus how is 'repeat offender' defined? for a large company, it's very possible for the company as a whole to trigger the 'repeat offender' clause, even if everyone who ever does something wrong never does it again (if nothing else, large companies acquire other companies, and employees at these newly acquired companies may not be doing everything per the polices of the big company)

So the real problem is FUD?

Posted Feb 2, 2012 1:40 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

I don't see any notion of repeat offenders in

http://www.gnu.org/licenses/gpl-3.0.en.html

So the real problem is FUD?

Posted Feb 2, 2012 1:44 UTC (Thu) by neilbrown (subscriber, #359) [Link] (1 responses)

Third paragraph of section 8.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

Only applies "first time" for each copyright holder.

So the real problem is FUD?

Posted Feb 2, 2012 10:14 UTC (Thu) by khim (subscriber, #9252) [Link]

Note that this clause is triggered only if copyright holder notifies you. If someone else finds out you are using GPLv3 product incorrectly (something like casual "I see you are offering special version of GCC in your SDK, but I don't see neither source nor a way to request said sources") and you react accordingly ("Oh, you know, we just forgot to upload them, can you wait a few days?") then license is reinstated without any strings attached. You can make mistakes as many times as you want till the actual copyright notifies you of the violation by some reasonable means.

About the calculus for the project

Posted Feb 2, 2012 4:24 UTC (Thu) by Company (guest, #57006) [Link] (42 responses)

What you are saying and what other people don't understand is that Sony does not care about legality (or legitimacy) of its actions at all. Sony solely operates on risk.

So the only thing Sony does when picking the software to ship is doing a cost/benefit analysis. If the potential price for lawsuits or the risk of shipping late is too high, you pick something else.

This behavior explains very well why the company you identify with would select to install rootkits or litigate children into jail. It also explains why it would rather not have license enforcement actions.

And what this actually means is that the correct thing to do to spread the GPL over the BSD is to start sueing companies for failing to print the BSD disclaimer. Even if that doesn't really achieve anything for Free software directly, it would increase Sony's perception of risk for using BSD licensed software and make it flock to the GPL.

Did I get that right?

About the calculus for the project

Posted Feb 2, 2012 4:35 UTC (Thu) by tbird20d (subscriber, #1901) [Link] (41 responses)

Did I get that right?

No. We have extensive mechanisms in place for compliance, for both business and moral reasons.

About the calculus for the project

Posted Feb 2, 2012 10:18 UTC (Thu) by jospoortvliet (guest, #33164) [Link] (40 responses)

So then the real problem is that you're so afraid of making a mistake in your compliance procedures (despite believing they are quite good) and getting sued the sh*t out of you by SFC that this project was started?

I personally find it very hard to believe that they would go after Sony, which, as you say, has a website with FOSS code, a contact point and proper procedures. There are much bigger fish to fry... But you could simply talk to them, ask what room you have for mistakes?!?

About the calculus for the project

Posted Feb 2, 2012 18:59 UTC (Thu) by tbird20d (subscriber, #1901) [Link] (39 responses)

I don't think they'll come after Sony. This seems to keep coming up, so I've addressed it in the FAQ for the proposal.

About the calculus for the project

Posted Feb 3, 2012 11:01 UTC (Fri) by fb (guest, #53265) [Link] (38 responses)

Hi,

I would like to point an issue which I missed in this discussion so far.

I will refrain from naming my current and previous employers because they have nothing to do with my opinions.

Regardless of whether SFC sues people over Busybox or not, as a proxy or not, I see the existence of a BSD/Apache licensed package as a positive thing. At my previous job, I wrote 'closed' source code[*]. The (rather large, think Sony-size) company had strict license compliance measures. At least in my division, any software not written internally had to get approval from 'legal' to ship. As it happens only BSD/Apache licensed code would get approval.

People may campaign and cheer the (L)GPLv[23] as much as they wish, but the *reality* today is that many companies will -for whatever reasons- simply not touch anything with GPL on it.

So I see Toybox as a positive development because strictly complying companies may end up having it as a resource, and open-source will IMO reach further than before. People may make a fuss, "oh, but there is no reason not-to-use-the-gpl". In reality writing Toybox seems more doable than changing some written-in-stone legal policies.

[*] I now work full time writing Apache licensed code :-P and yes at my previous job, we did submit every little patch we made on Apache code to "upstream".

[...]

On a personal note, I really never thought I would see a discussion at LWN where people would be arguing in favour of software scarcity.

About the calculus for the project

Posted Feb 3, 2012 18:53 UTC (Fri) by raven667 (guest, #5198) [Link] (1 responses)

> People may campaign and cheer the (L)GPLv[23] as much as they wish, but the *reality* today is that many companies will -for whatever reasons- simply not touch anything with GPL on it.

There is certainly some outreach that should continue to be done, sometimes the GPL is rejected because of fear and misunderstanding of what the license actually says and means. I get the sense that the Android core developers have some funny ideas about how the GPL works. Other companies prefer to contribute to GPL projects rather than BSD because the reciprocity means that they are always on a level competitive playing field. Very few business would be comfortable with all of their hard work feeding in a one-way direction to their largest competitor.

About the calculus for the project

Posted Feb 3, 2012 19:37 UTC (Fri) by khim (subscriber, #9252) [Link]

Very few business would be comfortable with all of their hard work feeding in a one-way direction to their largest competitor.

Yup. Google is the process of discovering that. Via Android (see Kindle Fire and Nook Color), via Chrome (see chrome.yandex.ru)... We'll see what it'll do.

About the calculus for the project

Posted Feb 3, 2012 22:11 UTC (Fri) by jimparis (guest, #38647) [Link] (34 responses)

> many companies will -for whatever reasons- simply not touch anything with GPL on it.
...
> In reality writing Toybox seems more doable than changing some written-in-stone legal policies.

Busybox only works with Linux. Linux is GPL. You can't have it both ways -- either you're violating the license of Linux, or your company's legal department is already fine with following the GPL.

About the calculus for the project

Posted Feb 3, 2012 22:38 UTC (Fri) by tbird20d (subscriber, #1901) [Link] (32 responses)

either you're violating the license of Linux, or your company's legal department is already fine with following the GPL

This is not a correct dichotomy. Many companies are fine following the industry consensus interpretation of the GPL, but have difficulty with the interpretation of the GPL by the busybox litigators.

A consistent meme in this discussion is that the motivation for this project is only because busybox is the only actively enforced component. I keep pointing out a different motive - and it keeps getting ignored and rejected, which is a bit frustrating. It's really because some of the interpretations of the GPL (like the death-clause and scope of remedies) by the SFC appear to me to be counterproductive.

I'm entirely comfortable dealing with gplviolations.org, or the kernel community - not because either of these other parties are lax in their enforcement (although admittedly the kernel community appears lax), but because I trust their interpretation of the GPL more, and their reasonableness about rectifying mistakes.

About the calculus for the project

Posted Feb 3, 2012 23:29 UTC (Fri) by jimparis (guest, #38647) [Link] (31 responses)

> A consistent meme in this discussion is that the motivation for this project is only because busybox is the only actively enforced component. I keep pointing out a different motive - and it keeps getting ignored and rejected, which is a bit frustrating. It's really because some of the interpretations of the GPL (like the death-clause and scope of remedies) by the SFC appear to me to be counterproductive.

It is a consistent meme because they hardly seem independent. You are asking us to believe that a difference in "interpretation" is the reason for Toybox, and its creation is in no way related to the fact that the SFLC will sue you when nobody else will. That's just hard to swallow, from the point of view of the open-source community that has traditionally had a very hard time getting companies to follow the license.

> I'm entirely comfortable dealing with gplviolations.org, or the kernel community - not because either of these other parties are lax in their enforcement (although admittedly the kernel community appears lax), but because I trust their interpretation of the GPL more, and their reasonableness about rectifying mistakes.

As you say, they are lax. Neither gplviolations.org nor the kernel community have ever taken anyone to a US court. I'm just not convinced that your trust in "their interpretation" and "their reasonableness" is not at all affected by the fact that they have demonstrated no legal teeth.

Let's say you have a habit of "borrowing" things without permission, never with bad intentions. Of course you'd rather borrow from your kind neighbor who, upon catching you, says "Hey, that wasn't nice" and asks for it back. You don't like borrowing from the other grumpy neighbor who calls the cops right away. You make a big fuss to make sure everyone knows that you got your own lawnmower and will no longer need to borrow the grumpy neighbor's, because hey, he was totally unreasonable to call the cops on you. Then the kind neighbor says "You know, you should just stop borrowing our stuff without permission in the first place" and you say "Come on! That grumpy guy was a total jerk. This has nothing to do with my borrowing, just his interpretation of property law."

If you want a new lawnmower, that's fine. But you shouldn't use it as an excuse to bash on the grumpy guy, and don't be offended when the nice neighbors also use this opportunity to complain about how they're being treated and how you're not doing them any favors.

I'm just a bystander. My point of view may be entirely wrong. Maybe the threat of being sued truly has no effect on your or Sony's views of Busybox. Maybe the SFLC does act unreasonably even when there was a honest mistake somewhere in the supply chain. But I've seen no evidence of that.

About the calculus for the project

Posted Feb 4, 2012 0:29 UTC (Sat) by tbird20d (subscriber, #1901) [Link]

You make a big fuss to make sure everyone knows that you got your own lawnmower

No. I didn't announce this project, Matthew Garret did, for his own purposes. He incorrectly attributed the motivation for this to my employer, which I felt needed correcting. People's own biases have led to a lot of name-calling and fingerpointing and outrage. I'm not trying to rub anyone's face in anything. I've tried to explain my own motivations, and I've been called a liar numerous times.

If you don't trust me, I get it. You can think whatever you like. I would address your mower metaphor, but it seems pointless since people are obviously disposed to distrust what I say, and I've been over it already.

About the calculus for the project

Posted Feb 4, 2012 0:41 UTC (Sat) by dlang (guest, #313) [Link] (27 responses)

> It is a consistent meme because they hardly seem independent. You are asking us to believe that a difference in "interpretation" is the reason for Toybox, and its creation is in no way related to the fact that the SFLC will sue you when nobody else will. That's just hard to swallow, from the point of view of the open-source community that has traditionally had a very hard time getting companies to follow the license.

you may want to actually go look at toybox and it's creator (Rob Landley, a former maintainer of Busybox, and one of the plaintifs in many of the SFLC busybox lawsuits)

Rob has been working on the project since 2006, and it's only in the last few months that he changed the license on it from GPLv2 to BSD. Go back through his blog entries, he has been very vocal about toybox being worked on because he thinks that it is better than busybox. Yes, part of the reason is that he didn't want to give Bruce any possible claim over the code, and he doesn't like GPLv3, but it was worked on because he wanted it to be better than busybox.

Since toybox was a GPLv2 project for several years, it couldn't have been created to make it easy to bypass the GPL

Since toybox was created while Rob was a plaintif represented by the SFLC, it couldn't have been created because he was unhappy with how the SFLC was handling the lawsuits.

About the calculus for the project

Posted Feb 4, 2012 0:46 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

Tim contacted Rob asking him if he'd be interesting in working on a liberally licensed Busybox clone. Rob's clearly working on Toybox for his own reasons, and I think they're all perfectly justifiable. Tim's interest in it is another matter.

About the calculus for the project

Posted Feb 4, 2012 1:10 UTC (Sat) by khim (subscriber, #9252) [Link] (25 responses)

you may want to actually go look at toybox and it's creator (Rob Landley, a former maintainer of Busybox, and one of the plaintifs in many of the SFLC busybox lawsuits)

I have no problems with Rob's work.

Since toybox was a GPLv2 project for several years, it couldn't have been created to make it easy to bypass the GPL.

Of course not. It was only co-opted for that purpose.

The evidence is damning: On an engineering note, they never contributed a single line of code to BusyBox. NOT ONE. I thought they would, but they didn't, so I stopped pursuing them.

What does it say to you? Two things.
1. That future lawsuits will probably not bring new enhancements for busybox.
2. It's not simple to comply with busybox's license. It's trivial.

OEMs don't really change busybox code thus it's enough to just call busybox --version, download tarball from the official site and you can recreate binary.

Now, we have two pieces of software (busybox and Linux kernel). One is 100 times more complex and 1000 times more often modified in practice by OEMs. And someone want to replace the simplest half of the pair - with the explicit goal to STFU the guys who use it as a proxy to get sources for the more interesting part. What does it say about the possible goals?

In fact SONY and others stretched copyright so much that you can argue that project under discussion is doing is most probably flat out illegal. Because in 99% of cases it'll be used as a means to facilitate copyright violation. This fact was enough to kill Naster, why should it be ignored in this case?

About the calculus for the project

Posted Feb 4, 2012 1:25 UTC (Sat) by dlang (guest, #313) [Link] (23 responses)

you say

> I have no problems with Rob's work.

but then you say

> that project under discussion is doing is most probably flat out illegal.

but you are talking about exactly the same project, Rob's toybox project.

which is it, Rob's project is Ok, or Rob's project is illegal?

you can't have it both ways.

About the calculus for the project

Posted Feb 4, 2012 11:21 UTC (Sat) by khim (subscriber, #9252) [Link] (22 responses)

you can't have it both ways.

Yes, I can.

> I have no problems with Rob's work.

Check the first world: I. I, personally, have no problems with Rob's work - but then I'd prefer world where copyright is much less powerful (or where it does not exist at all, as I've already said).

> what that project under discussion is doing is most probably flat out illegal.

But Disneys and SONYs of our world prefer not just strong, but superstrong copyright. They lobby for extensions in congress, they constantly try to straighten it in lawsuits, etc. IMNSHO (as Napster story showed) they already inflated power of copyright so much that that what Tim is doing is most probably illegal because that feature would have no commercial value without the non-infringing product.

but you are talking about exactly the same project, Rob's toybox project.

Nope. Rob's project used GPL and as such for not usable for Napster-style copyright indictment. Because it was just practically impossible to use it without violating both license of kernel and license of toybox. What Tim did is convinced Rob to change license - and this made toybox mostly useful as a facilitator of infringement of Linux kernel copyright.

Right now it's a theory - and not very solid at that. We'll need more evidence before it can be tested in court. If most toybox users will nonetheless diligently ship sources of Linux kernel (this is what Tim explains what is the goal of project: industry guys are quite Ok with GPL compliance and only want bisybox replacement to avoid pesky SFC) - then this theory will evaporate in a puff of smoke. If most users will infringe on Linux kernel copyright then aforementioned theory will be straightened enough to question the legality of initial Tim's work, too.

I just want to point out that SONY, too, can not have it both ways: it can not push to expand copyright power endlessly and at the same time expect that it'll not be affected by said expansion on the other front where it's not plaintiff, but defendant. Right now the coin is in air and how it'll land depends on future actions of chip vendors and suppliers. As well as on the future actions of Tim itself: he can claim that toybox is just first step and chip vendors and suppliers plan to replace Linux kernel, too (this will close this problem once and for all), but then he should show come concrete steps in this direction to convince court that it's all is not just "smoke and mirrors".

BSD-relicensed (that's important) toybox looks very much like Napster-style copyright infringement facilitator.

About the calculus for the project

Posted Feb 4, 2012 19:04 UTC (Sat) by alankila (guest, #47141) [Link] (20 responses)

I'm going to eradicate the context: you are basically advancing a theory which states that relicensing one software from GPL to BSD is illegal because some completely unrelated GPL-licensed software's license can then be violated without legal consequences?

I think such a theory would be laughed out of any court. If licenses are being violated on some piece of software, then let those who have the authority sue if they choose to. If the kernel people do not feel like suing, then it does seem questionable to me that busybox people feel like they have the right to impose settlement conditions on the kernel because of violations on busybox.

Secondly, GPL does not have so much leverage as it once seemed to: there appears to be not-GPL replacements for most if not all the pieces of the system software stack today. I'm sure that changing from Linux to some other kernel would be a tough engineering effort, but scaring enough companies with GPL threats could make them band together and start a replacement effort on some other kernel (bsd?). In the end, if all GPL-licensed software becomes replaced then the legal theory you are advancing will fail too, because there is no GPL-licensed software left whose license could be violated.

About the calculus for the project

Posted Feb 4, 2012 21:22 UTC (Sat) by khim (subscriber, #9252) [Link] (19 responses)

I'm going to eradicate the context:

Which will make the further discussion pointless.

Eben Moglen said it best here:

It generally turns out, as I know from having spent almost a quarter of a century now as a lawyer for hackers, that when hackers pretend to be lawyers, there are certain predictable formulations that they come to; they assume a degree of consistence in legal rules that is not achievable; this is a primary problem which occurs particularly in US focused conversation, such is that in Debian Legal, where the libertarian demand for intellectual consistency, and the hacker belief that laws are form of code that are executed without errors or ambiguities, joins together to create a particular frame of analysis for legal questions.

It doesn't work very well for me as a lawyer, I think it doesn't work very well for lawyers elsewhere in the World, because the one thing which lawyers around the world all share is an awareness of the squishiness of law, it is by no means the hard arthropod carapace for internal soft organs that non-lawyers have a tendency to assume it is....

Context is everything when law is concerned. The very same actions can be interpreted radially differently in court - depending on the context. That's why you can not just grab random pieces of legal advice and use them in court and that's why legal advice is so costly in general: it must be fine-tuned for your particular case.

If licenses are being violated on some piece of software, then let those who have the authority sue if they choose to.

Oh, sure. Only copyright holders of the code in kernel can ever sue Tim. I and you can not (unless you own significant chunk of kernel code, that is). At least that's the situation today. It may change tomorrow.

If the kernel people do not feel like suing, then it does seem questionable to me that busybox people feel like they have the right to impose settlement conditions on the kernel because of violations on busybox.

Sure. But when they will finally decide to sue they may decide to sue not just people who violated their copyright, but the people who've facilitated infringement of said copyright. And if it will be found that toybox is mostly used by sleazy companies to continue to violate kernel's copyright... well, at this point the project in question can found itself in hot water. Note: it all will depend on how far companies will stretch copyright in their efforts to provide adequate legal protection and effective legal remedies against any person knowingly performing without authority any of the following acts knowing, or with respect to civil remedies, having reasonable grounds to know, that it will induce, enable, facilitate, or conceal an infringement of any copyright or related rights. Looks like Disneys and SONYs of the world are quite serious which means that while what Tim is doing today is still legal (even if morally questionable) it may become illegal tomorrow!

Secondly, GPL does not have so much leverage as it once seemed to: there appears to be not-GPL replacements for most if not all the pieces of the system software stack today.

Indeed. As I've said already if toybox will be mostly used in combination with some kind of BSD kernel then the aforementioned theory will evaporate in a puff of smoke. We'll see.

In the end, if all GPL-licensed software becomes replaced then the legal theory you are advancing will fail too, because there is no GPL-licensed software left whose license could be violated.

Sure. If the project in question will be expanded to cover all the GPL-licensed code typically used by shady contractors and if GPL code will be eradicated as result then it'll be different story entirely. But so far it does not look like port of toybox to other kernels is even considered - and this puts the whole effort squarely in the "copyright facilitator" bin.

About the calculus for the project

Posted Feb 5, 2012 11:12 UTC (Sun) by rahvin (guest, #16953) [Link] (10 responses)

An interesting argument I hadn't considered. In the interest of adding to your supposition I'll add the following. The theory of copyright infringement facilitation without engaging in actual infringement yourself has been used successfully in court several times in the US.

As you mention the first use was the Napster case that resulted in the entire company getting shut down. But there have been other cases, such as Limewire, Grokster and several other smaller players. In all the previous cases it was a civil lawsuit and involved the argument that centered around contributory copyright infringement and resulted in millions of dollars of damages. Most of the cases were appealed all the way to the Supreme and as such have established a fairly solid legal citation in future cases (baring a future reversal by the Supreme).

But more recently the MegaUpload cases presents a dramatic escalation in this with a criminal proceeding with racketeering charges tied in where the US government is seeking multiple years of jail time for the parties responsible. The theory you've presented is interesting because it's a well established precedent in US courts that contributory copyright infringement is a real and punishable offense.

The court verdicts to date have basically established the precedent that if the intent and use of the product was for the primary purpose of infringing copyright, even if there are legitimate uses that make up a small part of the use case, that the parties responsible are guilty of contributory copyright infringement for the behavior of their users. You have to wonder if these verdicts couldn't be stretched to extend to this situation. Although it'll be argued the intent wasn't to encourage GPL infringement (but to avoid a SFC legal action) by the people involved it should be fairly obvious that regardless, a significant number of people in the community and on LWN have interpreted the action to be an attempt to facilitate infringement and that this entire discussion would likely be used in the case, particularly the comments by those involved.

Would a GPL case extend to this level? I doubt it, but as you say history doesn't predict the future. With laws like SOPA in play an ambitious district attorney looking to get their name in the news could litigate a GPL case without the consent of copyright holder (one of the many scary clauses in the law).

An interesting hypothesis no doubt, thanks for posting it.

About the calculus for the project

Posted Feb 5, 2012 15:00 UTC (Sun) by khim (subscriber, #9252) [Link] (9 responses)

Now you can understand why I clearly distinguish Rob's work and Tim's work.

Rob just wrote yet another replacement for busybox - may be technically interesting, but legally pretty plain project. It used the same GPL which both busybox and Linux kernel are using thus it was not all that interesting from the legal perspective: yes, SFC had no way to enforce it's copyright, but thus was just Rob's goodwill, it was easy for him to change his mind at any time. Hardly a reason for a hypothetical sleazy company to be excited. And hardly anybody was excited: toybox was around for years but was mostly a curiosity not worth talking about much.

Tim, on the other hand, convinced Rob to change license and make it as close to public domain grant as possible. Now it becomes much easier to infringe on kernel's copyright. Tim even admits it's directly:
Q. Is this being done to prevent the SFC from asking for the source to the Linux kernel?
A. No, although it would have that effect. As part of their request to remedy a busybox GPL violation, the SFC does ask for source code unrelated to busybox. Personally, I believe this is improper. However, my main reason for proposing this project is to avoid having the SFC gain review authority over unrelated products produced by a company. The larger the set of Linux-based products that are produced by a company, the greater exposure there is for a possible mistake, and the greater potential costs that would incur in the event of litigation and/or settlement.
Of course he also continues with rhetoric that his goal is not to help copyright violators, etc, but... how much it helped other companies you've mentioned here?

About the calculus for the project

Posted Feb 10, 2012 0:18 UTC (Fri) by landley (guest, #6789) [Link] (8 responses)

No, Tim asked me if I knew anybody who'd want to work on extending Android's crappy Toolbox so people wouldn't need to replace it with software that can never ship as part of Android, due to Google's existing "no GPL in userspace" policy which most android vendors inherit:

http://source.android.com/source/licenses.html

_I_ am the one who brought up Toybox, and pointed out I already _had_ something that was way the heck ahead of Toolbox, and which I'd love an excuse to work on again.

And I have already been talking about the smartphone replacing the PC since BEFORE ANDROID EVEN EXISTED:

http://landley.net/notes-2010.html#09-10-2010

(The 2002 reference in that is about when I wrote an article on the topic for a now-defuct wesite called linux and main, I might be able to pull the article out of archive.org if I try. I note that Eric's objection was ergonomics would limit the usability of palm pilot and newton and such. There weren't any USB docking stations yet, but it seemed obvious to me that the problem would be solved, and that internet-through-cellphone was _compelling_. Yes, in 2002. And yes, I hit bad bufferbloat the first time I tried getting internet through my cell phone on Linux in 2001, I just had no idea what to _do_ about it and assumed I'd configured things wrong.)

I'm the one who made the connection that "Oh, if toybox was BSD licensed _that_ would give it a separate niche from busybox giving me an excuse to work on it without feeling like I was wasting my time, because android is a deployment platform that only bsd licensed code can fit in. And I could use that as leverage to steer android towards a more full-fledged posix environment, and from there it's a simple step towards leveraging my aboriginal linux project to make android self-hosting, and then android would have a leg up against the iPhone, which it's been losing to recently".

The enthusiasm was _mine_, because I saw a path forward I'd missed before, which Tim's agenda was just a tiny part of. Tim was actually going a different direction with it, by I got an idea talking with him.

It was an idea that FSF zealots really don't like, but they lost me in 2006:

http://landley.net/notes-2006.html#03-12-2006

And I've been drifting _away_ from the GPL ever since. Before you blame Tim for my "screw it, BSD license the sucker" decision, read this bit almost TWO YEARS EARLIER:

http://landley.net/notes-2010.html#10-01-2010

> Since uClibc's so obviously moribund, I'm vaguely pondering poking at
> Android's "bionic" project instead, and maybe even their "toolbox"
> project. The first is their libc (uClibc replacement) and the second is
> their coreutils (busybox replacement). They wrote their own because they
> decided they want all the userspace stuff to be BSD licensed, no GPL in
> userspace. Before GPLv3 came out I would have objected to this, but now
> it seems kind of reasonable. (If the FSF is really _that_crazy_, then
> you don't want to get any of it on you.)

And goes on to talk about the merits and drawbacks of BSD licensing.

This was me analyzing some more of Android's licensing decisions a year before I relicensed Toybox:

http://landley.net/notes-2010.html#09-10-2010

So by all means, consider me some kind of strange puppet for Tim that's unable to form any independent thoughts about licensing, let alone make informed decisions like an adult.

About the calculus for the project

Posted Feb 10, 2012 10:16 UTC (Fri) by khim (subscriber, #9252) [Link] (7 responses)

If this is all about Android then why the page was started with talks about GPL infringement facilitation? It still talks about this aspect first and about potential usage in Android second.

Better userspace for Android will be easy sell. GPL infringement facilitator is not. Even if technically it's the same project.

P.S. Actually userspace for android is slightly different project because to support Dalvik you need different set of tools then to support traditional POSIX userspace.

About the calculus for the project

Posted Feb 10, 2012 16:19 UTC (Fri) by landley (guest, #6789) [Link]

"We'd like to get as many patents as possible to protect ourselves from the insane patent system via mutually assured destruction and cross-licensing agreements."

"We'd like to get an alternative to BusyBox to protect ourselves from the insane out of control SFLC/SFC and their demands about third-party binary only kernel modules and vendor toolchains we've never even seen the source code to if we shipped a vanilla unmodified busybox but didn't SAY we shipped a vanilla unmodified busybox."

"We'd like to distance ourselves from this legal quagmire rather than try to navigate an endless shifting maze."

That's not _my_ motivation, but I can certainly see spraying for lawyers holding an appeal for people, especially when legal stuff isn't what they _do_. And if it makes 'em more likely to use the code I already _wrote_ and am still adding to (which is technically better than the alternative)? Sure, why not?

Rob

About the calculus for the project

Posted Feb 10, 2012 16:22 UTC (Fri) by landley (guest, #6789) [Link] (5 responses)

By the way, another analogy for all the insane GPL zealots to ponder:

Don't put lifeboats on your cruise ship. Make it unsinkable. By planning for what happens if the boat sinks, you're planning to sink the boat! Shame on you, lifeboats are EVIL!

Rob

About the calculus for the project

Posted Feb 10, 2012 17:21 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

You are not putting lifebots on a ship. You are adding couple of lifebots to Titanic.

This makes no sense whatsoever. If you don't expect for it to be sunk then why bother with lifebots at all? If you do expect crash and burn scenario then why do you plan to save just a handful of people, not all of them?

About the calculus for the project

Posted Feb 11, 2012 14:35 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

Actually, that's not fair on Titanic ...

She had FAR more lifeboats than were legally required.

And could have saved a lot more people, if they hadn't messed up evacuating the boat. Plus a load of people didn't want to get on the lifeboats because they felt safer staying on board (pretty much the same as happened in the recent cruise-ship sinking in Italy ...)

(I think the law nowadays says you need enough spaces on EACH SIDE of the boat for the entire passenger/crew complement - ie 2 spaces per person. Most boats carry even more. It makes sense, actually, if the boat is listing you can lose half your usable lifeboat capacity in the space of seconds.)

Cheers,
Wol

About the calculus for the project

Posted Feb 11, 2012 15:39 UTC (Sat) by khim (subscriber, #9252) [Link]

Actually, that's not fair on Titanic ...

She had FAR more lifeboats than were legally required.

Sure. Law required just 16 lifeboats while Titanic had 20. With total capacity of 1,178 people on a ship with capacity of 3,547. Less then ⅓ space per person. Good idea. Not.

And could have saved a lot more people, if they hadn't messed up evacuating the boat. Plus a load of people didn't want to get on the lifeboats because they felt safer staying on board (pretty much the same as happened in the recent cruise-ship sinking in Italy ...)

That's another issue. Yes, even if you have enough lifeboats you still can lose a lot of lives in a case of crush. But if you don't have enough lifeboats to save all passengers then loss of life is inevitable.

I think the law nowadays says you need enough spaces on EACH SIDE of the boat for the entire passenger/crew complement - ie 2 spaces per person. Most boats carry even more. It makes sense, actually, if the boat is listing you can lose half your usable lifeboat capacity in the space of seconds.

Sure. More then one space per person may be good idea. How much more is subject of the debate. Less then one space per person is pointless - and this is exactly how Titanic was equipped.

About the calculus for the project

Posted Feb 12, 2012 15:51 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

btw, you might stand more chance of convincing people rather than repelling them if you didn't routinely call them insane. Just a thought.

About the calculus for the project

Posted Feb 13, 2012 8:27 UTC (Mon) by bronson (subscriber, #4806) [Link]

This is true. But I don't think Rob is calling all GPL zealots insane...? That's just a tiny subset.

About the calculus for the project

Posted Feb 5, 2012 12:25 UTC (Sun) by alankila (guest, #47141) [Link] (3 responses)

Thank you for a thoughtful reply. I personally do hope that people would not find this argument reasonable way to think about licenses, because in general case any piece of software that happens to eliminate another piece of GPL software could be argued to help facilitate GPL infringement on the remaining software.

But as you point out, law is essentially insane and random, and stranger things could happen. My personal feeling, however, is that this is not fair nor right, whatever the courts might find.

About the calculus for the project

Posted Feb 5, 2012 15:14 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

I personally do hope that people would not find this argument reasonable way to think about licenses, because in general case any piece of software that happens to eliminate another piece of GPL software could be argued to help facilitate GPL infringement on the remaining software.

Nope. Again: context matters. As rahvin already wrote: The court verdicts to date have basically established the precedent that if the intent and use of the product was for the primary purpose of infringing copyright, even if there are legitimate uses that make up a small part of the use case, that the parties responsible are guilty of contributory copyright infringement for the behavior of their users. Not only you should show that someone picked your piece of software because it's under BSD license (that's understandable: less rules to follow), you must show another piece of GPLed code which is commonly used with first one and show that most users of your software not only continue to use it, but also do it in violation of it's copyright. Tall order, indeed.

But as you point out, law is essentially insane and random, and stranger things could happen. My personal feeling, however, is that this is not fair nor right, whatever the courts might find.

No questions here. I also feel that copyright's power is inflated way, way, WAY beyond any reasonable limits. But... dura lex sed lex. And since Disneys and SONYs of the world were instrumental in said insane inflation it's only proper to apply no mercy, as much punishment as possible principle to them.

About the calculus for the project

Posted Feb 5, 2012 23:13 UTC (Sun) by anselm (subscriber, #2796) [Link] (1 responses)

Not only you should show that someone picked your piece of software because it's under BSD license (that's understandable: less rules to follow), …

What about the idea of someone picking the BSD-licensed software simply because it was better code than the GPL software (i.e., written by somebody with several years of experience with the GPL codebase, taking into account any design and implementation issues since discovered with the GPL codebase etc., and better targeted towards solving the actual problem that users of the software need solved)?

In that case it would be difficult to argue that the »intent and use« of a BSD-licensed Busybox workalike would be »for the primary purpose of infringing copyright«. Maybe its intent and use is to provide a technically superior all-in-one shell-type tool, and its users prefer it to Busybox on these grounds (with the more liberal license as a fringe benefit). This isn't Napster, after all.

Given this, it would be next to impossible (for someone like the SFC) to show that somebody picked the BSD-licensed software exclusively on licensing grounds, and claiming that this in turn was only done to avoid GPL compliance issues concerning the Linux kernel would border on a conspiracy theory. At the very least, someone like the SFC would have to prove that the workalike was clearly less suited, technically, for its intended use (by the defendant, not the FLOSS community in general) than the original GPLed Busybox, and that the defendant still went for the workalike just to be able to do an end-run round the SFC. Have fun.

About the calculus for the project

Posted Feb 6, 2012 0:33 UTC (Mon) by khim (subscriber, #9252) [Link]

I never said it's easy to probe illegality of this work. In fact just a dozen years this question was flat out crazy: it was obvious that if there no copyright violation then there are no material for lawsuit. And as I've already said: it's hard to say a-priori which way the development will go. In fact there already exist alternative BSD-licensed userspace fro Linux: Android's one (albeit in this case it's pretty clear that it's goal was to support Java-based environment and not to act as GPL-free replacement for GNU tools). And if companies that use toybox will be postly good citizens then we'll not a problem: as was shown many times already it's not about busybox or toybox.

But Disneys and SONYs of the world are hard at work - and they continue to extend the reach of copyright in the vain hope to squeeze more money from 100 years old creations.

If enough guys from enough companies will blab out that they are switching to toybox to solve "SFC problem" then you'll have materials for lawsuit. It'll not matter if toybox is inferior or superior. If proportion of GPL-violating companies will be high enough among toybox users and low enough among busybox users and you'll have direct evidence for a few "switchers" - you'll probably have enough for the court in the current world, where copyright importance is inflated beyond any reason. And in tomorrow's world it may be even easier.

About the calculus for the project

Posted Feb 9, 2012 23:44 UTC (Thu) by landley (guest, #6789) [Link] (3 responses)

I'm the ex-maintainer of busybox, who started toybox before I actually did the last release of busybox. I'm the one who _started_ the busybox license enforcement lawsuits (and recruited Erik Andersen in into it, and yes I still have my old email).

You're claiming that my new project might be considered an infringement facilitator AGAINST MY OLD PROJECT, and that stopping the lawsuits I _started_ might somehow legally do... something?

Your honestly believe that the legal system can and should forbid people from doing new things that compete with (and obsolete) their own previous work? And you take this position in defense of "freedom", as defined by the FSF?

I ask seriously: are you crazy? Do you need some kind of diagnosis and treatment? (I already _know_ the FSF does...)

About the calculus for the project

Posted Feb 10, 2012 10:06 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

You're claiming that my new project might be considered an infringement facilitator AGAINST MY OLD PROJECT, and that stopping the lawsuits I _started_ might somehow legally do... something?

Oh yea. Absolutely. This is what this lawsuit is all about. Oracle even explicitly claimed that the fact that the very same people are working on Dalvik that worked on Java decades ago increases Google's liability. Or perhaps you live in some other world where such things never happen?

Your honestly believe that the legal system can and should forbid people from doing new things that compete with (and obsolete) their own previous work?

That's different question. I know that the legal system can and does forbid people from doing new things that compete with their own previous work. I'm not saying it's good thing - that's another thing entirely.

And you take this position in defense of "freedom", as defined by the FSF?

Law exist without FSF's freedom. Government changes it, not FSF.

I've pointed that what you are doing is probably illegal and that you can be sued for doing it in the future. This is almost certainly true. But I'm not saying that this is what FSF should do. Just because you can sue someone does not mean you should. That's different story altogether.

I ask seriously: are you crazy? Do you need some kind of diagnosis and treatment?

Me? I'm absolutely sane. The copyright world is crazy - but sadly I don't know how to cure it.

About the calculus for the project

Posted Feb 10, 2012 17:15 UTC (Fri) by landley (guest, #6789) [Link] (1 responses)

> That's different question. I know that the legal system can and does
> forbid people from doing new things that compete with their own previous
> work.

Not in California or Texas it doesn't. ("Right to work" states.) There's rather a lot of case law on this. Silicon Valley was _built_ on the "traitorous eight" from Shockley Semiconductor.

http://en.wikipedia.org/wiki/Traitorous_eight

Honestly, if you work in the industry you get to know this stuff...

Rob

(Oratroll is suing over patents, sounds like they're attempting to establish treble damages for wilful violation, ala http://www.ipwatchdog.com/patent/advanced-patent/patent-i... . Which is in fact the reason Linus gives for not reading software patents.)

About the calculus for the project

Posted Feb 10, 2012 17:38 UTC (Fri) by khim (subscriber, #9252) [Link]

http://en.wikipedia.org/wiki/Traitorous_eight

Honestly, if you work in the industry you get to know this stuff...

Sure. These tales are very well-known. But that happened half-century ago. Companies worked diligently to rectify "the problem" all that time. Today the outcome of such lawsuit is quite different to predict.

Oratroll is suing over patents

Nope. Copyrights are very much in dispute, too. And outcome is not yet certain. And I'm sure if Oracle will be repelled this time then it'll cooperate with Disneys and SONYs of the world to change the law to make sure next time they'll win.

In fact the whole SFC "problem" have one trivial and quite logical solution: change the law, reduce copyright power and make what SFC is doing illegal. Sadly Disneys and SONYs of the world reject this solution out of hand because it'll reduce their copyright power, too. Well, as long as that's the case don't expect me to feel any sympathy to their plight. They brought it on themselves.

About the calculus for the project

Posted Feb 9, 2012 23:36 UTC (Thu) by landley (guest, #6789) [Link]

> BSD-relicensed (that's important) toybox looks very much like
> Napster-style copyright infringement facilitator.

"It's not impossible, I used to bullseye womp rats in my T-16 back home. They're not much bigger than two meters."

I wrote the toybox code, I own the copyright on the code, I issued a second license to my copyrighted code. (A license is a permission statement. The older versions were released under GPLv2 and that was the only set of conditions you had permission to use it under. I have since granted additional permission to use my copyrighted code under less restrictive terms. Legally, the two are unrelated.)

As the guy who _started_ the Busybox licence enforcement suits, as someone who spent a couple years paid by IBM's lawyers as a domain expert to help defend them against legal claims, as someone who had an email exchange with Richard Stallmand in the 90's about nuances of the GPL for a "copyright and licensing HOWTO" that eventually turned into a week-long series of articles on the five types of intellectual property for The Motley Fool:

http://www.fool.com/portfolios/rulemaker/2000/rulemaker00...
http://www.fool.com/portfolios/rulemaker/2000/rulemaker00...
http://www.fool.com/portfolios/rulemaker/2000/rulemaker00...
http://www.fool.com/portfolios/rulemaker/2000/rulemaker00...
http://www.fool.com/portfolios/rulemaker/2000/rulemaker00...

As somebody who has studied intellectual property law as a hobby since the 1990's, as someone who has spoken on panels discussing the GPL when the other panelists were professional practicing lawyers, as someone who was once flown to new York to speak on a panel with Eben Moglen (the lawyer co-author of the GPL) about GPL enforcement.

As all that and more, I tell you:

No, it's not "important". You have absolutely no _clue_ what you're talking about, and I don't appreciate the transparent FUD.

About the calculus for the project

Posted Feb 9, 2012 23:17 UTC (Thu) by landley (guest, #6789) [Link]

> What does it say to you? Two things.
> 1. That future lawsuits will probably not bring new enhancements for
> busybox.

No, it says that past ones didn't. I cut my ties at the end of 2008, I haven't seen anything new show up in the busybox repository or on the mailing list that's attributable to lawsuits since, but to be honest I haven't been paying _that_ close attention. Outside of submitting my patch implementation, fixing busybox vi's horrible serial handling, trying to convince Denys to adopt some of toybox's better infrastructure (such as having all information about a command be in one file per command), and some trivial cleanups to demonstrate the the code doesn't HAVE to be #ifdef salad (I.E. "this is what I added the ENABLE_BLAH and USE_BLAH() macros for 5 years ago, you're using them wrong")... I haven't really paid that close attention to the busybox list. I catch up when I move to a new release, get involved in a thread or two, and then wander away again.

I still seem to have an impact when I do show up. My last exchange was:

http://lists.busybox.net/pipermail/busybox/2011-November/...

Which led to me fairly randomly advocating "some things are better as as shell scripts, not in C":

http://lists.busybox.net/pipermail/busybox/2011-November/...
http://lists.busybox.net/pipermail/busybox/2011-November/...
http://lists.busybox.net/pipermail/busybox/2011-November/...

And then I wandered away again, but this morning I noticed, in year 13 of the project we now have:

http://git.busybox.net/busybox/commit/?id=d0222503ff9ff26...

(My rsync script which syncs my laptop up to my web server also does a git pull on various repositories, and busybox is still in there...)

Sheer coincidence, of course. But given a choice, I'd rather put my energy into Toybox than Busybox. When I worked on busybox, I wanted it to spread up into the desktop and become the standard command line of things like Knoppix while remaining small and simple. Neither happened. Now I want toybox to spread down into android and ride the smartphone up as it displaces the PC the way the PC displaced the minicomputer, and that displaced the mainframe before it.

And before you say "that's impossible", google "Toshiba Dynadock" and imagine what plugging a USB docking station into an android phone containing a native compiler actually _means_...

Rob

About the calculus for the project

Posted Feb 4, 2012 14:30 UTC (Sat) by nix (subscriber, #2304) [Link]

As you say, they are lax. Neither gplviolations.org nor the kernel community have ever taken anyone to a US court.

Uh, that would be because gpl-violations.org operates in Germany. Harald Welte is a kernel hacker, so members of the kernel community certainly have taken people to court -- just not US court.

About the calculus for the project

Posted Feb 9, 2012 22:54 UTC (Thu) by landley (guest, #6789) [Link]

> You are asking us to believe that a difference in "interpretation" is the
> reason for Toybox, and its creation is in no way related to the fact that
> the SFLC will sue you when nobody else will.

No, Toybox started in 2006, because a troll showed up to take credit for all my work ten years after he last wrote any code (for anything), and disgusted me so hugely I left busybox entirely rather than let him take credit for one more LINE of code I wrote:

http://landley.net/notes-2006.html#26-09-2006

But I still wanted to work on small, simple utilities (I had several half-finished, and I write this sort of code for fun), so I took the excuse to start over from scratch without the decade of legacy design decisions BusyBox had accumulated. Instead of just sulking, after I withdrew from BusyBox I started a new project and sat down to write better code:

http://landley.net/notes-2006.html#01-10-2006

I continued to work on it, on and off, for the next 3 years, until I'd solved all the interesting design problems and knew how the new project should be implemented. But I had a bunch of other demands on my time (aboriginal linux, my tinycc fork, day job), and I had the problem with Toybox: the niche it was going for was already filled. By BusyBox. I'd appointed its current maintainer and handed years of my work off to him, I was going up against something with a 10 year head start, led by a smart active guy, including years of my own work. It was "good enough", merely being technically _better_ wouldn't necessarily draw users away from it. It had a greater "project gravity", and is what people would reach for first to solve the problem both projects addressed.

I started to consider rejoining BusyBox after about 2 years:

http://landley.net/notes-2008.html#30-06-2008

And eventually I mothballed ToyBox and started pushing my work "upstream" into busybox (which was actually a huge port since the point was to base from-scratch rewrites on completely different infrastructure):

http://landley.net/notes-2010.html#11-03-2010

The biggest chunk of infrastructure was my new patch implementation, because BusyBox's was more or less a stub. But I also met denys at CELF 2010 and explained toybox's config and help infrastructure (where all you do to add a command is add a toys/mynewcommand.c file and then re-run the build and it picks everything up from that; in BusyBox you had to touch 5 different files), and so on.

But I liked the toybox infratructure much better than busybox's, even with what cleanups I managed to convince Denys to do. And unfortunately, BusyBox had lost focus on "simple", and moved it down below "small binary size", "fast execution time", and "lots of features". The resulting code was #ifdef salad full of magic annotations and control flow that hid the program's actual entry point in libbb/appletlib.c line 771. The result was just no fun to work on:

http://landley.net/notes-2011.html#08-06-2011

For a couple years I vaguely tried to learn Lua to rewrite toybox in that as a way of giving it a reason to exist separate from busybox (and thus a reason for me to still work on it):

http://landley.net/notes-2009.html#26-02-2009

But lua turns out not to have a standard posix binding, making rewriting toybox in it kinda hard. (If I have to include native C code to extend lua, I might as well write the whole thing in C. Being in a higher level language eliminates the need for cross compiling, but being in a higher level langauge with C extensions _doesn't_.)

So toybox was in limbo for a couple years, with the bits I really _needed_ (for my aboriginal linux project, creating the smallest Linux development environment capable of rebuilding itself from source) pushed into busybox, but busybox being no fun to work on and not seeing much point in pushing toybox up a hill busybox was already at the top of...

Then when Tim contacted me in November, what he did was point out that there _was_ a niche for ToyBox: on Android, which by policy forbids GPL in userspace but has only a stub command line that's crying out to be replaced.

I've considered Android very important for a while now, because it _will_ take over from the PC:

http://landley.net/notes-2011.html#26-06-2011

And Linux won't:

http://landley.net/notes-2010.html#10-03-2010

I just hadn't played with its native development environment much after a bad early experience:

http://landley.net/notes-2010.html#10-01-2010

So when Tim went "android" (and pointed out the AOSP is much less stupid now than it was 2 years ago) I went "D'oh" and started scheming:

http://landley.net/notes-2011.html#13-11-2011

I'd never have left GPLv2 behind if it wasn't for GPLv3. (I seriously doubt Android would have forbid GPL in userspace either, v2 got tarred with the same brush as v3.) I loved GPLv2:

http://sf.geekitude.com/content/pros-and-cons-gnu-general...

But I'm not the one who left the GPL, it left _me_:

http://landley.net/notes-2006.html#03-12-2006

Rob

About the calculus for the project

Posted Feb 3, 2012 22:40 UTC (Fri) by raven667 (guest, #5198) [Link]

Or the position they seem to be taking, IIUC, that GPL enforcement for Linux is NotTheirProblem(tm).

About the calculus for the project

Posted Feb 3, 2012 23:56 UTC (Fri) by marcH (subscriber, #57642) [Link]

The reality today is that every other company in the world is using GPL software, most notably Linux

http://www.h-online.com/open/features/We-won-and-we-didn-...

Companies which exclude any piece of GPL'ed software without even considering it are obviously restricting their options, which is unlikely to make them more competitive.

> ... and open-source will IMO reach further than before.

Whether BSD or GPL is more efficient at producing open-source has been debated 5 zillions times already, and the answer is certainly not as obvious as you make it sound.

About the calculus for the project

Posted Feb 2, 2012 15:09 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] (2 responses)

"Some people have said that what the SFC requests in remedies is not that costly, but I can assure you that large corporations see it very differently. Matthew, in particular, keeps asserting that the real reason for this project is "to make it easier to infringe the kernel's license." This is simply not true."

You both characterise the motivation with dramatically different words. But if we analyse it carefully, you seem to be saying the same thing. I'll try for a more neutral rendition:

The motivation is to reduce the risk and the adverse consequences of a violation — whether it be an intentional or inadvertent violation.

Personally, I don't care care about the distinction between deliberate and accidental violation, which seems to be the major difference between your version and Matthew's statement. If you have taken steps to reduce the consequences of an "accidental" violation, that can only mean that you want to reduce the amount of effort you expend in ensuring that you comply with the licence in the first place. Which makes it, to me, a deliberate choice.

It's a shame that Busybox has been left with the responsibility of bringing errant manufacturers into compliance, and I'm glad that they asked for the manufacturers to comply with the licences of all the software they ship, rather than only asking for the source for Busybox. That doesn't seem like an excessively costly and inappropriate condition, to me.

If one of my children calls the police because I'm beating them, I think it's quite right for the police officer to refuse to leave me alone until I stop beating all of my children; even the ones who didn't make a formal complaint.

I think it's high time that Linux kernel developers joined in and granted SFC or other organisations the authority to act on our behalf too. Then we won't need to rely on the fact that Busybox is usually also pirated; we can act directly when there is a violation on the kernel itself.

Harald has done good work in the past, but as noted elsewhere he's extremely busy with other things now. And if Busybox is no longer going to be able to help to keep manufacturers honest, we do actually need someone like the SFC to be acting directly on our behalf.

I'll be assigning the rights to the SFC to enforce all copyrights that I personally hold in the Linux kernel and any other project they ask me about. I strongly encourage all other kernel developers to do the same.

About the calculus for the project

Posted Feb 2, 2012 19:47 UTC (Thu) by masoncl (subscriber, #47138) [Link] (1 responses)

> I'll be assigning the rights to the SFC to enforce all copyrights that I personally hold in the Linux kernel and any other project they ask me about. I strongly encourage all other kernel developers to do the same.

I'd encourage anyone who does so to retain control over the way those copyrights are used. This isn't a dig against the SFC, just a good idea in general.

About the calculus for the project

Posted Feb 2, 2012 19:58 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

Most definitely. A standard agreement along these lines (and I've signed them for Harald in the past too) would grant authority to act on your behalf, on a temporary basis that you can terminate at any time; perhaps with a reasonable notice period.

We're certainly not talking about copyright assignments or anything like that.

I trust the SFC to handle things appropriately, and if they ever lost my trust I could withdraw my authority simply by sending them an email and telling them so.

About the calculus for the project

Posted Feb 3, 2012 11:50 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] (1 responses)

"Imagine if you were mayor of a town of 300,000 people, and you had to pay a million dollar fine if someone was caught stealing. You have implemented a set of policies to prevent stealing, and to encourage people not to steal. Could you guarantee that no one ever stole? As mayor, would you pay $1,000 for an insurance policy against the fine? That's similar to the cost/benefit calculus for this project, for large enterprises. It's not that executives are unwilling to enforce compliance, or are actively undermining the license of the code their company ships. They just want to reduce risk."

This makes perfect sense to me (ignoring the scale of the numbers). But the analogy is slightly incomplete. In fact there is only one shopkeeper who is making complaints about the theft, and who is causing you to pay those fines. And your insurance policy only covers that one shopkeeper.

There are plenty of other shopkeepers who have been stolen from. And so far, the stuff that's been stolen from them has been returned after that one guy has gone to the police and the thieves have been caught.

So yes, you can silence that one guy, but you are taking a gamble that none of the others will start to stand up for themselves, now that he's gone.

There are all kinds of other discussions going on in this thread, about how the mayor is evil for "encouraging" stealing, which I don't believe. And how the one shopkeeper is evil for demanding that the thieves return all the stuff they stole, rather than only the stuff they stole from him.

All of those other discussions miss the point, as far as I'm concerned. The point is that this "insurance", which shuts up the one guy who's been calling the police and getting stuff returned for all his friends, is not going to work.

Someone else is just going to call the police instead. It's a PITA for them and it distracts them from the shopkeeping that they prefer to do — but if their friend can't do it any more, they'll just have to do it themselves.

About the calculus for the project

Posted Feb 3, 2012 12:39 UTC (Fri) by dwmw2 (subscriber, #2063) [Link]

"Someone else is just going to call the police instead. It's a PITA for them and it distracts them from the shopkeeping that they prefer to do — but if their friend can't do it any more, they'll just have to do it themselves.

Of course, the mayor might realise this; he's not silly. So he might deliberately set about trying to discourage the other shopkeepers from calling the police.

He might tell tales of police brutality, but be strangely unable to provide actual evidence of this.

He might encourage those people who complain about the police returning stolen goods to everyone, rather than just the one shopkeeper who reported the theft. And try to expand that complaint into something more sinister about the police being "overzealous", but again without any real evidence.

And he might find any other method he can to discredit the police with unfounded claims.

Hopefully, the other shopkeepers would have the wit to see through that deception.

I believe that Bradley Kuhn is telling the truth when he reports what the SFC actually ask for; I find it hard to believe any of the wild claims I've heard, and I trust that their behaviour will be continue to reasonable.

But to a certain extent that doesn't even matter. I don't have to trust that the SFC will always behave reasonably for ever and ever — because if they ever did violate my trust, I'd just withdraw my permission for them to act on my behalf.

I strongly recommend that every kernel developer should work with the SFC and allow them to take enforcement action on our behalf. You don't have to sign in blood. If any of these unfounded claims ever did turn out to be true, you could easily withdraw your permission. It's that simple.

you forgot about gpl-violations

Posted Feb 1, 2012 19:33 UTC (Wed) by dlang (guest, #313) [Link] (12 responses)

Harald Welte has been enforcing the GPL on the kernel for years. He chooses to go a very different route than the SFC has gone.

you forgot about gpl-violations

Posted Feb 1, 2012 19:38 UTC (Wed) by corbet (editor, #1) [Link] (11 responses)

Harald has been busy with other things and doesn't seem to be doing much with gpl-violations.org. That effort has since slowed considerably. They have done some good work with the AVM v. Cybits case, but that is the only news posted on their site since 2008. Undoubtedly there is behind-the-scenes work going on, but a lot of the initiative seems to have moved to the SFC.

you forgot about gpl-violations

Posted Feb 1, 2012 19:45 UTC (Wed) by armijn (subscriber, #3653) [Link] (9 responses)

As the guy running the day to day operations at gpl-violations.org I can tell you that that is simply not true. We don't publish about cases, but we have been very active, both with cases and talking to companies directly.

you forgot about gpl-violations

Posted Feb 1, 2012 20:11 UTC (Wed) by corbet (editor, #1) [Link] (6 responses)

Is there any way you can put out some information on what you've been doing, at least in statistical form? There is a fairly widespread perception that, for example, nobody is really doing enforcement in the kernel space at the moment. Making people more aware of what is going on might help to ease some concerns in that area.

In other words, it is true that AVC v. Cybits is the only news on gpl-violations.org since 2008. So it looks like not much is going on.

you forgot about gpl-violations

Posted Feb 1, 2012 20:29 UTC (Wed) by laf0rge (subscriber, #6469) [Link] (2 responses)

The fact is that I'm too overloaded with any kind of work in about all the dozens of projects that I'm involved in, that I don't find much time for gpl-violations.org at the moment. I wanted to have some more news on the website, and a new website for many years, but never got around doing anything about it.

But yes, the project is up and running and we've been doing enforcement all the time along. There's a maximum cap of 10 cases in parallel at this time, to not stretch the thin resources even thinner. The total number of enforcement cases ever since gpl-violations.org has started is certainly beyond 200 now.

Armijn is doing a great job in running the operations, as are other people who are actively contributing but not publicly visible.

I wanted to have at least an annual report on the site every year, but even that didn't happen either. It's pretty depressing if you work 12-14 hours a day, don't take weekends off, not even christmas, and still every day you never find even remotely enough time for all the things you want to do.

Let's see if I can get that report together, but if it will happen, it will probably not happen anytime soon, sorry.

you forgot about gpl-violations

Posted Feb 2, 2012 0:31 UTC (Thu) by josh (subscriber, #17465) [Link]

Even a simple post saying "We've worked on N cases this year, more details when we're not swamped with cases." would help greatly, and would hopefully not require much time to produce.

you forgot about gpl-violations

Posted Feb 2, 2012 0:32 UTC (Thu) by josh (subscriber, #17465) [Link]

By the way: you do awesome work, thanks for doing it. That goes for code as well as for gpl-violations.org.

you forgot about gpl-violations

Posted Feb 1, 2012 20:32 UTC (Wed) by armijn (subscriber, #3653) [Link] (2 responses)

I will see what I can mine from my archive. Our focus in 2011 and 2012 has been on Android, especially tablets. As many people have noticed, the situation there is pretty bad.

you forgot about gpl-violations

Posted Feb 1, 2012 21:42 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

I understand you are busy but if you don't have a good impression on SFC and don't publish the work you are doing in this area, it is natural for people to assume SFC is the only entity doing this and this gives them more power. If you want to balance that, publicise what you do.

you forgot about gpl-violations

Posted Feb 1, 2012 22:34 UTC (Wed) by marcH (subscriber, #57642) [Link]

I second that. Working on only half the cases BUT publicising them will have a much better chilling effect on violators.

you forgot about gpl-violations

Posted Feb 2, 2012 4:03 UTC (Thu) by rahvin (guest, #16953) [Link] (1 responses)

How about a simple question. Would you agree (in any way) with the allegation raised by Tim that SFC is demanding unreasonable terms in comparison to your own organization? It was always my impression that what SFC was demanding was little different that what your own group was demanding. And if you don't mind could you list the approach and demands that are generally made by your own organization?

I'm curious if Tim is correct in his assertion that there is this huge difference in how the two organizations work and what they demand for cure.

you forgot about gpl-violations

Posted Feb 2, 2012 10:21 UTC (Thu) by jospoortvliet (guest, #33164) [Link]

I'd say the comment by Armijn higher up in the page speaks for itself... He questioned the legality of SFC's actions (rightly so or not) so I doubt gpl-violations acts that same way then.

you forgot about gpl-violations

Posted Feb 1, 2012 19:47 UTC (Wed) by scottt (subscriber, #5028) [Link]

There is of course Harald's new year resolution for 2012: http://laforge.gnumonks.org/weblog/2011/12/24/#20111224-h...

A tempest in a toybox

Posted Feb 2, 2012 5:05 UTC (Thu) by martin.langhoff (subscriber, #61417) [Link] (6 responses)

Starting an new, competing project solely due to licensing issues is a classic of the FOSS world. It's been done a thousand times.

Now there are two possible angles -- one is whether it is moral or ethical, and I see most of the discussion here trying to sort that out.

The second one -- which I think is more important -- is whether it works, whether it is sustainable long term. If the codebase is good enough, and the license acceptable to a userbase that is ready to improve it -- you are in business. OEMs can be such a userbase.

A BSD-licensed project that moves forward at a steady pace can be very successful. The license doesn't enforce the give-back, but the steady pace can make it painful to maintain a fork, so the incentive to contribute back exists.

Vendors do unspeakable things with Apache, and yet Apache has not withered. As long as the project keeps momentum, anyone who's too forked has to pay a heavy price of rebase / merge. That eventually drives them to upstream or at least modularize to reduce the pain.

Perhaps, with the popularity of Linux on small embedded devices, it's likely that a small BSD-licensed userland for Linux will take hold.

In the end, it is not the "morally correct license" that wins. This isn't a fable. Instead, good software + a core group of develipers that drives a constructive dynamic, cares about its ecosystem (end users, OEMs, distros) and keeps the pace are the key components for a sustainable and successful project.

IMHO

A tempest in a toybox

Posted Feb 3, 2012 9:46 UTC (Fri) by cas (guest, #52554) [Link] (4 responses)

That might work for apache, but the kinds of products that use busybox are considered by their manufacturers to be disposable, intended to be replaced within a year or three - phones, tablets, routers, media players, set-top boxes, TVs, and more. disposable consumer junk, well along on the road to obsolescence even on the day they are released.

There is simply no incentive in that context to even maintain their own forks, let alone submit changes upstream.

BTW, your pragmatic angle is only important in the very short term, and even then only in a very narrowly-focused oblivious-to-the-real-world way. It's not even true pragmatism, because it's only a short-term benefit for a long-term loss.

No, it is the moral and ethical issues which are truly important.

They're not a reason to prohibit development of a BSD-style licensed alternative (an absurd suggestion anyway - even if anyone wanted to, no-one has the power). But they are a reason to boycott contributing anything to the project.

One of the reasons why manufacturers dislike the GPL is that the license effectively allows users to extend the lifespan of the "disposable" products they buy, and even re-purpose them. e.g. without the GPL, cyanogenmod wouldn't have recent versions of android running on 4,5,+ year old phones. The GPL gives rights - and options and possibilities and even capabilities - to the end-users...a fact that BSD-advocates either won't/can't see or refuse to place any value on.

This, naturally, conflicts with the gadget-fetishism, the obsession with the new and shiny, the must-have-it-now consumerist impulse that manufacturers want us to have.

Also, and just as importantly, as an occasional consumer of tech. products, I don't want a BSD-licensed userland on devices I purchase, because the BSD license does *nothing* to ensure that the product I buy is actually mine - under my control as well as in my possession. Apple has demonstrated well enough that the BSD license serves the interests of manufacturers and their corporate partners, rather than my interests.

As a user, the GPL is my friend. it gives me rights to the software I use.

as a developer and contributor to FOSS projects, the GPL is also my friend - it ensures that my work, my donation of time and effort and skill will always be available.

A tempest in a toybox

Posted Feb 4, 2012 18:33 UTC (Sat) by alankila (guest, #47141) [Link] (3 responses)

I can't help feeling that attributing CM's existence to GPL is somewhat incorrect, given that such a large part of Android is not GPL to begin with.

A tempest in a toybox

Posted Feb 4, 2012 18:41 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (2 responses)

The GPL is the only reason the vendors have to give up the kernel, and without that you'd only have CM for the Nexuses.

A tempest in a toybox

Posted Feb 5, 2012 3:32 UTC (Sun) by Fowl (subscriber, #65667) [Link] (1 responses)

CM could still run with extracted binary vendor kernels, same as it uses extracted binary userspace libraries now. Things like the cameras on many of these devices have kernel shims and then user space blobs providing the abi that (a particular version of) android expects. Much effort is expended reverse engineering and writing wrappers for these kinds of things.

Without kernel source it would 'just' be harder and certain features wouldn't be possible. Look at what the Widows Mobile modding community achieved with no source, for anything.

A tempest in a toybox

Posted Feb 5, 2012 3:41 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

Newer versions of Android depend on functionality present in newer kernels. While it's theoretically possible that people could shim that into 2 year old kernel binaries, in practical terms most CM ports simply wouldn't exist.

A tempest in a toybox

Posted Feb 4, 2012 4:42 UTC (Sat) by foom (subscriber, #14868) [Link]

Apache (httpd) may not have withered, but it hardly seems the paragon of health.

A couple weeks ago I wanted to use an LDAP authorization feature (nested group membership). After some investigation and surprise, I found that that feature had been committed to the svn trunk in 2007, but has not yet made it into a release. Why? Because there haven't been any new major versions released since 2.2 was released in 2005, 7 years ago! Yikes! (But, I see 2.4 is expected to be released real soon now.)

The glacial speed of releases probably has nothing to do with licenses, but I would guess that anyone who has forked Apache into a proprietary variant has most likely had no trouble keeping up with the rate of change...so you might want to find a new example to hold up. :)

A tempest in a toybox

Posted Feb 2, 2012 15:53 UTC (Thu) by spaetz (guest, #32870) [Link] (1 responses)

I wonder if it were possible to fork the GPL to create a v2 version that does not include a death penalty. But cures infringements after the source has been provided. It would make it much more attractive to me, knowing that a crazy developer or a simple mistake cannot forfeit my uses of a GPL software forever.

A tempest in a toybox

Posted Feb 2, 2012 16:44 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

You could just attach an explicit additional permission to any GPLv2 code you write.

FAQ for project proposal just added to wiki

Posted Feb 2, 2012 18:55 UTC (Thu) by tbird20d (subscriber, #1901) [Link] (9 responses)

I've seen a lot of similar questions about the project. In an effort to avoid spamming the list with responses, and to clarify the project motivation and goals, I have added a FAQ section to the project proposal wiki page.

Please see: http://elinux.org/Busybox_replacement_project#FAQ

FAQ for project proposal just added to wiki

Posted Feb 2, 2012 19:07 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (8 responses)

"Q. Is this being done to prevent the SFC from asking for the source to the Linux kernel?
A. No, although it would have that effect."

You are wrong about this. What you are doing is pushing the kernel developers to use SFC instead of using busybox as a proxy

https://lwn.net/Articles/479010/

"I'll be assigning the rights to the SFC to enforce all copyrights that I personally hold in the Linux kernel and any other project they ask me about. "

Even BSD license has a copyright attribution requirement. Enforcing that vigorously would cause enough pain if a vendor hasn't thought about compliance before.

FAQ for project proposal just added to wiki

Posted Feb 2, 2012 20:22 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] (7 responses)

If they think it would have that effect, then the reimplementation does make a certain amount of sense.

There is a cost involved in ensuring compliance for every single product, and with the best of will companies do often get it wrong. A lot of us have violated the GPL at times, quite unintentionally. It's easily done.

The fact of the matter is, it is only busybox which is actively defending its copyright these days. By replacing busybox, they dramatically reduce the risk of sanctions when they fail to comply with the licence.

It doesn't mean that they're intending to break the law; they're just taking the natural step to reduce their risk.

The approach does seem to be based on the idea that only busybox actually holds manufacturers to account, so it's only busybox that they need to replace in order to be able to violate the licences safely.

Even if you don't attribute malice, and you believe there's no plan to intentionally violate the licence of other projects that don't defend themselves, it does seem very cynical.

It's also naïve, because it is effectively a call for copyright-holders in other projects, especially the Linux kernel, to wake up and start to stand up for themselves rather than letting others do it for them.

FAQ for project proposal just added to wiki

Posted Feb 3, 2012 4:26 UTC (Fri) by raven667 (guest, #5198) [Link]

That's probably the most clear and unbiased summary of the whole thing.

FAQ for project proposal just added to wiki

Posted Feb 3, 2012 5:26 UTC (Fri) by dlang (guest, #313) [Link]

it's not only busybox that's defending the GPL code, gpl-violations.org is still very active, but they have different triggers for action and (based on the comments) different approaches to the companies in question.

Two different "risks" here

Posted Feb 3, 2012 12:23 UTC (Fri) by thumperward (guest, #34368) [Link] (4 responses)

You've missed the most important point here. There are two different definitions of "risk" here:

* Risk of shipping violating code
* Risk of being sued for shipping violating code

Given that BusyBox is rarely modified to any real extent by the vendors in question, the first risk is only mitigated to the extent of a megabyte of code which probably hasn't been modified anyway. This endeavour is very much intended to counter the second risk. In reality, vendors will still violate the license for software they're shipping, but it will be more difficult to address that because the simplest vector for compliance has been removed.

This is a very pragmatic choice. It is the polar opposite of an ethical one.

Chris

Two different "risks" here

Posted Feb 10, 2012 18:20 UTC (Fri) by landley (guest, #6789) [Link] (3 responses)

Once again, someone implies that it's somehow immoral for me to write new code obsoleting my old code. Here's some context for that:

I personally started the busybox lawsuits. Erik Andersen had a "hall of shame" page during his 7 years of maintainership but, didn't do anything about it. He had his father send out cease and desist letters, but if they were ignored didn't follow up.

Erik did team up with Bradley Kuhn and Eben Moglen and so on to threaten to sue linksys circa 2003, although I believe _they_ approached _him_. (And possibly Harald Welte as well, I'd have to look it up; it was before I got involved.) That action was carefully targetted and gave us openwrt and derivatives. It also caused Linksys to cease all Linux development and migrate its devices to a proprietary embedded OS for several years, but this was considered worthwhile as part of a larger overall outcome. The "embedded home router niche" hadn't _existed_ before Linksys, and now it was a ground-breakingly cheap deployment platform for open source software.

But guess what? The team of people who were _threatening_ to sue Cisco over the GPL back in 2003? They didn't actually file suit:

http://www.forbes.com/2003/10/14/cz_dl_1014linksys.html

All the work was done _out_ of court, and Cisco cooperated to _keep_ themselves out of court. The threat of a GPL lawsuit was just saber rattling to get Cisco's attention, they negotiated the release of source code _without_ever_filing_suit_.

I decided to experiment with filing actual suits to deal with the "Hall of Shame" I inherited from Erik Andersen when I took over as busybox maintainer. There was an existing, specific backlog of reports, which we expected to yield busybox code we could add to the repository. I asked Erik to cosign because he'd collected the hall of shame and what records there were consisted of his inbox, and the versions in question predated my maintainership and often my participation in busybox development. But Erik spent years not doing it, and setting the wheels in motion for it was one of my first acts as maintainer.

The 2003 Cisco effort, settled out of court without ever filing suit and yielding a mountain of useful code that opened up a new ecological niche to Linux, was nothing _like_ the current round of "sue first, ask questions later, and demand tens of thousands of dollars in legal fees and a commitment to keep paying protection money on every new product for years afterwards" the SFLC and SFC efforts have devolved into.

I'm now obsoleting the busybox lawsuits not _just_ because they drive companies away from Linux, but because nothing that's happened since 2006 has come even _close_ to openwrt. We got NOTHING OUT OF IT. All the open drivers for chips from nvidia and ati and broadcom and such we've gotten since then happened either because a company _chose_ to be nice (like Intel, hiring the xfree86 guys to push back against microsoft a bit), or because we _reverse_engineered_them_:

http://bcm-specs.sipsolutions.net/announcement.pdf
http://liquidat.wordpress.com/2007/03/04/the-forcedeth-st...
http://r300.sourceforge.net/
http://nouveau.freedesktop.org/wiki/

And so on. Sometimes Linux got support for hardware _FROM_ BSD:

http://madwifi-project.org/wiki/About/History

All this talk about lawsuits being necessary for hardware support does not match reality, and certainly was not the goal of the guy who started the suits (I.E. me).

I can show evidence that the "sue first and ask questions later" approach of stringing together a series of lawsuits to form a self-financing perpetual lawsuit machine that needs to be fed... that does way, way, way more harm than good. Because I started it, I consider stopping it (and thus ending that harm) to be my responsibility.

You're welcome to believe differently, but the facts do not support your position. I have first person experience here: you do not. You have presented no evidence in support of your position. I've asked for people to show me the code that came out of a busybox lawsuit and got merged, nobody has pointed at any. Instead they choose to weigh a purely theoretical benefit vs actual demonstrable harm.

In insulating your beliefs from challenge by facts, you are taking a position based on ideology, which does not match reality, and thus are a religious zealot, not an engineer. As with "eating meat on a friday" or "we only allow these sexual positions", it's easy to insist things are a sin a priori, because religious questions of morality do not actually require an underlying logic. Thus when logic fails, zealots start talking about morality without being able to show evidence of concrete harm to any specific persons.

(I can debate philosophy with you. But if you don't understand why I believe that we should put a teapot in orbit around Mars in honor of Bertrand Russell, you need to do some reading first.)

Rob

P.S. tl;dr - Bwahahahahahaha.

Two different "risks" here

Posted Feb 10, 2012 18:45 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

I've personally got the source code for the Nook Color and the Viewsonic Gtablet released, both of which developed vibrant developer communities who, thanks to actually being able to rebase to newer kernels by virtue of having the source, have got newer versions of Android running on the devices than the vendor chose to support.

Availability of kernel source for consumer devices is important, and the uses its been put to are surprising. There are even communities of people who develop replacement firmware for TVs. We've seen what happens without active enforcement of the GPL - most vendors simply never supply their code. Enforcement is a necessary part of giving users the freedoms that the copyright holders intended, and those freedoms make a real difference.

Two different "risks" here

Posted Feb 11, 2012 2:08 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Uhm.

R300, R600 and R800 now have public documentation and open source drivers. There's a virtual SVGA driver that provides 3D acceleration to guests which is fully mainlined.

Then there's OpenSource Broadcom driver.

Basically, the only major 'bad' companies by now are NVidia and Imgtec (PowerVR developers).

Two different "risks" here

Posted Feb 11, 2012 12:21 UTC (Sat) by khim (subscriber, #9252) [Link]

But guess what? The team of people who were _threatening_ to sue Cisco over the GPL back in 2003? They didn't actually file suit:

http://www.forbes.com/2003/10/14/cz_dl_1014linksys.html

This is factually wrong. They actually did that.

All the work was done _out_ of court, and Cisco cooperated to _keep_ themselves out of court.

As you describe in other place this "cooperation" was in form "let's sweep it under the rug, continue with sweet talk and hope FSF will eventually go away". It didn't work: FSF is extremely patient, but this is more then compensated by it's perseverance.

The threat of a GPL lawsuit was just saber rattling to get Cisco's attention, they negotiated the release of source code _without_ever_filing_suit_.

Yes. Once. And it was incomplete. And then Cisco issued new versions of both software and hardware - again with GPL violation. And as your admit when they started new "proper" effort they had no plans to do anything with old violations.

All the open drivers for chips from nvidia and ati and broadcom and such we've gotten since then happened either because a company _chose_ to be nice (like Intel, hiring the xfree86 guys to push back against microsoft a bit), or because we _reverse_engineered_them_.

Yes, but can you explain just why companies suddenly decided to be nice when they dragged their feet for years? And why are you so sure lawsuits have nothing to do with that?

All this talk about lawsuits being necessary for hardware support does not match reality, and certainly was not the goal of the guy who started the suits (I.E. me).

You may have started it, but your certainly don't have power to stop it. Simply because you don't own rights for a lot of GPLed code.

I have first person experience here: you do not.

As Kleiner said: It's difficult to see the picture when you're inside the frame. You can only talk about direct consequences of all that activity, but how can you claim that Broadcom's change of heart is not related to SFLC and SFC efforts?

You are correct when you say Never think you're _irreplacable_. Nobody is. That's certainly true. And if your goal is to make software used by millions then these lawsuits may hurt. But Stallman's initial goal was completely different: the goal was to be able to hack on the software you "own", not to spread your own software as an act of goodwill. GPL was not a goal in itself, but means to this end: if someone uses your code then GPL guarantees that you get your own code back with appropriate changes! Clever hack - but it was broken by tivoization and by blatant ignorance of GPL conditions. Solution to tivoization is obvious: GPLv3. It makes sure that manufacturer can not forbid you to modify your own code. Solution to GPL violations are lawsuits. If manufacturer does not give you enough data to start hacking on your code then what's the point of the whole exercise?

From this POV lawsuits are quite successful: a lot of companies published enough sources to make the whole classes of devices hackable. The fact that GPL stopped being the most popular license in the world is unfortunate side-effect, but alternative (GPL continues to be most popular license while manufacturers effectively treat it as BSD license) was clearly worse from FSF's POV.

P.S. It's funny that you argue are so adamantly against SFC's efforts where the only "proven disaster" happened because of FSF. FSF certainly started it's efforts way, way before your involvement. In fact G++ story happened before busybox project was even started!

Level Playing Field

Posted Feb 3, 2012 3:08 UTC (Fri) by bug1 (guest, #7097) [Link] (1 responses)

Violators need to be punished so there isnt a disincentive for complying with the GPL.

If the GPL isnt enforced then there is an incentive to violate the license, reading, understanding and respecting the license does take time.

I believe a common tactic of violators was to
- Ignore license
- Lock down device to make it hard to get caught
- If caught claim ignorance
- Wait for the Free Software community to expend time and resource explaining to them nicely what they should have done. (saving the company money)
- Drag feet
- Comply
- Repeat with next product

In particular the FSF used this softly softly approach and had trouble with repeat offenders.

There is a big cultural difference between corporations and Free software, corporations goal is to make money, if violating the license doesnt risk their profits then they have no reason to comply with the GPL.

Level Playing Field

Posted Feb 10, 2012 0:37 UTC (Fri) by landley (guest, #6789) [Link]

I'm not a Free Software developer. I'm an Open Source developer.

I consider GPLv3 yet another proprietary license. I'm sad GPLv3 undermined GPLv2 to the point it's no longer viable in a lot of contexts, but I got over it and moved on. I'm not the only one. GPL use is declining, and more active license enforcement will only make it decline faster.

(I like the Linux kernel, but busybox was ported to run on bare hardware with newlib+libgloss in 2006. Never think you're _irreplacable_. Nobody is.)

And yes, the guy who started license enforcement on BusyBox is saying that. It's what I learned from the experience. Are your positions based on experience, or on how you _want_ the world to behave?

Rob

(What I do worry about is laws that make modchipping an xbox illegal. Vendors lock game consoles down, people open them up to make unlicensed development workstations with aftermarket add-ons, and the _dangerous_ bit is rendering the aftermarket addons illegal. GPLv3 ain't gonna do that because the vendors can write their own kernel if they want to lock down their console, it just excludes our software from the relevant market. What we _need_ are laws making it explicitly legal for me to pick my own lock. These licensing tricks we're getting up in arms about are irrelevant: Linus explicitly allowed tivoization, and if minor developers start suing people over that _he_ might fork his own project enough rip out/rewrite your code, _and_ testify in the defense of whoever you're suing that his public statements on the matter _mean_ something. If they've got the "secure boot" lockdown and it's illegal for you to crack your own box, the rest is details.)

A tempest in a toybox

Posted May 31, 2012 20:06 UTC (Thu) by shentino (guest, #76459) [Link]

Seems to me that Busybox is doing a good thing by serving as a honeypot to catch code thieves and GPL scofflaws red handed.

If people weren't so keen on trying to get away with it there wouldn't be such a problem in the first place.