User: Password:
|
|
Subscribe / Log in / New account

Clarification on a few points

Clarification on a few points

Posted Jan 31, 2012 18:01 UTC (Tue) by tbird20d (subscriber, #1901)
Parent article: Garrett: The ongoing fight against GPL enforcement

Reasonable people can disagree on whether this is a good idea or not. As the un-named Sony developer mentioned in the article, I hope I can give some perspective that will help explain the issues better.

First and foremost, I need to clarify that this is not a "Sony project". I am working on this in my role as an embedded Linux industry advocate, who tangentially happens to be a Sony engineer. Those who see some Sony conspiracy here can take off their tinfoil hats.

It is NOT the goal of this to help people violate the GPL, but rather to decrease the risk of some nuclear outcome, should a mistake be made somewhere in the supply chain for a product. For example, it is possible for a mistake made by an ODM (like providing the wrong busybox source version) could result in the recall of millions of unrelated products. As it stands, the demands made by the SFC in order to bring a company back into compliance are beyond the value that busybox provides to a company. I also believe they are wrong from both a legal and moral perspective.

I recognize full well that some companies are not living up to their GPL obligations. At the same time, everyone I work with and talk to is working hard to comply with the GPL. In particular, I am proud of Sony's track record of GPL compliance. See Sony's Source Code download site.

However, companies and people do sometimes make mistakes. In my own experience, the remedies requested by other agents and organizations working for GPL compliance are much more productive than those of the SFC. Given the current situation, it makes sense to reduce the probability of mistakes, and their legal repercussions.

It is a shame that such a project is needed. But it is primarily needed, in my opinion, due to the overreach of the busybox litigators. I believe the project represents an ethical and pragmatic solution to this particular legal challenge.


(Log in to post comments)

Clarification on a few points

Posted Jan 31, 2012 18:10 UTC (Tue) by epa (subscriber, #39769) [Link]

You could instead add a --dump-source option to busybox which prints the complete source code to stdout. This code would be baked into the executable during the build process and so always up to date. Vendors could ship the binary executable of busybox without worries.

Clarification on a few points

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

The source code to busybox, as a compressed tarball, is bigger than the binary of busybox. Since small size is one of the major design criteria in embedded software...

Clarification on a few points

Posted Feb 1, 2012 10:20 UTC (Wed) by rvfh (subscriber, #31018) [Link]

Yeah, but memory usage is the main issue these days, not hard-disk usage, so there would be a way to have the source code ready to be grabbed but never loaded into memory.

When there is a will, there is a way :-)

Clarification on a few points

Posted Feb 1, 2012 11:18 UTC (Wed) by epa (subscriber, #39769) [Link]

About 1.6 megabytes compressed with lrzip -z. Add a bit more for the decompression code and it comfortably fits in two megabytes, which is not expensive given current flash memory prices.

Clarification on a few points

Posted Jan 31, 2012 18:34 UTC (Tue) by rahvin (subscriber, #16953) [Link]

So you deny this is to avoid helping people violate the GPL then go on the state that this is being developed so that when people do violate the GPL they don't have to answer for that because you morally disagree with the level of penalty that SFC imposes.

According to what I just read you are doing exactly what you claim you aren't doing. By your own words this is being developed so that if "someone" violates the GPL they can avoid infringement discussions with the SFC, or in other words to avoid enforcement of the GPL.

It would seem from this that the original call to have Kernel developer step forward and allow their code to be used for enforcement is a very valid call to the development community as your work is specifically to allow people to use GPL software without having to worry about the legal consequences of non-compliance. IMO there should be a bite to non-compliance, regardless of intent. What the SFC asks is nothing in comparison to the millions you would have to pay for violating the licenses of any commercial product.

It's be really nice is one of the major developers of the Kernel stepped forward.

Clarification on a few points

Posted Jan 31, 2012 18:58 UTC (Tue) by armijn (subscriber, #3653) [Link]

There are of course the documents that were submitted to the court in the Best Buy case:

http://terekhov.de/178.pdf

Search for 'veto' on pages 6, 13 and 25.

I can very well understand that a company would decide to *not* use BusyBox in future products when confronted with such claims.

Clarification on a few points

Posted Jan 31, 2012 19:12 UTC (Tue) by rahvin (subscriber, #16953) [Link]

There's two sides to every lawsuit, you are quoting a single filing by the company that violated the GPL and is trying to defend it's violation.

Personally I have no objection to what the SFC does as they are simply asking people to comply with the license they agreed to when they used the code to begin with. That they were using BusyBox as a lever on all GPL code doesn't change the fact that the infringing companies in question would have NEVER opened that door had they no infringed the license to begin with. As others have pointed out, if they are violating the GPL on Busybox they are likely violating it on all the GPL code.

It's pretty darn simple, if you can't comply, or can't make your suppliers comply with the license don't use GPL code in your product. There's no altruism here, the companies are using GPL code because it saves them a bundle of money. That they can't comply with the extremely simple requirements of code availability speaks volumes to the incompetence of the companies involved. Let them instead go license a commercial software that they can't modify and if they violate the license they will be on the hook for millions per infraction with a supplier that is guaranteed to sue them. I bet they keep using the GPL give the other option.

Clarification on a few points

Posted Jan 31, 2012 19:48 UTC (Tue) by armijn (subscriber, #3653) [Link]

I expected this answer. I have actually talked to several companies in this field in Asia, and they all say the exact same thing, so it is not just Best Buy.

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.

Clarification on a few points

Posted Jan 31, 2012 21:33 UTC (Tue) by dskoll (subscriber, #1630) [Link]

It's pretty darn simple, if you can't comply, or can't make your suppliers comply with the license don't use GPL code in your product.

So then... isn't that what the developers of the Busybox replacement are doing? They're making it possible to not use GPL code in your product at least as far as Busybox is concerned.

Clarification on a few points

Posted Jan 31, 2012 21:40 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

But they'll still be using the kernel, which is much larger and more likely to contain components from a wide array of suppliers. If you can't get compliance right for Busybox then you stand no chance of managing it for the kernel.

Clarification on a few points

Posted Jan 31, 2012 21:51 UTC (Tue) by dskoll (subscriber, #1630) [Link]

But they'll still be using the kernel,

Assuming they're using the Linux kernel. Busybox can be used on a BSD kernel, no?

Clarification on a few points

Posted Jan 31, 2012 21:56 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

I'm not aware of any cases where people have been shipping devices with Busybox on non-Linux kernels. If you're using BSD then it's more common to just build the tools you need with crunchgen.

Clarification on a few points

Posted Feb 1, 2012 0:01 UTC (Wed) by landley (subscriber, #6789) [Link]

Busybox's include/platform.h was added on my watch to support the guy building against libgloss and the people who wanted to build against MacOS X and so on.

That said, board support packages usually provide kernel source because it's one package and you usually have to rebuild it to tailor it to the hardware. They don't necessarily rebuild the base userspace.

For example, at my day job the "bringup" department I'm working for has built kernels for three different new product boards since I got here. I build kernels every day. And each time they use a binary arago root filesystem tarball that hasn't been recompiled since I got here, with a toolchain they got from code sourcery in 2009. (The bringup department then hands said kernels off to the Android guys, who replace the root filesystem with Android stuff they get from Google, and layer their own stuff on top of it as android packages. Neither the kernels nor root filesystems actually _ship_, I'm just trying to make the hardware work and then they put android on it.)

Google's already excluding all GPL code from userspace, and android developers are happy to go along with it. I'm building a package the android guys might actually get to _use_. Busybox has existed since before android shipped, and doesn't get used on android, and isn't going to. Arguing whether or not it _should_, or how they'll come around if we wait for the sun to go out, has nothing to do with reality.

Linus Torvalds stopped waiting for the android developers to come around to his way of thinking, and started merging their code. I've usually considered Linus a good model. (Remember how he used a non-GPL license for Sparse because he was fed up with the FSF? I suspect git was only GPLv2 to quiet the "oh no bitkeeper"! hysteria, but haven't asked.)

I keep hearing people go "what, are they going to rewrite the kernel next if we make a big enough fuss about it"? And I keep going "MacOS X is BSD based became the most profitable company in the world using that; you think Google can't switch to that in a single development cycle if they really wanted to?"

Linux has stayed unified because of _LINUS_. Thinking that "oh it can't fork, it's GPL"... Android kernel anyone?

Red Hat almost standardized on Alan Cox's kernel back when Linus overloaded and spent months dropping patches (anybody remember my old "Patch Penguin" rant?), and Alan took a year off to go back to grad school to FORCE everybody to work with Linus (who took up bitkeeper to solve the scalability issue). The license has _helped_ keep Linux unified, but it's the community that's actually done it. The community of kernel developers who _REJECTED_ GPLv3, sidelined Richard Stallman, and never BOTHERED to launch widespread license enforcement lawsuits because they are a BAD IDEA. There's some saber rattling, but suing potential allies generally doesn't bring them closer to you. This isn't a defeat = friendship world.

Me, I reinvent the wheel a lot (hence working on busybox). I had to prove for myself that they're a bad idea. So I ran the experiment, and I reported the results, and whadaya know: It's a bad idea.

(I can't help it if other people want to repeat my mistakes and insist on finding out for themselves that fire is hot, but telling the guy with firsthand experience that you know more about it than he does gets old after a while.)

Clarification on a few points

Posted Feb 1, 2012 1:50 UTC (Wed) by Duncan (guest, #6647) [Link]

> Google's already excluding all GPL code from userspace, and android developers are happy to go along with it.

In practice, that remains to be determined in a court of law -- the Oracle case. What happens if Oracle wins? Google would have to pay penalties for past shipments, sure, but that doesn't resolve the future shipment problem.

What happens if they can't agree on a solution for future shipments? Google would have two alternatives, either quit shipping something they're doing 700K activations a day of, or suddenly reverse course on a GPLed userspace and keep shipping. Of course they /might/ have a third option lined up too, an independent replacement. But that would be a compatibility nightmare.

What I've been hoping for all along is pretty much just this scenario. There's a large enough Android ecosystem out there that any way this scenario plays out would set the whole tech world ringing with the implications. Would google and the rest of the ecosystem simply quit shipping? OUCH! Or would they bite the bullet and gamble that whatever the anti-GPL case was before, Android's too big to stop now just because it ends up being GPLed userspace? How much of the ecosystem would stay with them if they did?

Of course, that would put the ball back in Oracle's court as well, effectively calling their bluff on their GPLed Java. The risk is a toppling of the entire copyleft ecosystem and community, but imagine what a reputation the GPL would have if it survived THAT, regardless of how the rest of it plays out, Oracle trying to reverse course on Java's GPLing, OR challenging its patent provisions so that bit gets settled, OR folding and allowing Google to continue shipping, of course with rather zealous enforcement of the GPL provisions from someone with the money to do so, in an attempt to discourage everyone else from taking that same out.

That's still an unlikely scenario, but the first part of it, Google continuing to build Android shipments to the point where it /might/ be practical to force a GPLed userspace, and have people actually accept it, has certainly happened. Thus, the odds are far better than they were when that whole feud started.

And if Oracle /did/ choose the patent challenge route, it could very easily result in the whole tech world "going patent nuclear", thus very possibly settling the patent wars once and for all once all the dust settles, as well. Even if it didn't result in the patent world "going nuke", it should at least resolve the patent issues one way or another for the GPLv2, thus resolving all sorts of GPL community issues in that regard. If the GPLv2's patent provisions such as they are hold, it's solve a lot of Linux patent issues, and if they don't, well, the predictions leading to the GPLv3 would have been demonstrated to be true, and the GPLv2 licensed Linus kernel will end up being far closer license-wise to the BSDs than it is now, at least for anyone with patents.

So, yeah, while Google has to date taken a hard line on a GPLed Android userspace, that could yet change. I guess we'll see how this Oracle/Google case plays out at the trial court level at least, pretty quickly, now. There will certainly be appeals and it's likely to play out for years either way, just as SCO did, but the Android ecosystem and even the larger mobile computing ecosystem is I think way bigger already than the entire Linux ecosystem was when SCO started, and the waves could thus be MUCH MUCH bigger... either way!

Duncan

Clarification on a few points

Posted Feb 1, 2012 21:52 UTC (Wed) by Wol (guest, #4433) [Link]

Just to add to this - READ GROKLAW.

Firstly, Oracle launched this as a patent suit. Unfortunately for them, the patents have been comprehensively gutted.

Secondly, they threw in the copyright stuff as a side dish. Unfortunately, it seems to be all they've got left. And it's pretty irrelevant, because Google (a) never used the code in question, and (b) only distributed it by accident. It's a few lines of code (measured in hundreds of LOC if that), and it's part of the test suite that should NEVER get onto any shipping device.

Cheers,
Wol

Clarification on a few points

Posted Feb 1, 2012 21:57 UTC (Wed) by Wol (guest, #4433) [Link]

Whoops - I missed your comment about *if* Oracle choose the patent challenge route.

But, as you'll see from my other post, they DID choose the patent challenge route. And it seems the nuke detonated on launch ...

I can't remember all the figures, but they tried to sue over about 250 claims. The Judge said "that's too much, whittle it down to your best 15" or something like that. Google returned a major broadside and it seems out of those 250, Oracle is unlikely to find 15, or whatever it was the Judge said, to bring to trial! They might even get to trial only to find they don't have any valid patents to claim!

Cheers,
Wol

Clarification on a few points

Posted Feb 1, 2012 11:41 UTC (Wed) by mitchskin (guest, #32405) [Link]

Android does have some (L)GPL code in userspace: dbus, bluez, and webkit at least.

GPL in Android userspace

Posted Feb 2, 2012 12:58 UTC (Thu) by simonkelley (subscriber, #17525) [Link]

Android also has dnsmasq, which is GPLv2/GPLv3, in userspace. When they first started talking about removing GPL userspace I offered Google a license on pretty much any terms they wanted but covering use in Android only. They wouldn't take the "Android only" part, and dnsmasq is still in Ice Cream Sandwich under the GPL.

Clarification on a few points

Posted Feb 2, 2012 10:50 UTC (Thu) by paulj (subscriber, #341) [Link]

Google's already excluding all GPL code from userspace,

Hmm, Android's bluetooth support relies on Bluez, which is GPLv2+. Google stuck some IPC in between the Android stuff and the Bluez libraries, but I doubt that achieves the GPL-washing effect that Google are trying for, should BlueZ copyright holders ever care to do something.

So unless that's changed, your statement above appears to be incorrect.

Clarification on a few points

Posted Feb 1, 2012 0:41 UTC (Wed) by Trelane (subscriber, #56877) [Link]

> Search for 'veto' on pages 6, 13 and 25.

The allegations are there, but not the exhibits. Where is the original text that requested the alleged veto?

Clarification on a few points

Posted Feb 1, 2012 13:34 UTC (Wed) by k3ninho (subscriber, #50375) [Link]

I have inferred that there was an attempt to strong-arm Best Buy (and possibly other settled infringers). That might not be true - it's not set in a context how far the 'veto' situations go. If not true, disregard the following:

Coercion? Is anyone involved with SFLC a parent? Anyone know what 'positive reinforcement' looks like?

It boils down to this: the winning play has to be that non-compliant companies get help to remake their internal processes in such a way that they comply with the licence, then they get help to communicate how easy that is to other organisation with whom they do business.

Trying to coerce, hamstring, or force collusion seems to me to be contrary to the advocated 'freedom' behind the original software projects (not to mention the prospect of skewing market competition and the negative publicity that would bring). You just can't let that kind of bullying go. Perhaps there's a reply which claims 'this is all these corporations know and the only way we can interact with them': don't forget that the opportunity to do it differently is still there and can set an example of the better way to do things that is collaborating with the free and open source software development communities.

Take care.
K3n.

Clarification on a few points

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

I think you misunderstand what I said. This is not to allow companies to violate the GPL, it is to help them (and mostly their suppliers, really) use non-GPL software. That way, if the supplier makes a mistake and can't find the exact source for the non-GPL software, nobody is on the hook for litigation and extreme remedies.

In practice, it would make things easier if my suppliers didn't ship any GPL user-space code to me. At Sony, we'll put on our own user-space GPL code. We have good practices in place for managing our GPL responsibilities in this case, thank you very much. In the case of kernel code, to my knowledge we've never had a problem with a supplier providing correct sources for this.

I understand why this is sub-optimal in the grand scheme of things, because it detracts from the community value of GPL user-space code.

Clarification on a few points

Posted Jan 31, 2012 20:38 UTC (Tue) by landley (subscriber, #6789) [Link]

The easiest way to avoid violating the GPL is not to use it. People here are screaming because that's not the behavior they WANT, but wanting water to flow uphill doesn't make it happen.

Did you guys not NOTICE?

http://www.itworld.com/it-managementstrategy/233753/gpl-c...

Google's "No GPL in userspace" thing is very much _not_ an isolated incident. Those of us who were big GPLv2 advocates and don't like GPLv3, what did you EXPECT us to do when you tried to shove v3 down our throats?

Clarification on a few points

Posted Jan 31, 2012 20:58 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

These numbers, in themselves, don't prove anything about a change in attitudes towards the GPL. The *absolute* number of GPL projects is increasing. The relative number is certainly decreasing, but how much of that is because people who previously liked the GPL no longer do and how much of it is because more people are coming to free software development from a web background with less tradition of strong copyleft licenses?

Clarification on a few points

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

According to netcraft the absolute number of IIS web servers has been increasing steadily too, ever since the 1990's.

Clarification on a few points

Posted Jan 31, 2012 23:47 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

Yes, and that's equally meaningless as an individual statistic. Extracting meaning takes knowledge of population changes.

Clarification on a few points

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

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

Clarification on a few points

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

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 (subscriber, #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 (subscriber, #6789) [Link]

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]

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]

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 (subscriber, #313) [Link]

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]

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]

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]

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]

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]

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]

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 (subscriber, #313) [Link]

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]

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 (subscriber, #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]

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]

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]

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 (subscriber, #6789) [Link]

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]

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.

Clarification on a few points

Posted Jan 31, 2012 20:37 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> It is NOT the goal of this to help people violate the GPL, but rather to decrease the risk of some nuclear outcome, should a mistake be made somewhere in the supply chain for a product. For example, it is possible for a mistake made by an ODM (like providing the wrong busybox source version) could result in the recall of millions of unrelated products.
As Bruce Perens pointed out earlier, SFC's settlement terms have always been very reasonable, so there's no "nuclear outcome" to be expected. Given the current state of affairs, the only conceivable purpose of your project is actually what you deny it to be: avoiding GPL enforcement. So I'm sorry, but I believe you're lying to us.
Besides, it's a really, really lame excuse anyway. It really isn't that hard to just read and follow the bloody license. If people fuck it up nevertheless, they deserve to be punished.

Clarification on a few points

Posted Feb 1, 2012 13:45 UTC (Wed) by masoncl (subscriber, #47138) [Link]

Busybox represents an unknown...just because the cases so far have gone a certain way doesn't mean they always will. It's easy to imagine doing some math on a napkin and coming to Tim's position. It's free software, and he's equally free to not use it.

But, I'd certainly be more comfortable with a project to ensure compliance in the providers. It's easy to assume the suppliers would be willing to prove compliance if they didn't get paid until it was proven.

I admit this is a simple view of a very complex supply chain (sorry Tim). The suppliers still must prove the replacement is used instead of busybox. Why not just check the sources provided instead?

This is a fixed R&D cost (not a per-unit cost), and big electronics companies force suppliers to conform to all kinds of rules and specifications. They also do a range of tests on the fully assembled devices.

It's fair for us to expect compliance to be one of those tests.

Clarification on a few points

Posted Feb 1, 2012 16:03 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> Busybox represents an unknown...just because the cases so far have gone a certain way doesn't mean they always will.
Sure, the busybox copyright holders might make you jump through all kinds of hoops if you violate their copyright. Well, don't do that then!

Clarification on a few points

Posted Feb 1, 2012 21:30 UTC (Wed) by bronson (subscriber, #4806) [Link]

Thanks for that insight on a complex subject.

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

Clarification on a few points

Posted Feb 1, 2012 21:42 UTC (Wed) by HelloWorld (guest, #56129) [Link]

How is this a "complex subject"? It's really not that hard to ship a leaflet that explains the customer's rights with the product and put a tarball on an ftp server. All I keep hearing is lame excuses.

Clarification on a few points

Posted Feb 2, 2012 23:13 UTC (Thu) by bronson (subscriber, #4806) [Link]

Have you negotiated with suppliers? Tried to evaluate their complex and hacky toolchains and whether your project should rely on them? It can get nightmarish even without worrying about GPL compliance.

Attacks on the SFC for being too aggressive

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

A lot of people attack the SFC for being too aggressive, but it wasn't until the SFC started an aggressive campaign, using Busybox as a weapon (around 2006/2007), that as a consumer I started seeing devices released with little GPL leaflets and the source code available for download.

I don't know if any of the devices I've seen were as a result of direct action against the vendor, but the actions of the SFC, FSF and others surely helped encourage vendors to comply.

Now for a bad analogy: If a Sony caught somebody downloading one track, I'm sure they would insist on checking everything else the copyright violator owned for further violations and the SFC's aggressive litigation demanding to review other products for more GPL'd code is no worse. Only in this case the defendant's tend to be large corporations who can afford to go the distance instead of college kids and grandmothers!

P.S I know you are suggesting the project outside of your work for Sony but surely you can't expect to take the moral high ground against the SFC while working for such a litigious and ethically bankrupt company.

Disclaimer:I know nothing and no-one, this is just my opinion as an end user!

Clarification on a few points

Posted Feb 1, 2012 9:49 UTC (Wed) by niner (subscriber, #26151) [Link]

> As it stands, the demands made by the SFC in order to bring a company back into compliance are beyond the value that busybox provides to a company. I also believe they are wrong from both a legal and moral perspective.

You are working for Sony, a company that sues teenagers over several times their lifetime incomes for copyright violations while at the same time breaking the law by installing rootkits on customer's computers and which likes to break products after they sold them.

Sony has no moral standing whatsoever. None.

> I am proud of Sony's track record of GPL compliance.

Being proud of Sony sometimes not breaking the law? Yes, that's certainly impressive.

> However, companies and people do sometimes make mistakes

Tell that to Sony's lawyers. They somehow see matters not as lenient.

Clarification on a few points

Posted Feb 1, 2012 11:55 UTC (Wed) by anselm (subscriber, #2796) [Link]

You are working for Sony, a company that sues teenagers over several times their lifetime incomes for copyright violations while at the same time breaking the law by installing rootkits on customer's computers and which likes to break products after they sold them.

Hang on. The Sony company that does these things (Sony BMG/Sony Music Entertainment) and the Sony company that sells gadgets with Linux inside (Sony Electronics) aren't the same.

Clarification on a few points

Posted Feb 1, 2012 12:22 UTC (Wed) by niner (subscriber, #26151) [Link]

All these so different Sony companies belong to Sony Corporation. They answer to the same board. The ones you mentioned share a common root even on a lower level at Sony Corporation of America.

It's like "let's put all our questionable businesses into a separate corporation, so we share all the income but not the blame".

Sorry, I just don't buy your argument. It's a Sony.

Clarification on a few points

Posted Feb 1, 2012 12:49 UTC (Wed) by anselm (subscriber, #2796) [Link]

Right. So having a brother who's a sleazy lawyer automatically makes you sleazy, too.

Incidentally, Sony BMG, of the 2005 rootkit scandal, wasn't even a 100% Sony subsidiary – it was a joint company, half of which consisted of Bertelsmann Music Group (hence the »BMG«), a subsidiary of Bertelsmann AG. Sony bought Bertelsmann's share in the venture only in 2008, to (re-)make Sony Music Entertainment.

Clarification on a few points

Posted Feb 1, 2012 13:04 UTC (Wed) by ekj (guest, #1524) [Link]

Not unless you and your brother both stand under the direct command of the same entity. But if you do, then totally yes.

If Sleazy Inc owns companies A and B, then yes, A doing something evil does reflect poorly on B, and it makes total sense to (for example) consider B without moral standing, based on the actions of A.

It makes sense because the same single board controls both A and B.

If your left hand engages in aggression towards me, I'm totally going to consider your right hand a potential threat: because I'm aware that both of your arms are controlled by the same entity.

Clarification on a few points

Posted Feb 1, 2012 14:41 UTC (Wed) by leoc (subscriber, #39773) [Link]

Please correct me if I am wrong but it is your Sony that made the PS3, widely advertising its support for running Linux and then retroactively removed the function after many people bought it just for that purpose?

Clarification on a few points

Posted Feb 1, 2012 15:54 UTC (Wed) by anselm (subscriber, #2796) [Link]

This is something the original poster might justifiably have criticised but didn't.

One thing to take away from this is that huge companies like Sony (or for that matter Microsoft) may employ people who are reasonable if not downright nice, and whose actions have no bearing on the actions of their colleagues in other parts of the company (or related companies). Refusing to talk to these people, or calling them names, on the grounds that they have sleazy colleagues who ultimately answer to the same CEO (probably with seven tiers of different intermediate managers in-between) doesn't lead us anywhere.

Nothing personal, just business ?

Posted Feb 1, 2012 21:41 UTC (Wed) by khim (subscriber, #9252) [Link]

Sorry, but this is exactly how we've ended in this mess: reasonable if not downright nice people work for nasty companies with justification that it's Ok because it's big company and they can not do anything means that companies feel free to continue to harass customers, lobby for draconian laws, etc.

Sorry, but no. Justification that you just have sleazy colleagues who ultimately answer to the same CEO does not make it Ok even you personally have done nothing atrocious. Now, I'm not saying everyone should forget about their life, family and declare jihad against nasty companies despite onerous personal costs. If you have no reasonable choice and are forced to work for the nasty company then noone will condemn you. And if you were just offered 50% bigger compensation - then that's fine, too (if companies will know that their nastiness can cost them real money they will adjust, they are not stupid). But in all cases you should be slightly ashamed and look for the other opportunities if possible, not try to explain that "this SONY is not like that other SONY, no, they are totally different". This is your SONY and your actions will be viewed in light of "that our SONY" decisions.

Clarification on a few points

Posted Feb 1, 2012 16:20 UTC (Wed) by bpearlmutter (subscriber, #14693) [Link]

Really? Can I buy some shares of Sony Electronics without buying any shares of Sony BMG/Sony Music Entertainment?

Clarification on a few points

Posted Feb 2, 2012 10:41 UTC (Thu) by paulj (subscriber, #341) [Link]

I am working on this in my role as an embedded Linux industry advocate, who tangentially happens to be a Sony engineer.

Are you saying that this work is not approved of or funded in any way by Sony (i.e. the corporate management infrastructure that oversees you)?

Otherwise, if you're doing this as part of a role funded by Sony, then you're acting in Sonys' interests as their agent. And in which case, you can't seriously think you can divorce what you do for your work from those who fund it?


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