Clarification on a few points

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

I'm the original author of Busybox, and the person who placed the GPL upon it. I am not a party to the lawsuits regarding it. Instead, I offer my services to the infringing companies, to help them cure their infringement to the satisfaction of all developers.

BSD-like licenses can be enforced as well as the GPL, as we showed in Jacobsen v. Katzer. Many, many companies fail to follow the license presentation requirements of the BSD license. There are a great many copyright holders out there, GPL and BSD both, and we need just one who is represented in code on the device to enforce. So, I don't think you can achieve your legal goal by replacing Busybox.

As a representative of the companies that have been contacted by SFC, I have experienced the settlement terms of SFC firsthand. Those requirements are:

The infringing party must resolve all infringements in the device, whether those infringements are in Busybox or other software such as the Linux kernel.
The infringing party must provide new products containing similar software for audit before release, for a period of three years after the settlement.
The infringing party must set up a compliance program.

I've also had to pay SFC for the technical work on the audit. They charge a lot less than I do, and less than any sane legal-technical practitioner in New York City should charge.

The only unfair thing SFC does, as far as I'm aware, is that they don't involve me in the busybox cases, although I'm the original developer and my code is still present. And this is the requirement of their clients Eric Andersen and Rob Landley. So, I went to work for the other side, helping them to cure the infringement. Frankly, that side pays better anyway.

I think you're off base regarding the legal and moral stance of SFC, and your own moral position stinks. Help your clients perform due diligence, rather than helping them avoid enforcement.

Bruce Perens

to post comments

Clarification on a few points

