A tempest in a toybox [LWN.net]

A tempest in a toybox

Posted Feb 1, 2012 17:05 UTC (Wed) by Uraeus (guest, #33755)
Parent article: A tempest in a toybox

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.

to post comments

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.