Clarification on a few points

I think we all agree on the fact that complying with the licenses is extremely simple and I do think that enforcement to have this corrected is actually a good thing, since it often serves as a wake up call to companies to fix their processes.

Asking for fixing things that are outside of your own copyright (and which is unlikely you could enforce easily anyway) like binary kernel modules, review rights and veto rights for future firmwares and devices, plus asking to be reimbursed for that review (again, this is not just something that Best Buy said) sounds like a clever hack, but they are overreaching and shooting themselves in the foot here, because it is asking for your software to be replaced.

I would also be surprised if these claims would hold up in courts in Europe. I very much doubt it (but IANAL, I just like to hang around them and ask them lots of questions). I should ask more lawyers about this.

this is handing power to copyright intrests that big media only dream of right now.

You're correct that Bradley with his SFC hat on doesn't ask for encryption or signing keys; that was my misunderstanding. However, they *do* ask for a firmware image that contains the binary in question and ideally the ability to install that image onto the device. Merely creating a binary executable and including the makefile that does the "make install" step isn't enough from them. They want a firmware image that looks similar to what is in the original ROM image. If, hypothetically speaking, that firmware image (say, pre-encryption) also happens to include content-protecting DRM encryption keys where disclosure of said keys would result in the Content Cartel's legal sharks to come after a defendant --- which trust me are way more scary than the SFC lawyers --- it can leave the recipient of that enforcement action in a very tight place. Personally, I wouldn't have pushed as hard in the settlement talks, given my limited knowledge of the case, but that's neither here nor there. I'm also guessing that part of the problem was once the adversarial legal approach was invoked, it's very hard to avoid lawyers misunderstanding technical terms, which just draws things out once you try to negotiate remediation steps.

On a more constructive side of things, I think the best way forward is to focus on education vis-a-vis how not to get into this situation in the first place. i.e., make sure you have clean separation between your proprietary and non-proprietary binary content (i.e., put things like Blu-ray keys in separate protected partitions or hardware, and don't mix it with GPLv2, and especially not with GPLv3 licensed code).

It also seems that given that the SFC has become the "bad cop", they have acquired a reputation of being litigation-happy, which from my conversations with Bradley, is an unfair rap. The question is whether they can assuage Tim's fear that an "accidental mistake" by a downstream user of some device incorporating Busybox or other GPL'ed code won't result in the SFC going nuclear on them, without companies trying to game the system by knowing how close to the line they can get. As one example, consider the HTC loophole (i.e., "as long as we respond in 3-6 months, we don't have to be afraid of getting sued") --- although the reality is if you're going to litigate, it's probably going to be 3-6 months minimum, since the wheels of justice grind slowly. And of course, litigation has many other costs other than just the legal fees. One of them is it increases the FUD involved with using your software project.

At the end of the day, it's a question of how can we make using open source code in general, and busybox in particular, not scary. My big concern from the general perspective is that people will get scared enough by the perception that there are over-zealous, litigation-happy parties out there, that they decide to not to use the Linux Kernel, and either (a) decide to use a pure proprietary solution, such as QNX, or (b) go to a BSD or Apache-licensed OS or userspace, such as FreeBSD.

One approach (at least for busybox; fortunately the Linux kernel developers don't have this litigation-happy reputation) is of course to re-implement a BSD-licensed equivalent, and that's the approach Tim has taken. Another approach is to educate the embedded manufacturers and tell them here are the bright lines which will allow them to be safe, even if they want to use Linux to implement a Blu-ray player that needs to have very stringent DRM requirements. And, that staying in bounds of these bright lines really isn't that onerous. That is, use the carrot and not the stick. Ultimately, I think that's the much more productive approach compared to litigation, and to the extent that the SFC (from my conversations with Bradley) views litigation as a last resort, I think they would agree with this latter approach of education of the embedded vendors.

-- Ted

P.S. Not that I'm in favor of that kind of DRM; in fact I generally refuse to buy Blu-ray DVD's (there are cases where both the DVD and Blu-Ray DVD are included in the same case, where I might decide to buy said combined package). I just don't believe in using the heavy club of Copyright and the GPL as a way of imposing my beliefs on others. That's a philosophical belief for which men and women of good will have disagreed about, though, so I respect that other people may feel differently about things like GPLv3's anti-Tivo clause.

I guess a similar approach to software quality would be, "just don't write bugs."