Posted Jan 31, 2012 19:35 UTC (Tue) by tbird20d (subscriber, #1901) [Link] (2 responses)

I know who you are Bruce. I was the one at Lineo who approved paying Erik to work on Busybox, way back when. I know the Busybox history.

Help your clients perform due diligence, rather than helping them avoid enforcement.

I want to help people avoid infractions, not avoid enforcement. I think this is pretty moral.

Clarification on a few points

Posted Jan 31, 2012 19:54 UTC (Tue) by BrucePerens (guest, #2510) [Link]

Tim,

Avoid "infractions"? I guess you mean avoid unintentional infringement. Yes, they're all unintentional. But when I get to work with these companies I find that they are building multi-billion-dollar product lines and have no compliance program, little concept of due diligence, and no working connection between engineering and legal. They get their engineering from small software or chip companies who don't communicate their due diligence requirement and don't stay around to provide source code.

Or, in the case of Best Buy's Insignia line, they buy a run from a factory and don't ever have a relationship with the engineering department.

They are infringing on their proprietary technology providers as well, including ones that provide content protection technology and have really harsh penalties in their contracts and the ability to shut the vendor out of producing a broad swath of products that carry that content. They get caught by those guys as well as SFC.

The only moral, ethical solution is to help them with due diligence.

What you are now attempting to arrive at is a situation like Android, in which the entire user-mode is under a gift license but you still have the Linux kernel. So, SFC will have to work harder to find kernel developers. And then you'll scrap Linux for BSD, and SFC will end up enforcing attribution requirements in BSD, using the precedent from the appeal in Jacobsen v. Katzer.

Clarification on a few points

Posted Jan 31, 2012 23:30 UTC (Tue) by landley (guest, #6789) [Link]

If you'd just told Erik "no, spend the extra week to start over from scratch"...

Hindsight, eh?

Clarification on a few points

Posted Jan 31, 2012 20:32 UTC (Tue) by landley (guest, #6789) [Link] (16 responses)

A) I ended my participation in the lawsuits in 2008, when it became clear no code was coming out of it and that they were doing more harm than good.

B) Bruce? Show me your code still being present in busybox. I did http://busybox.net/~landley/forensics.txt and you've never actually refuted any of it. You keep repeating that you have code, but you'll never do The Thing:

"Shut up, and show me the code"

Clarification on a few points

Posted Jan 31, 2012 21:39 UTC (Tue) by BrucePerens (guest, #2510) [Link] (15 responses)

Off the top of my head:

You're not fully apprehending the context of Judge Walker's guidelines. Altai's re-implementation of CA's software in a different language was non-literal copying. On the other hand, all versions of Busybox later than mine have been directly derivative. They start with the entire body of source code that I created and the overall design, and then later versions have incremental changes. So, you could probably remove every exact line that I wrote, and I would still have an excellent case that the result remained a derivative work and that I have an actionable interest in the work.

You misuse 17.102(b) to say that certain code is not my work because you believe it's functional and thus not copyrightable.

You don't consider that I have a compilation copyright as well.

You think I will have no actionable interest in toybox, or whatever you call it, after your extensive involvement in Busybox. I could assert such an interest if provoked.

I could probably enlarge this list if I took the time. But that would be engaging with you, which isn't desirable or necessary.

Clarification on a few points

Posted Jan 31, 2012 22:01 UTC (Tue) by deater (subscriber, #11746) [Link] (1 responses)

so by your argument, the various BSDs are still derivative of the original AT&T codebase, despite all of the AT&T code being removed? Enough so that whoever owns the UN*X copyright these days could re-assert ownership rights?

Clarification on a few points

Posted Jan 31, 2012 22:22 UTC (Tue) by BrucePerens (guest, #2510) [Link]

so by your argument, the various BSDs are still derivative of the original AT&T codebase, despite all of the AT&T code being removed?

There are a lot of circumstances to the AT&T and BSD case that don't apply here. AT&T didn't maintain their copyright correctly, in a different legal context than we have today. There was no copyright by default back then, as we later got from a Berne copyright convention. They didn't properly assert their copyright. So, when they went to enforce against BSD, they found they could not do so for reasons that had nothing to do with the nature of derivative works. And Ray Noorda brokered a settlement between the parties (yes, the SCO Ray Noorda, before he went senile). We might otherwise have no BSD today.

Clarification on a few points

Posted Jan 31, 2012 22:27 UTC (Tue) by dlang (guest, #313) [Link] (12 responses)

be careful with this argument, if taken to it's logical extreme it would mean that any mistakes by a contributer to an opensource project can never be rectified, the project can only be shut down.

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

Clarification on a few points

Posted Jan 31, 2012 22:42 UTC (Tue) by BrucePerens (guest, #2510) [Link] (6 responses)

You mean the way they can't change the advertising terms in the license on SSL because of something that happened to Eric Young 20 years ago?

Yes. This sort of stuff happens. But it's a lot more complicated than your one-sentence summary. I could discuss it for at least an hour.

Clarification on a few points

Posted Feb 1, 2012 0:27 UTC (Wed) by josh (subscriber, #17465) [Link] (5 responses)

Considering how much pain the OpenSSL advertising clause has caused, I'd love to hear the details on that particular issue. Could you point to any details on what happened to Eric Young 20 years ago?

Clarification on a few points

Posted Feb 1, 2012 0:40 UTC (Wed) by BrucePerens (guest, #2510) [Link] (2 responses)

Eric was compelled to sign an agreement that he not touch the software again. He might be able to say why today, or not. I've not heard from him in a long time.

Clarification on a few points

Posted Feb 1, 2012 4:16 UTC (Wed) by josh (subscriber, #17465) [Link] (1 responses)

Ouch. I take it that "not touch the software again" also includes "give permission to relicense the software"?

Clarification on a few points

Posted Feb 1, 2012 4:36 UTC (Wed) by BrucePerens (guest, #2510) [Link]

Yes. Eric appears to still be with RSA although his blog is gone.

Clarification on a few points

Posted Feb 1, 2012 0:44 UTC (Wed) by nwnk (guest, #52271) [Link] (1 responses)

Eric got hired by RSA, who sold a product that directly competed with SSLeay, and who aren't the most open-source friendly people in the world. Since then the license to his code has not changed. I don't know whether that's Eric's choice or RSA's or somewhere in between, but it's sort of academic.

Clarification on a few points

Posted Feb 1, 2012 0:52 UTC (Wed) by BrucePerens (guest, #2510) [Link]

I suspect that it's more that RSA bought his company than that he just got hired. But you'd have to ask him.

Clarification on a few points

Posted Jan 31, 2012 22:47 UTC (Tue) by RiotingPacifist (guest, #68160) [Link] (4 responses)

Comparing any commit to a project, with Busybox's clear state as a derivative work based on earlier versions written by Bruce Perens doesn't really hold up.

Clarification on a few points

Posted Jan 31, 2012 22:58 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

my problem is that this is interpreting "derived from" to mean something pretty close to "inspired by"

This is like classic car restoration. If you take a Ford Model T and replace every piece of it, is it still a Model T? or is only inspired by one. At some point the car becomes a kit car with some Model T parts bolted on, and then as those are replaced it becomes just a kit car.

Clarification on a few points

Posted Jan 31, 2012 23:32 UTC (Tue) by RiotingPacifist (guest, #68160) [Link] (1 responses)

If you took the "hybrid" out while you were changing parts over then the "hybrid" would certainly be a derivative of the Model T and the Kit-only car a derivative work of the "hybrid".

If you built your kit car while looking at the Model T and never depend on it for either structural integrity or functionality then it would be more complicated. And obviously if you went further still and only took the spec of the Model T and reimplemented it from that then it would be "inspired" and count as clean room reverse engineering.

The real problem is that this isn't a car and the term "derivative work" has real legal meaning and precedent in the world of copyright.

I'm not saying Bruce would have any claim on Toybox purely because Langley has seen Busybox, but I would be careful.

Translations share no lines, but original author has copyright

Posted Feb 1, 2012 11:37 UTC (Wed) by coriordan (guest, #7544) [Link]

If I translate a book from Dutch to English, my work won't contain any lines of the original work, but the author of the Dutch version will still have copyright.

Whether broad copyright is good or bad for us is another debate, but we have to acknowledge that it is today broader than just exact words.

Clarification on a few points

Posted Jan 31, 2012 23:37 UTC (Tue) by landley (guest, #6789) [Link]

It's exactly the same argument SCO was making in the IBM case. "Our contribution can never be isolated, and thus can never be removed. It's an indelible essence that suffuses the text, between the lines. It's not based on copyright, on patent, on trademark, on trade secret, or on contract, but exists between all of those."

I used to refer to it as "SCO disease". For a couple years there, I got paid to help prove it wasn't true. This was shortly before you-know-who tried it.

Clarification on a few points

Posted Jan 31, 2012 20:42 UTC (Tue) by tytso (subscriber, #9993) [Link] (5 responses)

Speaking as someone who has a non-trivial amount of kernel code in my name (contributed before I started working for a Linux company), my huge objection to the SFC is their interpretation of the GPLv2 license, in particular about "scripts to control compilation and installation of the executable". To my mind, their expansive interpretation of that clause is tantamount to an anti-Tivoization clause, which is the primary reason I and many other kernel developers rejected the GPLv3 license.

So when he uses a busybox breach to try to enforce his view of the GPLv2 license on code that *I* own, I'm naturally going to object and consider his actions wrong from a moral and ethical point of view. Which is why I'm completely supportive of the Toybox effort.

That's not to say that I support blatant violations of the GPL; if there are manufacturers of Android devices that aren't coughing up source code, then we should go after them. But using busybox as a backdoor way of enforcing an anti-Tivoization effort as it applies to the Linux Kernel is Just Wrong. And as a result, if I were going to go after someone who was abusing the copyright on the Linux Kernel, the SFC wouldn't be my first choice as lawyers...

(Speaking only for myself, and not for any of my current or previous employers...)

Clarification on a few points

Posted Jan 31, 2012 21:56 UTC (Tue) by BrucePerens (guest, #2510) [Link] (4 responses)

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.

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.

Clarification on a few points

Posted Feb 10, 2012 10:40 UTC (Fri) by laf0rge (subscriber, #6469) [Link]

Is it really true that there was a requirement for audits of future source code releases? I spoke with Bradley Kuhn a couple of days ago, and he explicitly stated that there never was such a requirement or demand. Apparently they unilaterally _offer_ doing such reviews in the future. but that's completely unrelated to whether they reinstate the license or not.