A tempest in a toybox

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