Clarification on a few points
Clarification on a few points
Posted Jan 31, 2012 18:34 UTC (Tue) by rahvin (guest, #16953)In reply to: Clarification on a few points by tbird20d
Parent article: Garrett: The ongoing fight against GPL enforcement
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.
Posted Jan 31, 2012 18:58 UTC (Tue)
by armijn (subscriber, #3653)
[Link] (15 responses)
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.
Posted Jan 31, 2012 19:12 UTC (Tue)
by rahvin (guest, #16953)
[Link] (12 responses)
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.
Posted Jan 31, 2012 19:48 UTC (Tue)
by armijn (subscriber, #3653)
[Link]
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.
Posted Jan 31, 2012 21:33 UTC (Tue)
by dskoll (subscriber, #1630)
[Link] (10 responses)
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.
Posted Jan 31, 2012 21:40 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link] (9 responses)
Posted Jan 31, 2012 21:51 UTC (Tue)
by dskoll (subscriber, #1630)
[Link] (8 responses)
But they'll still be using the kernel,
Assuming they're using the Linux kernel. Busybox can be used on a BSD kernel, no?
Posted Jan 31, 2012 21:56 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link] (7 responses)
Posted Feb 1, 2012 0:01 UTC (Wed)
by landley (guest, #6789)
[Link] (6 responses)
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.)
Posted Feb 1, 2012 1:50 UTC (Wed)
by Duncan (guest, #6647)
[Link] (2 responses)
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
Posted Feb 1, 2012 21:52 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
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,
Posted Feb 1, 2012 21:57 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
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,
Posted Feb 1, 2012 11:41 UTC (Wed)
by mitchskin (subscriber, #32405)
[Link] (1 responses)
Posted Feb 2, 2012 12:58 UTC (Thu)
by simonkelley (guest, #17525)
[Link]
Posted Feb 2, 2012 10:50 UTC (Thu)
by paulj (subscriber, #341)
[Link]
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.
Posted Feb 1, 2012 0:41 UTC (Wed)
by Trelane (subscriber, #56877)
[Link]
The allegations are there, but not the exhibits. Where is the original text that requested the alleged veto?
Posted Feb 1, 2012 13:34 UTC (Wed)
by k3ninho (subscriber, #50375)
[Link]
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.
Posted Jan 31, 2012 19:03 UTC (Tue)
by tbird20d (subscriber, #1901)
[Link] (4 responses)
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.
Posted Jan 31, 2012 20:38 UTC (Tue)
by landley (guest, #6789)
[Link] (3 responses)
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?
Posted Jan 31, 2012 20:58 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Jan 31, 2012 23:18 UTC (Tue)
by landley (guest, #6789)
[Link] (1 responses)
Posted Jan 31, 2012 23:47 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link]
Clarification on a few points
Clarification on a few points
Clarification on a few points
Clarification on a few points
Clarification on a few points
Clarification on a few points
Clarification on a few points
Clarification on a few points
Clarification on a few points
Clarification on a few points
Wol
Clarification on a few points
Wol
Clarification on a few points
GPL in Android userspace
Google's already excluding all GPL code from userspace,
Clarification on a few points
Clarification on a few points
Clarification on a few points
K3n.
Clarification on a few points
Clarification on a few points
Clarification on a few points
Clarification on a few points
Clarification on a few points