|
|
Subscribe / Log in / New account

Clarification on a few points

Clarification on a few points

Posted Jan 31, 2012 21:56 UTC (Tue) by BrucePerens (guest, #2510)
In reply to: Clarification on a few points by tytso
Parent article: Garrett: The ongoing fight against GPL enforcement

Ted,

You're over-stating their request for "scripts". I have represented a client where SFC made this request, and they asked for a non-encrypted version of the binary from a step just before encryption. They never asked for keys.


to post comments

Clarification on a few points

Posted Feb 1, 2012 0:20 UTC (Wed) by tytso (subscriber, #9993) [Link] (3 responses)

I just finished talking to Bradley, and I got a better clarification of what was going on with one particular enforcement action that I was concerned about.

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.

Clarification on a few points

Posted Feb 1, 2012 1:32 UTC (Wed) by landley (guest, #6789) [Link] (2 responses)

I tried to come up with bright lines for busybox. I tried to make them easy to follow.

http://lists.busybox.net/pipermail/busybox/2008-October/0...
http://busybox.net/license.html

It didn't help in the slightest.

Rob

Clarification on a few points

Posted Feb 1, 2012 4:40 UTC (Wed) by tytso (subscriber, #9993) [Link] (1 responses)

Rob, note that the SFC is demanding way more than just the .config file, as you stated in the busybox web page. So that's a bit of an inaccuracy in that web page that you've sited. They also are demanding the scripts that create a firmware image that includes the busybox executable. Whether or not this is really required by the GPL is a question which (as far as I know) no court has ever ruled on point.

Clarification on a few points

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

Whether or not this is really required by the GPL is a question which (as far as I know) no court has ever ruled on point.

And I doubt it'll rule on it any time soon. SFC does not sue companies which tried to comply with GPL and just forgot to include couple of scripts in a tarball. It sues companies who blatantly violate it (that is: they neither give you source with binaries nor give you a written offer to provide such sources). When SFC is involved GPLv2 terms are no longer in play: offenders violated it, lost their rights and now must beg for forgiveness.

Of course it does not mean that the your question (is it fair to demand scripts used to build the image with GPLed component?) suddenly evaporates. But at this point it's morphed to the area of moral and conscience, not law.

How to avoid this problem? It's simple: publish the sources of the GPLed components. Toybox is not a solution. It may be first step on the path to the "true solution" (abandonment of all the GPLed components), sure. But if the plan is to remove all the GPLed components altogether, then I'd like to see the project with milestones and roadmaps.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds