A tempest in a toybox
One could imagine a number of reasons for wanting to rewrite Busybox. Over time, that package has grown to the point that it's not quite the minimal-footprint tool kit that it once was. Android-based systems can certainly benefit from the addition of Busybox, but the Android world tends to be allergic to GPL-licensed software; a non-GPL Busybox might even find a place in the standard Android distribution. But the project page makes another reason abundantly clear:
What seems to be happening in particular is that the primary Busybox litigant - the Software Freedom Conservancy (SFC) - has taken the termination language in GPLv2 to mean that somebody who fails to comply with the license loses all rights to the relevant software, even after they fix their compliance problems. (See Android and the GPLv2 death penalty for more information on this interpretation of the license, which is not universally held). Under this interpretation, they are withholding the restoration of a license to use and distribute Busybox based on conditions that are not directly related to Busybox; among other things, they require compliance for all other free software products shipped by that company, including the Linux kernel.
Thus, according to Matthew Garrett:
There is some truth to the notion that, on its own, license enforcement for Busybox is not hugely interesting. Encouraging compliance with the GPL is a good thing, but, beyond that, there is little to be gained by prying the source for a Busybox distribution from a vendor's hands. There just isn't anything interesting being added to Busybox by those vendors. Rob Landley, who was once one of the Software Freedom Law Center's plaintiffs (before the enforcement work moved to the Software Freedom Conservancy) once wrote:
Rob has been working on the Toybox project, which happens to be the effort that would someday like to replace Busybox, since 2006.
So, beyond the generation of bad publicity for a violator and some cash for the litigants, Busybox enforcement on its own could perhaps be said to achieve relatively little for the community. But a vendor that can't be bothered to provide a tarball for an unmodified Busybox distribution is highly unlikely to have its act together with regard to other projects, starting with the kernel. And that vendor's kernel code can often be the key to understanding their hardware and supporting it in free software. So it is not surprising that a group engaging in GPL enforcement would insist on the release of the kernel source as well.
On its face, it does seem surprising that vendors would object to this requirement - unless they overtly wish to get away with GPL infringement. Tim Bird, who is promoting the Busybox replacement project, has stated that this is not the case. Instead, Tim says:
Mistakes do happen. Companies are often surprisingly unaware of where their code comes from or what version they may have shipped in a given product. Often, the initial violation comes from upstream suppliers, with the final vendor being entirely unaware that they are shipping GPL-licensed software at all. What is being claimed here is that SFC's demands are causing the consequences of any such mistakes to be more than companies are willing to risk.
What does the SFC require of infringers? The SFC demands, naturally enough, that the requirements of the GPL be met for the version of Busybox shipped by an infringer. There are also demands for an unknown amount of financial compensation, both to the SFC (The SFC's FY2010 IRS filings show just over $200,000 in revenue from legal settlements) and to the Busybox developer (Erik Andersen) that the SFC is representing. Then there are the demands for compliance for all other GPL-licensed products shipped by the vendor, demands that, it is alleged, extend to the source for binary-only kernel modules. The SFC also evidently demands that future products be submitted to them for a compliance audit before being shipped to customers.
Such demands may well be appropriate for habitual GPL infringers; they are, arguably, a heavy penalty for a mistake. Whether the cases filed by the SFC relate to habitual behavior or mistakes is not necessarily clear; there have been plenty of allegations either way. One person's mistake is another person's intentional abuse.
If Busybox is, for whatever reason, especially mistake-prone, then replacing it with a mistake-proof, BSD-licensed version might make sense. Not using the software at all is certainly a way to avoid infringing its license. What is a bit more surprising is that some developers are lamenting the potential loss of Busybox as a lever for the enforcement of conditions on the use of the kernel. There are a couple of concerns here:
- The use of the GPL death penalty is worrisome, in that it gives
any copyright holder extreme power over anybody who can be said to
have infringed the license in any trivial way. Even if one is fully
in agreement with the SFC's use of the termination clause, there are,
beyond doubt, entities out there who would like to use it in ways that
are not in the interests of the free software community.
- One could argue that enforcement of the licenses for other software packages should be left up to the developers who wrote that code. They may have different ideas about how it should be done or even what compliance means. Any developer with copyrights in the kernel (or any other product) is entirely capable of going to the SFC if they want SFC-style enforcement of their rights.
For such a developer to go to the SFC is exactly what Matthew is asking for in his post. Thus far, despite a search for plaintiffs on the SFC's part, that has not happened. Why that might be is not entirely clear. Perhaps kernel developers are not comfortable with how the SFC goes about its business, or perhaps it's something else. It's worth noting that most kernel developers are employed by companies these days, with the result that much of their output is owned by their employers. For whatever reason, companies have shown remarkably little taste for GPL enforcement in any form, so a lot of kernel code is not available to be put into play in an enforcement action.
That last point is, arguably, a real flaw in the corporate-sponsored free software development model - at least, if the viability of copyleft licenses matters. The GPL, like almost any set of rules, will require occasional enforcement if its rules are to be respected; if corporations own the bulk of the code, and they are unwilling to be part of that enforcement effort, respect for the GPL will decrease. One could argue that scenario is exactly what is playing out now; one could also argue that it is causing Busybox, by virtue of being the only project for which active enforcement is happening, to be unfairly highlighted as the bad guy. If GPL enforcement were spread across a broader range of projects, it would be harder for companies to route around - unless, as some fear, that enforcement would drive companies away from GPL-licensed software altogether.
Situations like this one show that there is an increasing amount of
frustration building in our community. Some vendors and some developers
are clearly unhappy with how some license enforcement is being done, and
they are taking action in response. But there is also a lot of anger over
the blatant disregard for the requirements of the GPL at many companies;
that, too, is inspiring people to act. There are a number of undesirable
worst-case outcomes that could result. On one side, GPL infringement could
reach a point where projects like the kernel are, for all practical effect,
BSD-licensed. Or GPL enforcement could become so oppressive that vendors
flee to code that is truly BSD licensed. Avoiding these outcomes will
almost certainly require finding a way to enforce our licenses that most of
us can agree with.
Posted Feb 1, 2012 17:05 UTC (Wed)
by Uraeus (guest, #33755)
[Link] (6 responses)
Posted Feb 1, 2012 18:33 UTC (Wed)
by dlang (guest, #313)
[Link] (5 responses)
they've been enforcing the GPL (including court cases) on the linux kernel for a long time.
Posted Feb 2, 2012 1:20 UTC (Thu)
by rahvin (guest, #16953)
[Link]
Posted Feb 2, 2012 1:59 UTC (Thu)
by rickmoen (subscriber, #6943)
[Link] (3 responses)
Rick Moen
Posted Feb 2, 2012 22:51 UTC (Thu)
by armijn (subscriber, #3653)
[Link]
Posted Feb 9, 2012 13:41 UTC (Thu)
by landley (guest, #6789)
[Link] (1 responses)
I offloaded BusyBox license enforcement onto a third party because Erik Andersen's old "hall of shame" was simultaneously useless and too much work, but the real action on enforcement happened _after_ I left BusyBox. Erik is the one still doing it, and he hasn't been involved with BusyBox since 2005.
Harald didn't have time to code while he was doing license enforcement, and stopped doing license enforcement again when he got busy coding.
As far as I can tell, the kernel guys can't be bothered beyond the occasional gripe in conference slides and mailing lists that binary only modules aren't kosher unless you actually ported a driver initially writen for another OS).
And of course The Failure of Open Source (http://lwn.net/Articles/475742) is all about license advocacy, and as far as I can tell the last new code he wrote is almost old enough to vote.
The people who write code can write _more_ code. We've reverse engineered everything from 3D video drivers to forcedeth:
http://lwn.net/Articles/191900/
(Neither reverse engineering nor license enforcement is fun, but which of the two is a programmer likely to be more comfortable with and better at?)
The real threat to Linux's continued viability has always been loss of interest in Linus's tree (and thus fragmentation), in 2002 because Linus couldn't keep up with patches before he started using Bitkeeper, and more recently because more people used Android and we weren't merging the patches they published so vanilla wasn't interesting to the Android guys. But in both of those cases the patches/trees in question were public (binary-only isn't _interesting_ anymore).
http://linuxmafia.com/faq/Licensing_and_Law/forking.html
The open source community has put serious effort into keeping _itself_ together (around Linus and kernel.org) using social and technical methods, not legal ones.
One of my original motivations for doing license enforcement was that people who tried their OWN license enforcement (like Glenn McGrath on BusyBox) tended to burn out so badly they stopped coding:
http://www.mail-archive.com/gnu-misc-discuss@gnu.org/msg0...
I wanted to make it so they didn't have to, so we wouldn't loose good developers to the legal system anymore.
But I ran the experiment, and learned from it, and that's why I _stopped_doing_it_. I no longer think the problem is _insufficient_ license enforcement, I think the problem is just license enforcement.
I think getting the legal system all over code is bad for the code, and there's no real _difference_ between MPAA/RIAA/SOPA, decss and DVDCCA, crypto export regulations, software patents, or the FSF/SFLC/GPLv3. It's all corrosive to doing the engineering parts right. GPLv2 works great as a social contract and statement of values, but bringing the legal system into my development cycle does not end well.
Rob
Posted Feb 9, 2012 17:12 UTC (Thu)
by khim (subscriber, #9252)
[Link]
There are large practical difference: MPAA/RIAA/SOPA/etc try to make devices closed, FSF/SFLC/GPLv3/etc try to keep them open. In a world without MPAA/RIAA/SOPA/etc the efforts of FSF/SFLC/GPLv3/etc will be useless and pointless. Sadly we don't live in such a world, we live in a world where MPAA/RIAA/etc is reality and every small victory (like SOPA death) is immediately replaced with something else (like ACTA). In this world efforts of FSF/SFLC/GPLv3/etc are important.
Posted Feb 1, 2012 17:11 UTC (Wed)
by pizza (subscriber, #46)
[Link] (45 responses)
So if you violate the GPL, your product is already facing death row. The SFC's demands on top of that are several orders of mangitude less onerous than the law says they can ask for.
Even when taken to a more reasonable $2K per copy (as some of the end-user music piracy lawsuits have resulted in), that's still a penalty an order of magnitude larger than the probable retail value of the widget.
Anyway.
I used to work for an outfit that provided software ("BSPs") for access points and other wifi-enabled widgets. we delivered everything in source form, and the build system included a 'gplpackage' target that neatly packaged up every GPL component into a tarball, alongside the binary images. It's really not that hard to do, but one has to make that step a part of the release process.
Posted Feb 1, 2012 17:17 UTC (Wed)
by hummassa (guest, #307)
[Link] (7 responses)
It's not only "not hard", if you think about it (you ought to have a release process in place, no?) it's just plainly trivial to do so.
Posted Feb 1, 2012 17:24 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
But the GPL trumps that hierarchy and short-circuits things -- the parent company (whose name is on the box and who the end-user has a relationship with) is the one ultimately responsible for adhering to the GPL, and can't legally pass the buck by saying "we didn't get the source from our suppliers".
Posted Feb 2, 2012 1:25 UTC (Thu)
by rahvin (guest, #16953)
[Link] (1 responses)
From the courts point of view the infringer is the one distributing it, if you got the code from a third party your only recourse is to sue the supplier for the damages and costs associated with curing the copyright infringement.
Posted Feb 2, 2012 9:19 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Imagine you get ill from eating some prepared food. Then the retailer claims its not its fault because the poor thing bought rotten eggs and did not notice. Would you accept that as an excuse?
Posted Feb 1, 2012 22:22 UTC (Wed)
by khim (subscriber, #9252)
[Link] (3 responses)
Release process usually just pull some data from repository and builds everything. If developers committed stuff to the repository without due diligence then it may be non-trivial. Actually it's usually non-trivial in the interesting case (where source was modified). The fact that you can obtain yet another copy of the busybox tarball is not all that interesting, people want modified copies (if something was changed at all) - this case tends to be exactly the case where it's hard to separate GPL code from non-GPL code.
Posted Feb 2, 2012 7:42 UTC (Thu)
by hummassa (guest, #307)
[Link] (2 responses)
This just does not happen... or should not happen. In any case, if people commit *proprietary* stuff to the repository without due dilligence, the stakes are really higher.
> people want modified copies (if something was changed at all) - this case tends to be exactly the case where it's hard to separate GPL code from non-GPL code.
Not really. Abtraction, filtration, comparison -- is it a derivative work? If so, the "modified code" must also be GPLd, mark it as necessary in the "make gpl compliance tarball for upload" Makefile and be happy forever. Again, everyone should just act -- in the prep of a software-including product -- just as they would if free-licensed software pieces were proprietary-licensed software pieces: with due dilligence.
Posted Feb 2, 2012 14:07 UTC (Thu)
by NAR (subscriber, #1313)
[Link]
Moreover, projects can be transferred inside a multinational country between developer teams, countries or even continents, so it's perfectly plausible that a developer can be genuinely surprised if someone tells him that his product contains unlicensed binaries.
Posted Feb 2, 2012 14:37 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Absolutely not. In fact this is standard industry practice™: You commit everything to repository - SDKs, all the tools, compilers, etc. Everything. This may be formal violation of the license for some tools, but even this is not enforceable in most jurisdictions (if you have enough licenses to cover all the developers then you can just say you use repository for backup purposes). As long you don't distribute content of your repo everything is fine. But if you want to publish GPLed part then you need to separate the wheat from the lentil! It's much harder with free software. With proprietary software you usually don't have sources to modify, thus chance of mistakes is small. In some rare cases you do - but even then you mostly use vendor-supplied binaries and use sources only as reference. With free software not only you have sources - you often need to modify them slightly to make them usable (compileable, for example)! This raises risk of accidental violation hundredfold (if not thousandfold). I can't in good conscience call the process which requires strict rules and serious effort "trivial", sorry. It's not that hard (some proprietary tools require significantly more work if you want to stay compliant), but it's not "trivial" either.
Posted Feb 1, 2012 18:04 UTC (Wed)
by armijn (subscriber, #3653)
[Link] (26 responses)
I have talked to various lawyers in the free software world about this (under Chatham House Rules, so I can't explicitely name them), but all of them have frowned upon this, or dismissed it outright.
Before this turns into another flamefest about whether or not it is immoral or not for companies to violate the GPL, this is *the* core question: can you demand things outside of your own direct copyright?
Perhaps the editor could poll some lawyers about this subject, and get permission to quote them? It would be very helpful.
Posted Feb 1, 2012 18:09 UTC (Wed)
by corbet (editor, #1)
[Link] (4 responses)
Posted Feb 1, 2012 22:21 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
Posted Feb 2, 2012 12:52 UTC (Thu)
by ortalo (guest, #4654)
[Link]
Posted Feb 2, 2012 14:38 UTC (Thu)
by dwmw2 (subscriber, #2063)
[Link] (1 responses)
When the module thing comes to court, as I'm sure it will, you'll find that there are "high-clue" lawyers on both sides.
In cases like this, lawyers don't tell you what the law is; a judge does.
Posted Feb 3, 2012 10:32 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Posted Feb 1, 2012 18:11 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (7 responses)
Posted Feb 1, 2012 18:24 UTC (Wed)
by armijn (subscriber, #3653)
[Link] (6 responses)
I talked to several companies and lawyers and the pretty harsh terms (veto, review, binary kernel modules) are only pretty recent (Best Buy case, end of 2009). Before that it was indeed just as Bruce said: "not that bad" and reasonable terms.
Every company so far that has settled in the Best Buy case has settled under undisclosed terms but there is no *actual* judgement.
Perhaps the end result is indeed the same and companies said they would disclose source code, plus agree to something else (perhaps money, perhaps something else, but since those terms are not disclosed we don't know), just to get the lawsuits of their backs. But that still does not answer the core question whether or not it is actually legal to do so, which is what I am most interested in.
So far I have not heard a single lawyer (except from the ones from SFC) speak in support of the demands of SFC.
Posted Feb 1, 2012 18:36 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Feb 2, 2012 2:56 UTC (Thu)
by rahvin (guest, #16953)
[Link]
IANAL, but there is nothing illegal about what SFC is doing. They can only make these claims and requests because the companies in question open the door by infringing the GPL.
I'd also like to point something else out which unfortunately wasn't in the article. It should go without saying that if a Kernel developer steps forward to work with SFC as the plaintiff they will be the one in the driver seat and if they disagree with certain actions SFC is taking they would be in a position to stop that and prevent SFC from doing whatever it is that the developer disagreed with. The only thing SFC could do would be to refuse to work for the plaintiff.
If you don't like how SFC is engaging in these actions and the terms and conditions they demand for closure the best way to stop them is to become their plaintiff and work with them.
Posted Feb 2, 2012 14:32 UTC (Thu)
by dwmw2 (subscriber, #2063)
[Link]
Some people grant a licence in return for money; some grant a licence in return for postcards. There's absolutely no reason that they can't grant a licence on the condition that the licensee complies with the licence of the *other* software they use. Or stops beating their wife. Or stands on their head and asks nicely.
I believe that the standing on the head example was actually made by a judge in a recent ruling.
Posted Feb 1, 2012 19:44 UTC (Wed)
by jku (subscriber, #42379)
[Link]
Posted Feb 2, 2012 2:07 UTC (Thu)
by Trelane (subscriber, #56877)
[Link]
Aside from the obvious issue of the SFC not auditing you until you've allegedly violated the terms once.
Posted Feb 11, 2012 12:21 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Once the SFLC has got hold of someone who (a) has the clout to fix things, and (b) has the determination to fix things, it's pretty easy to come to an amicable solution.
The problem with Best Buy, as far as I can make out, was the only response the SFLC got was "not our problem". To the point they were finally exasperated enough to say "well it is your problem and we're going to court to make you face up to it!"
I don't know whether you have the same thing in America, but over here we have a position called "Company Secretary", of which most companies *M*U*S*T* legally have one. And one of the "perks" of the post is that if the company breaks the law, the Secretary is - *PERSONALLY* - legally liable and can be fined or imprisoned.
So over here, the equivalent of the SFLC could go to Companies House (the relevant public records office), find out who the Secretary is, and send them a registered letter. At which point he is personally on notice that he could end up in jail. He now has two choices. Pass the buck to the rest of the board, placing them on notice of jail terms, or resign. What do you think it's going to do to confidence in the Company if the Secretary resigns, giving as his reason that he doesn't want to go to jail?
Cheers,
Posted Feb 1, 2012 18:41 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
If it came down to the technicality of it then probably no, the case would be thrown out (see RightHaven) but why wouldn't you ask for and help implement a comprehensive compliance program rather than playing monkey hear-no-evil, see-no-evil, speak-no-evil? Compliance is the ultimate goal, not punishment. Unless you think being forced to comply with the licenses of the software you ship is "punishment".
Posted Feb 1, 2012 18:53 UTC (Wed)
by mjw (subscriber, #16740)
[Link]
Posted Feb 1, 2012 19:04 UTC (Wed)
by Otus (subscriber, #67685)
[Link] (2 responses)
Correct me if I'm wrong, but isn't the SFC doing this via settlements? I though settlements allow the two parties to decide on whatever terms both accept, with basically no legal limits.
If the sued companies don't see the terms as acceptable they can continue the court case, where the SFC would presumably ask for a payment or whatever the law allows them to ask for.
Posted Feb 2, 2012 3:06 UTC (Thu)
by rahvin (guest, #16953)
[Link]
Considering juries have been handing max statutory damages to poor single mothers who downloaded music off the internet (Jamie Thomas in her first trial for 21 songs was ordered to pay more than $1.5 million dollars) I think it's fairly probable that if a corporation was foolish enough to take this to the Jury they would end up with the max statutory damages the law allows but in reality the Jury can award damages anywhere between $0 and the max the law allows per infringement.
Posted Feb 5, 2012 20:42 UTC (Sun)
by dwmw2 (subscriber, #2063)
[Link]
I find it particularly strange given that the type of settlements they're talking about bear so little relation to the things that the SFC say they do ask for (see here).
If the likes of Sony really want to reduce their risk, perhaps they should lobby the government to reduce the statutory damages for copyright infringement?
Posted Feb 1, 2012 21:43 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (6 responses)
Oh, sure you can. If you don't agree, take it to court. The fact that noone has dared to, speaks volumes about the legitimacy of the request.
Posted Feb 2, 2012 2:12 UTC (Thu)
by Trelane (subscriber, #56877)
[Link] (3 responses)
Posted Feb 2, 2012 2:16 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Feb 2, 2012 2:51 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Feb 2, 2012 3:09 UTC (Thu)
by rahvin (guest, #16953)
[Link]
Posted Feb 11, 2012 12:27 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
So what they are demanding is "give us all the source we are legally entitled to".
Where it becomes a problem, and where Sony :-( has a problem with it, is they are also asking for the source for other products they may not have bought (that may well not even be on sale!).
Cheers,
Posted Feb 11, 2012 18:18 UTC (Sat)
by corbet (editor, #1)
[Link]
If somebody is shipping Busybox (or another GPL-licensed program), and they did not ship the source along with a binary distribution, then any third party is entitled to ask for the source. Having bought the box (or not) does not play into the picture in any way.
That said, third parties have no standing to legally enforce that requirement. Only the copyright holders can do that. The SFC, by virtue of representing copyright holders (and, possibly, being a copyright holder itself), has the standing to initiate this sort of action.
Posted Feb 9, 2012 8:06 UTC (Thu)
by kevinm (guest, #69913)
[Link]
Posted Feb 1, 2012 20:07 UTC (Wed)
by kripkenstein (guest, #43281)
[Link] (9 responses)
This is a valid point.
However, that copyright law is insane doesn't excuse us in the FOSS community doing anything insane as well (even if it is much less insane).
It is *very* hard to convince corporations to use FOSS if the risk is that a single mistake by one of their teams means that the entire company can no longer use that specific FOSS until the copyright owner agrees for them to. The main problem is uncertainty: The corporation does not know ahead of time exactly what the copyright owner will demand. At least with a proprietary license, you know ahead of times the costs involved in a clear (well, clear-er) manner.
If I had believed the GPL did actually assume such a "death penalty" event - I prefer to call it a "hostage situation" - I would never have released the GPL code I did (I would have used another FOSS license). It strikes me as counter to the intent of the GPL, and very dangerous to the FOSS community as I said above.
It is more than sufficient to protect GPL code to interpret it in the more reasonable way, which is that distributing GPL code grants a new license each time. So that you have a license if you comply with the GPL. If you don't comply, you lose that license until you download a new copy, and are in compliance with that license. In this situation, violating the GPL is still very bad - you cannot use the code any more - but at least you know ahead of time exactly what you need to do to be able to use it again - come into compliance.
That the SFC does basically that - but for all FOSS projects the company uses, not the one whose license they violated - is not as bad as things *could* be, because in theory the license enforcer could ask for anything at all (hence I prefer the term "hostage situation"). But again, the problem is that corporations don't know for sure in advance what the SFC will require, if one of their teams makes a mistake and doesn't fully comply with the license of one of the FOSS projects they use. This is one of the biggest problems for FOSS adoption today.
Posted Feb 1, 2012 20:23 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
I'm not sure that it's been tested in court but that seems like a reasonable interpretation, you don't have the right to distribute at all if you are not compliant and every compliant distribution doesn't require individual authorization by the copyright owner.
> corporations don't know for sure in advance what the SFC will require
That doesn't really seem to be true, the SFC has stated many times that all they require is that general compliance efforts be undertaken and that their expenses be paid.
> The main problem is uncertainty
If that were the main problem then no one would every go into business, businesses deal with uncertainty and risk all day long. Unless you think there should be some government-mandated certainty of risk, certainty of profits, etc. there is going to be some amount of risk and uncertainty in business.
Posted Feb 1, 2012 20:27 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (4 responses)
Posted Feb 2, 2012 4:18 UTC (Thu)
by kripkenstein (guest, #43281)
[Link] (1 responses)
Posted Feb 2, 2012 14:05 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
"GPLv2 provided for automatic termination of the rights of a person who copied, modified, sublicensed, or distributed a work in violation of the license. Automatic termination can be too harsh for those who have committed an inadvertent violation, particularly in cases involving distribution of large collections of software having numerous copyright holders. A violator who resumes compliance with GPLv2 would need to obtain forgiveness from all copyright holders, but even to contact them all might be impossible"
GPLv3 doesn't clarify the termination clause. It materially changes it.
Posted Feb 2, 2012 4:19 UTC (Thu)
by rahvin (guest, #16953)
[Link] (1 responses)
In theory the author could mean something completely different than both the parties to the contract meant and it wouldn't be the authors interpretation that mattered. The caveat here is that if the two parties to the contract had different intentions, then the Judge is tasked with finding a middle ground and could in theory use the contract authors intentions to reach that point even if it was diametrically opposed to the intentions of both parties. But I don't think it's very common that a contract exists where the two parties to the contract have opposite interpretations to what the contact meant AND the author had a third interpretation that was different to both parties intentions. That would be some brutally awful contract language to reach that point.
Posted Feb 2, 2012 4:46 UTC (Thu)
by ncm (guest, #165)
[Link]
Posted Feb 2, 2012 2:30 UTC (Thu)
by faramir (subscriber, #2327)
[Link] (2 responses)
Now it may be the case that companies violate the GPL license more often then they do proprietary licenses. Or maybe they just get caught more often. I really couldn't say, but I don't see how that matters.
Posted Feb 4, 2012 19:43 UTC (Sat)
by krake (guest, #55996)
[Link]
It seems kripkenstein has reason to believe that proprietary licenses come with details on how one would get a new license if one loses the current one due to violating its terms.
Sounds weird to me as well but that's what their posting says.
Posted Feb 9, 2012 20:03 UTC (Thu)
by landley (guest, #6789)
[Link]
Well, it's a _touch_ harder to invoke First Sale Doctrine. :)
Rob
Posted Feb 1, 2012 18:02 UTC (Wed)
by deater (subscriber, #11746)
[Link] (15 responses)
I wonder what the reactions would be if some $BIGCOMPANY made demands that other companies found infringing its product $X had to stop using all open-source software and submit all future products to be audited for compliance.
I have written a lot of GPLv2 code over the years, but this whole situation has seriously made me reconsider my license choices.
Posted Feb 1, 2012 20:09 UTC (Wed)
by ovitters (guest, #27950)
[Link] (1 responses)
Posted Feb 9, 2012 20:15 UTC (Thu)
by landley (guest, #6789)
[Link]
http://landley.net/notes-2006.html#18-09-2006
If it was started by the guy who set off the busybox license enforcement actions in the first place? March 27, 2006 entry from here:
http://busybox.net/oldnews.html
If the project was GPLv2 for the first few years and switched for reasons again publicly explained?
http://landley.net/notes-2011.html#13-11-2011
By the way, your position says that making FreeDOS or ReactOS are evil acts.
Posted Feb 1, 2012 23:56 UTC (Wed)
by geertj (subscriber, #4116)
[Link] (4 responses)
Posted Feb 2, 2012 13:06 UTC (Thu)
by robert_s (subscriber, #42402)
[Link] (3 responses)
Posted Feb 2, 2012 15:38 UTC (Thu)
by deater (subscriber, #11746)
[Link] (1 responses)
If GPL software is being shipped without source, I want that fixed.
I don't think the fix should involve all kinds of crazy strings attached.
Yes, it would be nice if the kernel GPL violations are fixed too. That's really unrelated to the busybox GPL enforcement. I mean, it would be nice if the infringing company would give all Linux developers candy and ponies too, but it seems like a silly demand to make.
If the Linux kernel developers want to enforce their GPL, let them. I don't see why it's the busybox lawyer's business at all though.
I'm saying this as someone who has a (very small) amount of GPL'd code in the linux-kernel tree.
Posted Feb 3, 2012 11:24 UTC (Fri)
by dwmw2 (subscriber, #2063)
[Link]
When they contact a router manufacturer who is shipping a Linux-based device without any source code at all, and they come to an out-of-court settlement… you'd rather they only made sure the offending company publishes their Busybox source code, and nothing else?
You don't want them asking the company to comply with the law for all software they use in that specific product?
For my part, I disagree strongly with you. I am grateful that they have been asking these companies to stop violating my copyright too.
I just don't understand your point of view at all. See the example I gave elsewhere about beating my children.
Posted Feb 9, 2012 20:19 UTC (Thu)
by landley (guest, #6789)
[Link]
http://landley.net/notes-2006.html#03-12-2006
The FSF couldn't make me write GPLv3 code, but they _could_ make me stop writing GPLv2 code. And I'm not alone:
http://developers.slashdot.org/story/11/12/17/1735253/gpl...
Posted Feb 2, 2012 0:32 UTC (Thu)
by mitchskin (guest, #32405)
[Link] (3 responses)
It's just that *if* you agree with the GPL enforcement work, then we should work together to find ways to continue it even if there's a permissive replacement for busybox. It's not an attempt to control projects or licenses, it's an attempt to coordinate with other like-minded people.
Posted Feb 2, 2012 15:48 UTC (Thu)
by deater (subscriber, #11746)
[Link] (2 responses)
Sure they are, I'm pretty sure that's Garrett's whole point.
Posted Feb 2, 2012 16:40 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Feb 9, 2012 20:50 UTC (Thu)
by landley (guest, #6789)
[Link]
So thanks for the signal boost. If you really want to personally pick up the sisyphos role of scaring developers away from open source via the legal system, good luck with it. Android's already written GPL off but I'm sure you can squeeze more out. I found it's easy to find lawyers happy to take companies' money, and really hard to get useful code out of the process. (Way, way, way more time and work than just writing it yourself.)
It's pretty easy to go after small fry and declare them "no longer in violation" after they go out of business or give your lawyers a lot of money and a random useless tarball of stuff you've already got to become technically compliant without ever actually producing any useful code because there _wasn't_ any. And you can draw it out _forever_ by suing "Board Support Package" customers, but not the BSP vendors who added the new drivers and never gave their customers complete source in the first place, and rack up an endless string of meaningless "victories" that way.
Personally? Been there. Done that. It gets old.
Rob
(I asked the SFLC why they sued Cisco instead of Broadcom, since they were complaining about a Broadcom BSP toolchain Cisco never _had_ the source code to. I never did get a clear answer to that one. I believe they said the FSF was the plaintiff not the busybox developers, so they couldn't discuss details of the case with me, or something like that.)
Posted Feb 2, 2012 3:17 UTC (Thu)
by rahvin (guest, #16953)
[Link] (3 responses)
Posted Feb 2, 2012 10:06 UTC (Thu)
by Trelane (subscriber, #56877)
[Link] (2 responses)
Posted Feb 2, 2012 11:34 UTC (Thu)
by tterribe (guest, #66972)
[Link] (1 responses)
Posted Feb 3, 2012 1:10 UTC (Fri)
by Trelane (subscriber, #56877)
[Link]
Posted Feb 1, 2012 18:48 UTC (Wed)
by jra (subscriber, #55261)
[Link] (3 responses)
http://sfconservancy.org/blog/2012/feb/01/gpl-enforcement/
From the horse's mouth, as it were :-).
Posted Feb 1, 2012 19:15 UTC (Wed)
by jra (subscriber, #55261)
[Link] (2 responses)
Jeremy.
Posted Feb 2, 2012 3:24 UTC (Thu)
by rahvin (guest, #16953)
[Link] (1 responses)
Posted Feb 9, 2012 20:52 UTC (Thu)
by landley (guest, #6789)
[Link]
Got it.
Posted Feb 1, 2012 19:03 UTC (Wed)
by tbird20d (subscriber, #1901)
[Link] (120 responses)
People have said that the cost of compliance is small. This is true, but it can be difficult to enforce across a large organization, especially with lots of sub-contractors and suppliers.
Imagine if you were mayor of a town of 300,000 people, and you had to pay a million dollar fine if someone was caught stealing. You have implemented a set of policies to prevent stealing, and to encourage people not to steal. Could you guarantee that no one ever stole? As mayor, would you pay $1,000 for an insurance policy against the fine? That's similar to the cost/benefit calculus for this project, for large enterprises. It's not that executives are unwilling to enforce compliance, or are actively undermining the license of the code their company ships. They just want to reduce risk.
Some people have said that what the SFC requests in remedies is not that costly, but I can assure you that large corporations see it very differently. Matthew, in particular, keeps asserting that the real reason for this project is "to make it easier to infringe the kernel's license." This is simply not true.
For a large company that is compliant with the GPL, the biggest worry is that a 3rd party (and a legally hostile one at that) would be given the right to review (and therefore delay) the shipment of its products. Bruce Perens said that the SFC requirement to audit the software for all GPL-based products was a "reasonable request". It certainly sounds like an appropriate thing to do for a repeat offender. But in terms of perceived cost, for Sony this would delay, and worse, add uncertainty to the release dates of hundreds of products each year. Time to market is an exceedingly big deal in consumer electronics. Products have lived or died by hitting or missing their launch windows. Marketing budgets are in the millions of dollars, with product releases designed to coincide with the holidays, or other specific events. The paltry figure of $5000 per audit seems small, but when multiplied by hundreds of products adds up to well over half a million a year in potential costs. But even worse is the time uncertainty that such an audit adds to the release cycle.
It is a shame that a few non-compliers have poisoned the well for those who take their GPL compliance seriously. I think that the SFC is over-reaching, and I'm sorry to say that I believe they will continue to over-reach. Given the scope of the remedies requested by the SFC, I believe eliminating the possibility of a license violation is a valid, although not ideal, solution.
Posted Feb 1, 2012 19:22 UTC (Wed)
by cmorgan (guest, #71980)
[Link] (1 responses)
Most companies take care to have an appropriate number of licenses for their software. They should do the same if its my software or big company X's software and I'm glad to see people like the SFC sticking up for the little guy.
Posted Feb 1, 2012 20:09 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Posted Feb 1, 2012 20:12 UTC (Wed)
by ovitters (guest, #27950)
[Link]
The legal bits are important; you cannot just ignore it, then complain that SFC is somehow bad. It started with ignoring copyright and the license of the code. I thought there was some kind of thing where people are assumed to know the law. Meaning: ignorance is no excuse.
Posted Feb 1, 2012 21:39 UTC (Wed)
by jimparis (guest, #38647)
[Link] (33 responses)
Posted Feb 1, 2012 21:49 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
I think the disagreement is that tbird doesn't believe you when you say that the SFC will operate in good faith
https://lwn.net/Articles/478770/
Without making a judgement about the merits I'm not sure this is a reconcilable difference of opinion.
Posted Feb 1, 2012 23:39 UTC (Wed)
by tbird20d (subscriber, #1901)
[Link] (31 responses)
The site address is: http://www.sony.net/Products/Linux/common/search.html
So say you.
Posted Feb 2, 2012 0:30 UTC (Thu)
by jubal (subscriber, #67202)
[Link]
Posted Feb 2, 2012 0:38 UTC (Thu)
by mitchskin (guest, #32405)
[Link]
I haven't seen you give a specific example that contradicts what he said.
Posted Feb 2, 2012 3:33 UTC (Thu)
by rahvin (guest, #16953)
[Link] (28 responses)
Nothing like publicly calling someone a liar.
Posted Feb 2, 2012 4:24 UTC (Thu)
by tbird20d (subscriber, #1901)
[Link] (27 responses)
That was not my intent, and I apologize if it came out that way. I intended to convey that I don't think this is guaranteed to be the case, and that I doubt the author can certify this assertion. What the author states is certainly what the SFC reports.
I have no reason to believe that the author (jimparis) does not believe the assertion.
Posted Feb 2, 2012 7:47 UTC (Thu)
by ekj (guest, #1524)
[Link] (26 responses)
But it's not been the trend. I don't think I recall even a single case where a company has openly admitted to their mistake, *responded* and made a good-faith effort to rectify the problem, yet nevertheless ended up in court.
Yes, in principle it could happen. In practice, it does not seem likely.
Posted Feb 2, 2012 10:03 UTC (Thu)
by khim (subscriber, #9252)
[Link] (25 responses)
It all depends on the definition of "good faith". The whole tempest started boiling when FSF sued CISCO. And as Rob Landley claimed it happened while CISCO was doing the honest good-faith effort to rectify the problem. It's just, you know, five years is not enough for them to get their house in order, that's all. Well, got that: if you try to reach compliance but that's hard then you can spend years and that's Ok, because it's hard, you know. Hmm... Home come Youtube was sued when it spent less then three years trying to solve similar problem? Home come Megaupload was not given five years? Somehow when copyrights of "big boys" are violated "good faith" is "you must do everything you could to stop that... pronto... today, or, better yet, yesterday". Youtube won in the end, but not because Google installed new copyright protection system, but because it already did what the law required at the beginning of the lawsuit. Even so: Google went to great lengths to make sure they do not only the bare minimum law requires, but they go above and beyond. Because, you know, they are large and powerful and so must be held to higher standards. Yet somehow CISCO, SONY and other large companies should be given years before they'll do even bare minimum? Gosh. P.S. I'm not happy to live is this super-litigious world. I'd much prefer to live without copyright at all (and yes, I know that in this case it'll be harder for me to sell my own work, too). But as long as large companies continue to raise stakes WRT to copyright violations we have no recourse but to respond. IMNSHO what SFC is doing is relatively mild response to this copyright escalation. The whole "tempest" looks silly for me: it's as if Bacterian complained after the fight that Krillin should be disqualified because he used dirty tricks.
Posted Feb 9, 2012 21:26 UTC (Thu)
by landley (guest, #6789)
[Link] (24 responses)
They had just taken Linux development back in-house for new routers (like the WRT610n) that had the capability to do a lot more in software. The guys in taiwan had monkey-patched the old broadcom build system into a horrible mess, all the package versions were 5 years old, and they were creating a while new build system (code-names "Bruschetta" and "Prosciutto" for minor variants of the same thing), and the new one came with a whole open source methodology they were setting up with public websites and participation on public lists and engagement in the community and a dedicated code auditing period between GM and actual production where the developers did NOTHING but confirm source versions and license info and ship the _source_ before shipping the _product_.
And then the FSF came in sock-puppeted the SFLC to go "you know that thing you outsourced to Taiwan after the first lawsuit, and haven't touched in 5 years, which the entire new development effort is aimed at obsoleting and replacing with current vanilla versions of everything? We're suing you over it AGAIN!"
And senior management went "Open Source is Not To Be Trusted", killed off the new in-house Linux effort, and outsourced support of existing WRT610n units to... Red Hat, I think.
The toolchain the FSF was suing over was A) from 2003 or so (gcc 3.2.3, binutils 2.13.2.1, linux-2.4.20, glibc-2.2.5. In 2008), B) from broadcom (cisco never had the source), C) a generic mips toolchain for a 5 year old hardware architecture. I'm fairly certain a toolchain built from all the vanilla sources would have happily worked as a drop-in replacement, but it was so old old nobody could build it on modern distros (and linux-2.4.20 wouldn't compile with gcc 4.x):
http://landley.net/notes-2008.html#21-12-2008
But by all means, consider the FSF's actions _useful_. After all, the end result was that all the guys working on getting vanilla Linux working well on the WRT610n were transferred off of Linux development to do Windows and IOS...
By the way, the only reason I know _this_ story in such detail is I was (purely coincidentally) on the other side of it. I expect the other enforcement actions were often equally pointless and/or counter productve, I just didn't get inside details from the engineers impacted by them. I just heard from lawyers and managers, and got code drops through intermediaries (which never had anything in them we would want, but I had to trawl through anyway to confirm that it did in fact reproduce the binary and identify random source control snapshot X plus backports of these 15 random commits out of the same source control system, plus debug printfs that really shouldn't have shipped, and they hardwired in these constants instead of learning how to use the config system...) All I really know about those _other_ actions is they were a complete waste of time from the perspective of BusyBox development.
(P.S. When I told the SFLC/SFC to stop representing me, they raised the fact I was giving up settlement money to try to convince me to stay. But money was _never_ why I did it, and it's not why I stopped either. I started the busybox enforcement actions because I thought it was the right thing to do and would help BusyBox and embedded Linux development and adoption, and I stopped when I figured out it was at _best_ useless, and most likely doing real harm to the goal of getting the most people to use the best software, harming _both_ the "most" and "best" parts of that goal.)
Rob
Posted Feb 9, 2012 22:13 UTC (Thu)
by khim (subscriber, #9252)
[Link] (21 responses)
Well, if you are correct then your heart-rending story just reiforced the the ekj's point: because they still had no plans to ever produce sources for the devices they continued to ship. This is obviously unfortunate but alternative is to basically give the CISCOs of the world right to ignore license requirements for as long as they want and to only participate in the development when they want. This is basically what Apache, BSD and MIT licenses are doing. Well, who knows, may be this is indeed the best way - but then the way to do this is not to ignore GPL and pretend you can treat it like the BSD license, but to actually rewrite or relicense all the GPLed code under BSD license. Do you plan to rewrite Linux kernel you or do you plan to use *BSD kernel instead? This is honest question: inquiring minds want to know. Because the whole point of the aforementioned exercise was to show that "drag your feet, ignore old compliance issues and they will go away in time" does not work. Toybox by itself will not be sufficient to protect the companies.
Posted Feb 10, 2012 1:56 UTC (Fri)
by landley (guest, #6789)
[Link] (20 responses)
But if the linux kernel becomes the nest of lawsuits busybox has, how hard would it really be to replace?
Context: the iPhone is running a bsd derivative already, and it didn't take apple all that long to switch from MacOS 9 to MacOS X (and that was porting the whole of MacOS userspace on top of it, _and_ there was a crazy divergence onto microkernels with mach they had to back out again)? Remember how Darwin is technically OpenDarwin?
The amount of engineering effort Google's already devoted to the Android kernel would let it fork a BSD kernel (net, open, free, dragonfly, darwin, doesn't really matter which), port all their new driver stuff to it, and get it reasonably working with their userspace in about 18 months.
Keep in mind, all _they_ want to do is run dalvik. Most of the stuff that Linux _has_, from massive SMP scalability through I/O elevators to container support... isn't really used on Android phones. Heck, bionic couldn't getpwnam() anybody but root last I checked...
Intellectual exercise: what would it take to port Linux 0.0.1 to android hardware? (Linus wrote that in 3 months, as a student. And when he started he didn't know how.) Now what would it take to extend that to where it could run Dalvik, drive an LCD touchscreen, a speaker and microphone, talk to the flash hardware, and control a dozen GPIO pins for buttons and LEDs and such? (The radio's already a binary blob running on another processor. Basically we're talking "u-boot with a scheduler".) How _small_ a team could do this? How long would it take? Now, does Google have the ability to do _better_ than that? How much better?
I'd say the android guys clearly _could_ replace the Linux kernel, if pushed. I don't think they _want_ to, and I'd like to be clear that I would not consider this a good outcome. But lawsuits are a nuclear option. You rattle sabers all you want, use them for leverage and negotiation. But stabbing somebody with them is an act of war. Flinging lawsuits around on a regular basis like the SFLC is doing means you're a rogue state, and must be dealt with. It's gone beyond "counterproductive".
I did not suddenly suggest "hey, I wonder if anybody would want a BSD licensed embedded command line" to other people. Neither did Tim. "No GPL in userspace" was NOT OUR IDEA.
Lots of people approached _Tim_ in his capacity as CELF dude. (Tim runs the Consumer Electronic Linux Forum and the Embedded Linux Conference that the Linux Foundation recently consumed. That's why people come to him and go "do you know of an X, I'm looking for one".) Tim wasn't the only one sniffing around, he's just the one who was willing to go _public_ about it, and take the heat for doing so. He was _responding_ to lots of people out there.
Everybody's flipping out about toybox but totally ignorant of the other projects out there also working on this:
http://beastiebox.sourceforge.net/
And so on and so forth. Toolbox itself would be one if Google put any work into it. The demand for a non-GPL busybox is something out there that _exists_, due to the SFLC and SFC's overuse of lawsuits. It's like antibotic resistance: use your "defense" stupidly and aggressively enough for long enough and the ecosystem adapts to render it irreelvant.
If it wasn't for the GPL aspect, wouldn't the busybox lawsuit factory be lumped in with the patent trolls and the BSA? You just seem to think the goals justify the means. I don't.
Posted Feb 10, 2012 9:47 UTC (Fri)
by khim (subscriber, #9252)
[Link] (19 responses)
Yup. Measly ten years (NextStep was bought in 1996 and MacOS Classic was abandoned in 2006). They have not ported the whole of MacOS userspace. They ran old system and new system side-by-side. Similar to dosbox or KVM. Sure, they kept some APIs, but ultimately MacOS X and MacOS Classic share very little (besides the name). That's prehistory - and another ten years of development (from about 1985 to 1996). I sincerely doubt it. They will need to port all the hardware drivers first and talk with partners, etc. Realistically speaking it'll be about three-four years till the first raw port (this is how long it took to produce the first version of MacOS X: porting started in 1997, first version of MacOS X was released in 2001 - and it was poor sight, it was incomplete, buggy, etc). ...today. But with 8-cores on the horizon and other similar development it may become important before long. You'll need to find the right kind of guy, but yes, it's doable in similar time. Give or take. Of course (unlike PC) you'll need to keep porting thing to new versions of phones again and again, but that's doable. That's where it gets hairy: Android uses surprising amount of very modern features. It's not clear how fast you can implement them from scratch. It's obvious that you'll need years, but if you'll need fifteen years, five years, or three years is interesting question. Not really. They can replace it if this will be strategic goal and development will need to start well in advance (think Apple's switch to Intel), but not if pushed: even three years delay will be enough to kill the platform (ask PalmOS guys). Bullshit. Have you looked on number of Android-related lawsuits lately? How many of them lead to total abandonment of the platform and switch to something else? Actually flinging lawsuits around on a regular basis is "business as usual" in mobile space. Think Apple and Samsung: they are partners yet they sue each other anyway. These people are not developing software designed to make GPL violation painless. Toybox was in the same bucket for years, it only become controversial when Tim basically said: our subcontractors like to violate GPL and this is a problem because pesky SFC likes to enforce it - we must make sure these violations are painless for us. Note that this is from a guy who works for a company which goes to great lengths to sue people which help others violate their valuable IP (AFAIK Geohot never pirated anything SONY-related himself). Of course when faced with blatant hypocrisy (when Geohot helps other people to violate SONYs copyright then he should go to jail, but when SONY's subcontractors violate GPL then we should help them) people flipped. Perhaps. That's why I asked what you plan to do to replace Linux kernel. It looks like you have no plans in this area which makes the whole thing supremely disgusting. If you lump BSA together with trolls then you already lost the ball. These are entirely different menaces. As for SFC… yes, it's here because BSA is here, but last time I've checked BSA had no plans to disband itself any time soon.
Posted Feb 10, 2012 16:05 UTC (Fri)
by landley (guest, #6789)
[Link]
I honestly hadn't thought about it before you brought it up, but I could install one of the BSDs in QEMU and regression test under that the same way I occasionally pull out my old Red Hat 9 image and see what subset of the functionality works under that. In theory I'm programming to posix (largely because bionic is a vague port of the OpenBSD libc).
You might as well be asking how I plan to keep kosher. This is not my fight. I don't personally like pork, but I don't avoid cheeseburgers either. I can make sure to _regularly_ have milk whenever I have meat, just to make sure you lose, but my goal here is to get you to go away and stop bothering me.
So ok, Toybox should make sure at least a subset of the commands can also build and run on BSD. Right, I'll throw it on the todo heap...
Rob
Posted Feb 10, 2012 18:32 UTC (Fri)
by dlang (guest, #313)
[Link] (17 responses)
with that argument just about all opensource project are illegal.
after all, what's linux but a project to let people have a unix-like system without complying with the proprietary licenses of the commercial unix systems?
what's openoffice but a project to let people have an alternative to microsoft office without complying with the proprietary licenses that microsoft sells?
if you go hunting for it, every opensource project can be framed in a way as to be encouraging people to avoid complying with some commercial license (the free as in beer part of freedom), and this is frequently touted as a significant reason for the open software existing by the project itself (not just a third party talking about the project like in the case of toybox)
Posted Feb 10, 2012 18:50 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (6 responses)
This is clearly a nonsense interpretation of what was asserted and I'm disappointed that you'd choose to bring it up this way. The assertion was that because the software only ran on a GPLv2 system and was only useful in this context that building a system using this software for the sole purpose of not complying with the source sharing requirements of the GPLv2 was abetting software piracy even though this software itself is not GPLv2 and does not, itself, have source sharing requirements. This exactly has zero parallels with your examples.
Posted Feb 10, 2012 19:03 UTC (Fri)
by dlang (guest, #313)
[Link] (5 responses)
I think that both arguments are nonsense, but if you believe in one, the other comes along as baggage.
Posted Feb 10, 2012 19:27 UTC (Fri)
by jake (editor, #205)
[Link] (3 responses)
and who on earth has made this argument? not liking him doing so is hardly a claim that it's "illegal" ...
jake
Posted Feb 10, 2012 19:37 UTC (Fri)
by dlang (guest, #313)
[Link] (2 responses)
if you load the full series of comments and search for 'illegal' you will see it being introduced.
Posted Feb 10, 2012 20:12 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
Please try to actually do that, Ok. You'll find that the first post is mine and it clearly states I have no problems with Rob's work. Rob wrote busybox replacement to solve some problems with busybox. No problem so far. Then later Tim comes along and convinces Rob to change the license citing SFC as the reason. This is the point when the whole outrage started and at this point it stopped being about technically interesting rewrite of busybox and started being about legally questionable GPL infringement easement. Only court may say for sure if such thing is legal or not, but the very fact that it's sold under "let's make sure SFC can not sue us for the violation of GPL while we continue to use identically-licensed other pieces of code" is not just morally wrong, it's highly questionable on legal grounds, too.
Posted Feb 11, 2012 22:30 UTC (Sat)
by landley (guest, #6789)
[Link]
Except that's not what happened.
Tim was trying to start a project called "BentoBox", which most likely would extend Android's Toolbox, and if not would start over from scratch. He was doing so in his capacity as CELF guy (not a Sony guy) because a number of different manufacturers had approached _him_ looking for such a thing, and he thought that pooling their resources was better than each of them writing yet another half-assed bsd-licensed not-busybox (toolbox, bsdbox, beastiebox, sbase, who knows how many private ones behind closed doors?)
Initially, I told him I wasn't interested. And then I thought about it and went "A _billion_ android devices. They've already had five years to ship busybox and didn't. Something is going to fill that market vacuum, and when it does it will be BIG."
I also thought: I really liked working on toybox, I only stopped because I didn't think anybody would ever use the result, because no matter how technically better I make it, it would have to displace an existing "good enough" solution with a ten year headstart including years of my own work. But... market vacuum. Billions of seats. They're going to use SOMETHING...
Tim still hasn't paid me a dime, and may never do so. (I'd love it if he _did_, but that's not why I restarted Toybox.)
I am the one who chose to relicense toybox. I didn't wait for Tim to decide to redirect his bentobox thing, I didn't wait for anybody to come up with any money, or a marketing campaign, or even a promise to use it instead of going off and doing something else that would compete with it.
I decided that Toybox should be restarted as a BSD-licensed project (Tim was proposing Apache license for bentobox). It was my code, I'm the only one who _could_ relicense it, and I'm certainly the only one who could make me work on it.
I am not Tim's puppet. And I'm not your puppet either. I've been programming since I was 12, releasing the results for free since almost that long (300 baud modem to BBS's: the first program I wrote and uploaded was "The Bard's Tailor", an editor for C64 bard's tale game save files), and doing so as open source since 1998. I didn't even MEET Tim until 2006.
That's the annoying assumption here, that some large company is pulling the strings, it's a conspiracy! In reality, large companies haven't had time to REACT to any of this. Tim made a proposal Sony has yet to even _evaluate_, and he works for them! Fortune 500 corporations move very, very slowly. They haven't noticed this project EXISTS yet. I may have 1.0 out before they do.
Rob
P.S. And please: Tim citing SFC at _me_? I fell out with SFLC before SFC forked off from them, I was very public about it in my blog, and have linked those old blog entries here ad nauseam. The no GPL in userspace thing is an Android policy which my _current_ employer (Polycom, I work in board bringup which has nothing to do with any of this) has adopted itself for Android products it ships (basically all new ones). I.E. the team I personally work on at my day job does board bringup in vanilla-ish Linux (A TI fork thereof, anyway; we recently got to upgrade to 2.6.37!), and then once we've made all the hardware work the prototypes get reformatted and handed off to a completely separate set of developers who install an android kernel (again from TI) and userspace, and write a Java GUI that runs in Dalvik and gets packaged into an apk file to install into Android. Those guys can't use _any_ GPL stuff in userspace. The only reason _we_ get to is that none of the userspace code we write ever _ships_. We're mostly just figuring out which wires aren't connected up right and which existing drivers don't do what we need them to so the vendor (TI) can fix 'em.
Posted Feb 10, 2012 19:33 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
Posted Feb 10, 2012 19:49 UTC (Fri)
by khim (subscriber, #9252)
[Link] (9 responses)
… and without using any code from said unix systems. The very first goal was to make Linux self-hosted and make sure you can use it without buying license for Minix. … and without use of any proprietary code at all. Important milestone was reached when openoffice was freed from all binary blobs. Wow. That's certainly bold statement. What kind of proprietary software will you need to use Linux, OpenOffice.org, GCC or any other tool? All FOSS projects I know strive very hard to make sure they can be used without any proprietary software at all. And when they need some binary blob it's always a problem which is considered quite serious - and this is not the new phenomenon. Number of drivers are not in Linux's mainstream kernel simply because they need binary blobs with questionable licenses. Compare it with project under discussion which quite explicitly is useless without GPLed components. And when asked about replacement for the other piece of puzzle the author itself noted that he honestly hadn't thought about it before. Sorry, but I find it quite hard to believe it's the same thing when people explicitly say that they want to make sure all the licenses are followed to a T and when they say "here is pile of identically licensed code which license is often violated but where some piece is more often in spotlight, let's make sure this piece is removed but keep everything else under the very some terms". If you'll show me bazillion of companies which complied with GPL WRT to linux kernel but were still hurt by SFC then I'll take all my words back and readily admit that SFC really goes to far. So far I've not seen even one such company.
Posted Feb 10, 2012 20:09 UTC (Fri)
by dlang (guest, #313)
[Link] (8 responses)
suuuuure.....
Posted Feb 10, 2012 20:26 UTC (Fri)
by khim (subscriber, #9252)
[Link] (7 responses)
Oh no. To make it run on BSD is only a first step. Then you need to convince people to actually use it in such configuration :-) If BSD port will just be a curiosity then court will [rightfully] say that it's existence is just a window dressing. Napster was capable of commercially significant non-infringing use - yet it was not enough, after all. But if BSD port will be used often enough then, sure, it'll mean that toybox relicense happened for other reasons besides copyright infringement facilitation. Again: nope. It's only illegal if it's only runs on linux and if a lot of companies continue to use it to violate GPL license for Linux kernel in [relative] safety. We'll see what happens. Perhaps now, when toybox is available and SFC can not use busybox to sue shady contractors, they will suddenly wise up and all start voluntarily comply with GPL license for kernel or may be they all will switch to BSD... but I somehow doubt it'll happen.
Posted Feb 12, 2012 16:55 UTC (Sun)
by landley (guest, #6789)
[Link]
*plonk*
Rob
Posted Feb 12, 2012 18:59 UTC (Sun)
by armijn (subscriber, #3653)
[Link] (3 responses)
Posted Feb 12, 2012 19:17 UTC (Sun)
by khim (subscriber, #9252)
[Link] (2 responses)
The license under which you develop you software has nothing to do with legality of such activity as I've already explained. If this project is supposed to solve problem of GPL copyright violation in one way or another (or if it's created to solve some other problems, not related to licensing at all) - then it's good, lawful project. If it's goal is to conceal an infringement - then it's illegal. Now, it's easy to claim "out goals are noble and if someone will use our work for unlawful purposes then it's not our problem", but this defense will fly only if statistic will support you. If most users of your project are using it to violate rights of someone else (for example Linux kernel developers) then you'll find yourself in a hot water no matter what you'll say. Napster is prime example - and law only becomes strict over time. ACTA is just the last step on this road - and I doubt it's the final one. The real irony here lies in the fact that SONY which pushes this expansion in the capitol and SONY which tries to "solve" it using morally-questionable tricks like relicensed toybox are the same entity - yet the logical solution (stop trying to stretch power of copyright any further) is somehow not even considered.
Posted Feb 13, 2012 8:18 UTC (Mon)
by bronson (subscriber, #4806)
[Link]
That's obviously not its goal.
And, even if it were, it still wouldn't be illegal. If you disagree, please state your case law. Napster is only relevant as a trivial example of failing "significant non-infringing" and has nothing to do with software licensing.
Posted Feb 13, 2012 22:15 UTC (Mon)
by docwhat (guest, #40373)
[Link]
Posted Feb 12, 2012 22:57 UTC (Sun)
by dlang (guest, #313)
[Link] (1 responses)
This is exactly what the game console and big media companies are trying to do.
There's a very good reason that the "open source definition" requires that there be no limit on the field of use of software for a license to qualify as open source.
It's sad to see GPL proponents playing into their enemies hands by trying to declare competing software to be illegal.
Posted Feb 13, 2012 0:05 UTC (Mon)
by dlang (guest, #313)
[Link]
Posted Feb 9, 2012 22:42 UTC (Thu)
by raven667 (subscriber, #5198)
[Link]
That basically describes the BSD family of licenses. It's different than the reciprocity and community building goals of the GPL. For example OpenSSH is used in a number of proprietary systems (such as Cisco IOS) and the BSD TCP/IP stack is used in many places (such as Windows). For large multi-vendor projects reciprocity is very important to encourage sharing otherwise each vendor is unlikely to share and will have their own, incompatible, proprietary fork with a weak central community. Only if you are lucky do those useful proprietary features get rolled into the shared project.
Posted Feb 27, 2012 23:32 UTC (Mon)
by gdt (subscriber, #6284)
[Link]
Cisco outsourced the old linksys Linux stuff to a taiwanese company after the first lawsuit, washed their hands of Linux... Cisco is a big company and so generalisations like this are unwise. Cisco's next generation switch and router software uses Linux underneath, so Cisco's views on Linux are not as black and white as you portray.
Posted Feb 1, 2012 21:47 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
You can't do that. GPL still remains in play because everyone who ships busybox also ships the Linux kernel. It takes only one key kernel developer to ask SFC to represent them and you are back to the problem you are trying to get away from. I do wonder whether SFC or FSF would be sending kernel patches in key areas with the sole idea of using it to enforce the GPL at the kernel level directly instead of using busybox as a proxy. At the point, the violators can consider using a BSD kernel. It would be a interesting fight to watch.
Posted Feb 2, 2012 8:54 UTC (Thu)
by fb (guest, #53265)
[Link]
Awesome. If that is the case, why are all this people decrying the possibility of losing their legal proxy?
Why make a big fuss if someone (actually the former Busybox maintainer) is working on a competing project?
Posted Feb 1, 2012 22:19 UTC (Wed)
by jonasj (guest, #44344)
[Link] (1 responses)
You work for Sony, who thought it acceptable to install rootkits on their customer's machines. Why in the world would I trust a word you say?
Posted Feb 1, 2012 22:28 UTC (Wed)
by jonasj (guest, #44344)
[Link]
Posted Feb 1, 2012 22:44 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (2 responses)
It is really hard to feel sorry for a rich multinational company that skips mandatory legal checks in order to be first to market.
It then becomes much much harder to feel sorry when the very same company is lobbying hard to harden copyright law so teenagers illegally downloading music can be put in jail. Compared to this the SFC now look like very nice guys.
Note: this has nothing to do with the GPL. It's about software licensing and legal reviews *in general*.
Posted Feb 9, 2012 21:35 UTC (Thu)
by landley (guest, #6789)
[Link] (1 responses)
A quote from: http://www.wired.com/wired/archive/11.11/linus_pr.html
"I do not look up any patents on principle because (a) it's a horrible waste of time and (b) I don't want to know,"
- Linus Torvalds.
Rob
Posted Feb 12, 2012 15:35 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Feb 1, 2012 23:39 UTC (Wed)
by PaulWay (subscriber, #45600)
[Link] (5 responses)
So, what, GPL authors are supposed to shut up because they might be hurting the company?
That's a harsh way of saying: none of what you say about Sony's concerns have anything to do with what we, as a community of copyrighted code authors, choose to do with our rights. It is no more acceptable for Sony to ignore licensing of FOSS code than it is for them to ignore anyone else's copyright. If anything, the fact that they stand to lose heaps of money if products are late is reason enough for them to get it right the first time. Claiming that it's all very complicated because of sub-contractors and different divisions is about as valid as a child blaming the broken plate on their invisible friend.
Aren't Sony one of the companies that are pushing for tougher penalties when people infringe their copyright? The whole point of a penalty is to provide a disincentive to infringement. At that point it should be a very simple business decision: a potential loss of millions of dollars in lost revenue due to a delayed product, or a certain loss of even more when they are found to be violating their software licenses, get fined for it _and_ have their devices delayed even further. That a company can then choose the latter option shows that they actually think that they can get away with it - their 'calculus' is based on the flawed assumption that the cost of non-compliance is less than the cost of compliance.
I'm not criticising you; I'm pointing out the hypocrisy of Sony's actions.
And I personally think the SFC saying "let us help you with getting all your licenses sorted out now", rather than waiting for compliance on BusyBox and then hitting them with the next lawsuit for the next GPL-violating thing they find, is doing the industry a massive favour. There's already enough legal shenanigans in the computer industry, with companies waiting until the ideal time to hit their competitors with lawsuits.
Ultimately, what galls me here is that Sony isn't ponying up the developers to actually write the bits of Toybox that they want, or even implementing their own BusyBox replacement if they like. They're expecting other people to do the work for them, then they come in and use it for free. All that buys them is a little bit of time: eventually the kernel community will start to enforce its copyrights and the fight will really be on. Either they need to start rewriting everything from scratch, or just harden up and comply with the licenses of the software that they use.
Have fun,
Paul
Posted Feb 1, 2012 23:49 UTC (Wed)
by tbird20d (subscriber, #1901)
[Link] (4 responses)
I've already contributed personally to the code.
Posted Feb 2, 2012 0:56 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Posted Feb 2, 2012 1:13 UTC (Thu)
by corbet (editor, #1)
[Link] (1 responses)
In a sense, Rahul, this is like us giving Red Hat grief for supporting rpmfusion - or not supporting it.
Posted Feb 2, 2012 1:51 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
If Tim is working on his own time, then of course, his association with Sony is not as relevant to this discussion but one cannot have it both ways.
Posted Feb 9, 2012 21:48 UTC (Thu)
by landley (guest, #6789)
[Link]
Tim's own time:
http://landley.net/hg/toybox/rev/413
He credited his employer, but that's not unusual:
http://landley.net/hg/toybox/rev/436
What exactly is the logic here in objecting, by the way?
"Oh no, Sony is sponsoring new open source code under a license that would allow the code to be used in the Linux kernel itself! Horrors!"
"Oh no, the guy who started the BusyBox lawsuits in the first place is rendering them irrelevant!"
"Oh no, people are writing BSD licensed command line utilities because w'eve never seen THAT before..."
"Oh no, this code may be actually better than BusyBox and intends to compete on the technical merits and win!"
Rob
(Sheesh, I mothballed the toybox project a couple years back because I didn't think beating busybox on technical merit was _enough_ to displace an entrenched competitor with a 10 year headstart, including several years of my own work. But I wouldn't have bothered in the first place if I didn't think I could do a better job on a purely engineering level.)
Posted Feb 1, 2012 23:51 UTC (Wed)
by i3839 (guest, #31386)
[Link] (16 responses)
Replacing GPL software is harder than just complying with the GPL.
For both approached you need to know which software is GPL and do something specific. All the whining about "we didn't know we were shipping GPL stuff" isn't solved by replacing known GPL stuff with something else. It's always the unknown stuff that bites you, whether GPL or proprietary.
So this doesn't solve any compliance problems except with Busybox itself. But as said above, complying is easier than replacing Busybox when you're already using it, so the only reason to replace Busybox would be because they don't want to comply with the license. Matthew is right to say this stinks, because it does.
Posted Feb 3, 2012 0:24 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (15 responses)
Posted Feb 3, 2012 2:56 UTC (Fri)
by i3839 (guest, #31386)
[Link] (14 responses)
Knowing that some subcontractor somewhere violates copyright doesn't help to solve the problem if you can't find out which software that is. If you have no access to your own device's source code you're totally screwed, one way or the other. How can you check your (sub)contractor's work if you can't see what they did?
That companies want to avoid GPL software altogether in the future is something I can understand, especially with scare tactics like losing the license forever. The GPL is too often misunderstood, partly because of FUD. But that is only possible if they are in control of the software. If they are then they have no excuses at all to not comply with all licenses. If they aren't, then writing non-GPL replacement software won't change anything.
Posted Feb 3, 2012 9:33 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (13 responses)
1. We do not have time to ask/check what our dodgy contractors are doing, (incredibly wrong in the first place) but:
Solution: influence the "market" by creating an alternative to busybox attractive enough to be selected by dodgy contractors. This will *statistically* reduce the risk of being caught.
Not moral but perfectly logical.
Think of a prepared food producer trying to introduce stricter farming regulations - even when not doing any farming itself (except this one is of course more likely to be moral).
Posted Feb 3, 2012 10:45 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Nope. Stricter farming regulations will be requirements to send the GPL code along with busybox binaries. What happens here is the coercion to replace products produced by farmers with concoction of flavour enhancers potent enough to cover the odour of rotten meat. Yup. The same as with food producers. Yet somehow aforementioned practice is universally despised while similar deal WRT software is supposed to be applauded.
Posted Feb 3, 2012 18:30 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (6 responses)
I think that is a mischaracterization of the stated concern, its not that they are being willfully ignorant of their suppliers its that in a large organization it's easy for some team to accidentally distribute pirated software by not doing due diligence on the vendor (or the vendor lying). The belief, right or wrong, is that a hostile copyright owner could cause a lot of trouble so to reduce this risk they are going to work on liberally licensed software that they own the copyrights on so that the components they maintain don't have piracy issues and presumed-hostile copyright owners.
Maybe Bradly Kuhn is some moustache twirrling ogre who's just itching to screw over some poor defenseless large manufacturer, the people involved probably know better than I, but I don't see any evidence in the publicly available information to support that hypothesis.
Posted Feb 3, 2012 23:33 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (5 responses)
> I think that is a mischaracterization of the stated concern, its not that they are being willfully ignorant of their suppliers its that in a large organization it's easy for some team to accidentally distribute pirated software by not doing due diligence on the vendor (or the vendor lying).
I think this is an overly nice way to say the exact same thing.
You MUST carefully select and watch your suppliers, period. Make sure they have a good reputation, tie them in very strict contracts, make sure they are too big too fail (and can pay you any damages back), force them to give you their source code and audit it yourself... this is really just business 101. If the managers of your company cut corners on business 101 in order to be first to market, then I sincerely hope your company dies in copyright litigations (GPL or else) because for sure my company forces us to be thorough and extremely careful, which obviously has a cost, and I would hate you beating us on the market because of that.
[Don't take it personally: it was just easier to give you the role of the bad guy]
> "Hostile Copyright Owner"
Too bad neither Hollywood nor the BSA never cared educating the masses with this new and interesting "HCO" concept.
Anyway I agree with i3839 to some extend. Even assuming that the most HCO owns and defends busybox today and that busybox gets successfully replaced, the most HCO will be someone owning something else in one year time and back to square one.
Posted Feb 4, 2012 14:51 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (4 responses)
"Some say the only two products not covered by product liability today are religion and software. For software that has to end;"
"If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then the builder shall be put to death." (Hammurabi's Code, approx. 1700 BC)
Posted Feb 5, 2012 12:35 UTC (Sun)
by alankila (guest, #47141)
[Link] (3 responses)
Then I read the link and observed it advocates liability only for closed source software, where the author of the software must be trusted, and eliminates it for software with source code, where the user could (in theory) become fully informed consumer of the software product.
Posted Feb 6, 2012 9:03 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (2 responses)
"if you make MONEY selling something, you'd better do it properly, or you will be held responsible for the trouble it causes" (emphasis is mine).
It's really more about *business* rather than closed source. If you sell open source then you are accountable (or should be). If you give closed source software for free then you should not. In the latter case you typically do not even know who is using the software and for what.
Posted Feb 6, 2012 11:31 UTC (Mon)
by alankila (guest, #47141)
[Link] (1 responses)
Posted Feb 6, 2012 16:47 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link]
Posted Feb 9, 2012 22:03 UTC (Thu)
by landley (guest, #6789)
[Link] (4 responses)
I worked at a place that checked all the source code into horrors like "Accurev", "Rational", or whatever that one beginning with a P is I've blotted out. Starting with a tarball (no history beyond that) and checking in local changes on top of that.
Then the _fun_ ones go on to check the _result_of the build into a _second_ source control system, populated entirely with binaries and tracking the root filesystem layout (or RPM binaries, or whatever they ship).
Impedence matching between the first source control system and the second source control system is entirely ad-hoc. Bonus points if they're different technologies left over from a department merger and/or partial migration that never removed the "legacy" system. (Adding new one in parallel: easy. Removing old one: hard.)
I didn't fight with this stuff in a license enforcement context. I fought with it in a "I'm working a 3 month contract to fix accumulated customer bugs in a legacy system they've forgotten how to _build_. They have partial source code for their product, but no longer have the context it built in and the people who did this moved on years ago" context.
It's lucrative, yet horrible. (I remember a contract at Dell where they paid Red Hat to support Red Hat Enterprise 2 _after_ it was end of lifed because they'd done shared libraries in C++ which did an "extern C" around all their library exports and then returned a pointer to a class instance, so all the funky name mangling changes between gcc versions bit them on the nose and they either had to upgrade bangalore, raleigh, and austin all at the same time _and_ ship a flag day release to all customers (of this funky high-end SAS array diagnostic/monitoring tool) or stick with the old compiler forevermore. They got _into_ that state because nobody had realized the full ramifications of their build. Getting a handle on the real dependencies and reproduction sequence of modern software builds is _hard_, at least when the FSF was ever involved in any way. Grub 2. *shudder*)
The real world is messy. This is not new. You're talking about BusyBox, a project that at one point had FIVE shell implementations that didn't share code. If _we_ couldn't get that cleaned up in the first decade of the project's existence, why the heck are you holding others to a higher standard?
Rob
Posted Feb 10, 2012 14:30 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (3 responses)
This is just natural selection. Bye. It will incidentally make room for higher quality software and more interesting jobs - I'm sure you will like it.
This might delay a bit the release of the next great smartphone/set top box/you name it - we will all survive.
Poor attempts to ask the "community" to rewrite this or that piece under a BSD license for you are laughable and you will buy very little time (assuming they succeed in the first place).
Once again: nothing GPL-specific in the above.
Posted Feb 10, 2012 16:11 UTC (Fri)
by landley (guest, #6789)
[Link] (1 responses)
Let the backpedaling commence.
Posted Feb 10, 2012 16:45 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
No.
The copyright system is not perfect and probably too hard but it's fair and basically working. The current patent system is completely broken and totally unfair.
Imagine you write some code, then I copy and massage a few lines of it and bang I get the copyright on the whole thing. This is how the copyright system would look like if it were managed by the USPTO.
Posted Feb 12, 2012 15:44 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Feb 2, 2012 1:29 UTC (Thu)
by neilbrown (subscriber, #359)
[Link] (4 responses)
If I understand you correctly, the real problem here is FUD.
Companies want to comply and try to comply, but there is uncertainty and doubt as to whether they will do so successfully and fear of the possible costs imposed to restore their license.
Does the GPLv3 address this? It gives a guaranteed re-instatement if you become compliant with 30 days (as long as you aren't a repeat offender). Is that enough to reduce the FUD?
That wouldn't help with BusyBox or Linux as they are v2 only, but maybe understanding if the v3 clause is helpful would give us a better perspective on the issues.
Posted Feb 2, 2012 1:36 UTC (Thu)
by dlang (guest, #313)
[Link] (3 responses)
Plus how is 'repeat offender' defined? for a large company, it's very possible for the company as a whole to trigger the 'repeat offender' clause, even if everyone who ever does something wrong never does it again (if nothing else, large companies acquire other companies, and employees at these newly acquired companies may not be doing everything per the polices of the big company)
Posted Feb 2, 2012 1:40 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Feb 2, 2012 1:44 UTC (Thu)
by neilbrown (subscriber, #359)
[Link] (1 responses)
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
Only applies "first time" for each copyright holder.
Posted Feb 2, 2012 10:14 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Posted Feb 2, 2012 4:24 UTC (Thu)
by Company (guest, #57006)
[Link] (42 responses)
So the only thing Sony does when picking the software to ship is doing a cost/benefit analysis. If the potential price for lawsuits or the risk of shipping late is too high, you pick something else.
This behavior explains very well why the company you identify with would select to install rootkits or litigate children into jail. It also explains why it would rather not have license enforcement actions.
And what this actually means is that the correct thing to do to spread the GPL over the BSD is to start sueing companies for failing to print the BSD disclaimer. Even if that doesn't really achieve anything for Free software directly, it would increase Sony's perception of risk for using BSD licensed software and make it flock to the GPL.
Did I get that right?
Posted Feb 2, 2012 4:35 UTC (Thu)
by tbird20d (subscriber, #1901)
[Link] (41 responses)
No. We have extensive mechanisms in place for compliance, for both business and moral reasons.
Posted Feb 2, 2012 10:18 UTC (Thu)
by jospoortvliet (guest, #33164)
[Link] (40 responses)
I personally find it very hard to believe that they would go after Sony, which, as you say, has a website with FOSS code, a contact point and proper procedures. There are much bigger fish to fry... But you could simply talk to them, ask what room you have for mistakes?!?
Posted Feb 2, 2012 18:59 UTC (Thu)
by tbird20d (subscriber, #1901)
[Link] (39 responses)
Posted Feb 3, 2012 11:01 UTC (Fri)
by fb (guest, #53265)
[Link] (38 responses)
I would like to point an issue which I missed in this discussion so far.
I will refrain from naming my current and previous employers because they have nothing to do with my opinions.
Regardless of whether SFC sues people over Busybox or not, as a proxy or not, I see the existence of a BSD/Apache licensed package as a positive thing. At my previous job, I wrote 'closed' source code[*]. The (rather large, think Sony-size) company had strict license compliance measures. At least in my division, any software not written internally had to get approval from 'legal' to ship. As it happens only BSD/Apache licensed code would get approval.
People may campaign and cheer the (L)GPLv[23] as much as they wish, but the *reality* today is that many companies will -for whatever reasons- simply not touch anything with GPL on it.
So I see Toybox as a positive development because strictly complying companies may end up having it as a resource, and open-source will IMO reach further than before. People may make a fuss, "oh, but there is no reason not-to-use-the-gpl". In reality writing Toybox seems more doable than changing some written-in-stone legal policies.
[*] I now work full time writing Apache licensed code :-P and yes at my previous job, we did submit every little patch we made on Apache code to "upstream".
[...]
On a personal note, I really never thought I would see a discussion at LWN where people would be arguing in favour of software scarcity.
Posted Feb 3, 2012 18:53 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (1 responses)
There is certainly some outreach that should continue to be done, sometimes the GPL is rejected because of fear and misunderstanding of what the license actually says and means. I get the sense that the Android core developers have some funny ideas about how the GPL works. Other companies prefer to contribute to GPL projects rather than BSD because the reciprocity means that they are always on a level competitive playing field. Very few business would be comfortable with all of their hard work feeding in a one-way direction to their largest competitor.
Posted Feb 3, 2012 19:37 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Yup. Google is the process of discovering that. Via Android (see Kindle Fire and Nook Color), via Chrome (see chrome.yandex.ru)... We'll see what it'll do.
Posted Feb 3, 2012 22:11 UTC (Fri)
by jimparis (guest, #38647)
[Link] (34 responses)
Busybox only works with Linux. Linux is GPL. You can't have it both ways -- either you're violating the license of Linux, or your company's legal department is already fine with following the GPL.
Posted Feb 3, 2012 22:38 UTC (Fri)
by tbird20d (subscriber, #1901)
[Link] (32 responses)
A consistent meme in this discussion is that the motivation for this project is only because busybox is the only actively enforced component. I keep pointing out a different motive - and it keeps getting ignored and rejected, which is a bit frustrating. It's really because some of the interpretations of the GPL (like the death-clause and scope of remedies) by the SFC appear to me to be counterproductive.
I'm entirely comfortable dealing with gplviolations.org, or the kernel community - not because either of these other parties are lax in their enforcement (although admittedly the kernel community appears lax), but because I trust their interpretation of the GPL more, and their reasonableness about rectifying mistakes.
Posted Feb 3, 2012 23:29 UTC (Fri)
by jimparis (guest, #38647)
[Link] (31 responses)
It is a consistent meme because they hardly seem independent. You are asking us to believe that a difference in "interpretation" is the reason for Toybox, and its creation is in no way related to the fact that the SFLC will sue you when nobody else will. That's just hard to swallow, from the point of view of the open-source community that has traditionally had a very hard time getting companies to follow the license.
> I'm entirely comfortable dealing with gplviolations.org, or the kernel community - not because either of these other parties are lax in their enforcement (although admittedly the kernel community appears lax), but because I trust their interpretation of the GPL more, and their reasonableness about rectifying mistakes.
As you say, they are lax. Neither gplviolations.org nor the kernel community have ever taken anyone to a US court. I'm just not convinced that your trust in "their interpretation" and "their reasonableness" is not at all affected by the fact that they have demonstrated no legal teeth.
Let's say you have a habit of "borrowing" things without permission, never with bad intentions. Of course you'd rather borrow from your kind neighbor who, upon catching you, says "Hey, that wasn't nice" and asks for it back. You don't like borrowing from the other grumpy neighbor who calls the cops right away. You make a big fuss to make sure everyone knows that you got your own lawnmower and will no longer need to borrow the grumpy neighbor's, because hey, he was totally unreasonable to call the cops on you. Then the kind neighbor says "You know, you should just stop borrowing our stuff without permission in the first place" and you say "Come on! That grumpy guy was a total jerk. This has nothing to do with my borrowing, just his interpretation of property law."
If you want a new lawnmower, that's fine. But you shouldn't use it as an excuse to bash on the grumpy guy, and don't be offended when the nice neighbors also use this opportunity to complain about how they're being treated and how you're not doing them any favors.
I'm just a bystander. My point of view may be entirely wrong. Maybe the threat of being sued truly has no effect on your or Sony's views of Busybox. Maybe the SFLC does act unreasonably even when there was a honest mistake somewhere in the supply chain. But I've seen no evidence of that.
Posted Feb 4, 2012 0:29 UTC (Sat)
by tbird20d (subscriber, #1901)
[Link]
If you don't trust me, I get it. You can think whatever you like. I would address your mower metaphor, but it seems pointless since people are obviously disposed to distrust what I say, and I've been over it already.
Posted Feb 4, 2012 0:41 UTC (Sat)
by dlang (guest, #313)
[Link] (27 responses)
you may want to actually go look at toybox and it's creator (Rob Landley, a former maintainer of Busybox, and one of the plaintifs in many of the SFLC busybox lawsuits)
Rob has been working on the project since 2006, and it's only in the last few months that he changed the license on it from GPLv2 to BSD. Go back through his blog entries, he has been very vocal about toybox being worked on because he thinks that it is better than busybox. Yes, part of the reason is that he didn't want to give Bruce any possible claim over the code, and he doesn't like GPLv3, but it was worked on because he wanted it to be better than busybox.
Since toybox was a GPLv2 project for several years, it couldn't have been created to make it easy to bypass the GPL
Since toybox was created while Rob was a plaintif represented by the SFLC, it couldn't have been created because he was unhappy with how the SFLC was handling the lawsuits.
Posted Feb 4, 2012 0:46 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link]
Posted Feb 4, 2012 1:10 UTC (Sat)
by khim (subscriber, #9252)
[Link] (25 responses)
I have no problems with Rob's work. Of course not. It was only co-opted for that purpose. The evidence is damning: On an engineering note, they never contributed a single line of code to BusyBox. NOT ONE. I thought they would, but they didn't, so I stopped pursuing them. What does it say to you? Two things. OEMs don't really change busybox code thus it's enough to just call busybox --version, download tarball from the official site and you can recreate binary. Now, we have two pieces of software (busybox and Linux kernel). One is 100 times more complex and 1000 times more often modified in practice by OEMs. And someone want to replace the simplest half of the pair - with the explicit goal to STFU the guys who use it as a proxy to get sources for the more interesting part. What does it say about the possible goals? In fact SONY and others stretched copyright so much that you can argue that project under discussion is doing is most probably flat out illegal. Because in 99% of cases it'll be used as a means to facilitate copyright violation. This fact was enough to kill Naster, why should it be ignored in this case?
Posted Feb 4, 2012 1:25 UTC (Sat)
by dlang (guest, #313)
[Link] (23 responses)
> I have no problems with Rob's work.
but then you say
> that project under discussion is doing is most probably flat out illegal.
but you are talking about exactly the same project, Rob's toybox project.
which is it, Rob's project is Ok, or Rob's project is illegal?
you can't have it both ways.
Posted Feb 4, 2012 11:21 UTC (Sat)
by khim (subscriber, #9252)
[Link] (22 responses)
Yes, I can. Check the first world: I. I, personally, have no problems with Rob's work - but then I'd prefer world where copyright is much less powerful (or where it does not exist at all, as I've already said). But Disneys and SONYs of our world prefer not just strong, but superstrong copyright. They lobby for extensions in congress, they constantly try to straighten it in lawsuits, etc. IMNSHO (as Napster story showed) they already inflated power of copyright so much that that what Tim is doing is most probably illegal because that feature would have no commercial value without the non-infringing product. Nope. Rob's project used GPL and as such for not usable for Napster-style copyright indictment. Because it was just practically impossible to use it without violating both license of kernel and license of toybox. What Tim did is convinced Rob to change license - and this made toybox mostly useful as a facilitator of infringement of Linux kernel copyright. Right now it's a theory - and not very solid at that. We'll need more evidence before it can be tested in court. If most toybox users will nonetheless diligently ship sources of Linux kernel (this is what Tim explains what is the goal of project: industry guys are quite Ok with GPL compliance and only want bisybox replacement to avoid pesky SFC) - then this theory will evaporate in a puff of smoke. If most users will infringe on Linux kernel copyright then aforementioned theory will be straightened enough to question the legality of initial Tim's work, too. I just want to point out that SONY, too, can not have it both ways: it can not push to expand copyright power endlessly and at the same time expect that it'll not be affected by said expansion on the other front where it's not plaintiff, but defendant. Right now the coin is in air and how it'll land depends on future actions of chip vendors and suppliers. As well as on the future actions of Tim itself: he can claim that toybox is just first step and chip vendors and suppliers plan to replace Linux kernel, too (this will close this problem once and for all), but then he should show come concrete steps in this direction to convince court that it's all is not just "smoke and mirrors". BSD-relicensed (that's important) toybox looks very much like Napster-style copyright infringement facilitator.
Posted Feb 4, 2012 19:04 UTC (Sat)
by alankila (guest, #47141)
[Link] (20 responses)
I think such a theory would be laughed out of any court. If licenses are being violated on some piece of software, then let those who have the authority sue if they choose to. If the kernel people do not feel like suing, then it does seem questionable to me that busybox people feel like they have the right to impose settlement conditions on the kernel because of violations on busybox.
Secondly, GPL does not have so much leverage as it once seemed to: there appears to be not-GPL replacements for most if not all the pieces of the system software stack today. I'm sure that changing from Linux to some other kernel would be a tough engineering effort, but scaring enough companies with GPL threats could make them band together and start a replacement effort on some other kernel (bsd?). In the end, if all GPL-licensed software becomes replaced then the legal theory you are advancing will fail too, because there is no GPL-licensed software left whose license could be violated.
Posted Feb 4, 2012 21:22 UTC (Sat)
by khim (subscriber, #9252)
[Link] (19 responses)
Which will make the further discussion pointless. Eben Moglen said it best here: Context is everything when law is concerned. The very same actions can be interpreted radially differently in court - depending on the context. That's why you can not just grab random pieces of legal advice and use them in court and that's why legal advice is so costly in general: it must be fine-tuned for your particular case. Oh, sure. Only copyright holders of the code in kernel can ever sue Tim. I and you can not (unless you own significant chunk of kernel code, that is). At least that's the situation today. It may change tomorrow. Sure. But when they will finally decide to sue they may decide to sue not just people who violated their copyright, but the people who've facilitated infringement of said copyright. And if it will be found that toybox is mostly used by sleazy companies to continue to violate kernel's copyright... well, at this point the project in question can found itself in hot water. Note: it all will depend on how far companies will stretch copyright in their efforts to provide
adequate legal protection and effective legal remedies against any person knowingly performing without authority any of the following acts knowing, or with respect to civil remedies, having reasonable grounds to know, that it will induce, enable, facilitate, or conceal an infringement of any copyright or related rights. Looks like Disneys and SONYs of the world are quite serious which means that while what Tim is doing today is still legal (even if morally questionable) it may become illegal tomorrow! Indeed. As I've said already if toybox will be mostly used in combination with some kind of BSD kernel then the aforementioned theory will evaporate in a puff of smoke. We'll see. Sure. If the project in question will be expanded to cover all the GPL-licensed code typically used by shady contractors and if GPL code will be eradicated as result then it'll be different story entirely. But so far it does not look like port of toybox to other kernels is even considered - and this puts the whole effort squarely in the "copyright facilitator" bin.
Posted Feb 5, 2012 11:12 UTC (Sun)
by rahvin (guest, #16953)
[Link] (10 responses)
As you mention the first use was the Napster case that resulted in the entire company getting shut down. But there have been other cases, such as Limewire, Grokster and several other smaller players. In all the previous cases it was a civil lawsuit and involved the argument that centered around contributory copyright infringement and resulted in millions of dollars of damages. Most of the cases were appealed all the way to the Supreme and as such have established a fairly solid legal citation in future cases (baring a future reversal by the Supreme).
But more recently the MegaUpload cases presents a dramatic escalation in this with a criminal proceeding with racketeering charges tied in where the US government is seeking multiple years of jail time for the parties responsible. The theory you've presented is interesting because it's a well established precedent in US courts that contributory copyright infringement is a real and punishable offense.
The court verdicts to date have basically established the precedent that if the intent and use of the product was for the primary purpose of infringing copyright, even if there are legitimate uses that make up a small part of the use case, that the parties responsible are guilty of contributory copyright infringement for the behavior of their users. You have to wonder if these verdicts couldn't be stretched to extend to this situation. Although it'll be argued the intent wasn't to encourage GPL infringement (but to avoid a SFC legal action) by the people involved it should be fairly obvious that regardless, a significant number of people in the community and on LWN have interpreted the action to be an attempt to facilitate infringement and that this entire discussion would likely be used in the case, particularly the comments by those involved.
Would a GPL case extend to this level? I doubt it, but as you say history doesn't predict the future. With laws like SOPA in play an ambitious district attorney looking to get their name in the news could litigate a GPL case without the consent of copyright holder (one of the many scary clauses in the law).
An interesting hypothesis no doubt, thanks for posting it.
Posted Feb 5, 2012 15:00 UTC (Sun)
by khim (subscriber, #9252)
[Link] (9 responses)
Now you can understand why I clearly distinguish Rob's work and Tim's work. Rob just wrote yet another replacement for busybox - may be technically interesting, but legally pretty plain project. It used the same GPL which both busybox and Linux kernel are using thus it was not all that interesting from the legal perspective: yes, SFC had no way to enforce it's copyright, but thus was just Rob's goodwill, it was easy for him to change his mind at any time. Hardly a reason for a hypothetical sleazy company to be excited. And hardly anybody was excited: toybox was around for years but was mostly a curiosity not worth talking about much. Tim, on the other hand, convinced Rob to change license and make it as close to public domain grant as possible. Now it becomes much easier to infringe on kernel's copyright. Tim even admits it's directly:
Posted Feb 10, 2012 0:18 UTC (Fri)
by landley (guest, #6789)
[Link] (8 responses)
http://source.android.com/source/licenses.html
_I_ am the one who brought up Toybox, and pointed out I already _had_ something that was way the heck ahead of Toolbox, and which I'd love an excuse to work on again.
And I have already been talking about the smartphone replacing the PC since BEFORE ANDROID EVEN EXISTED:
http://landley.net/notes-2010.html#09-10-2010
(The 2002 reference in that is about when I wrote an article on the topic for a now-defuct wesite called linux and main, I might be able to pull the article out of archive.org if I try. I note that Eric's objection was ergonomics would limit the usability of palm pilot and newton and such. There weren't any USB docking stations yet, but it seemed obvious to me that the problem would be solved, and that internet-through-cellphone was _compelling_. Yes, in 2002. And yes, I hit bad bufferbloat the first time I tried getting internet through my cell phone on Linux in 2001, I just had no idea what to _do_ about it and assumed I'd configured things wrong.)
I'm the one who made the connection that "Oh, if toybox was BSD licensed _that_ would give it a separate niche from busybox giving me an excuse to work on it without feeling like I was wasting my time, because android is a deployment platform that only bsd licensed code can fit in. And I could use that as leverage to steer android towards a more full-fledged posix environment, and from there it's a simple step towards leveraging my aboriginal linux project to make android self-hosting, and then android would have a leg up against the iPhone, which it's been losing to recently".
The enthusiasm was _mine_, because I saw a path forward I'd missed before, which Tim's agenda was just a tiny part of. Tim was actually going a different direction with it, by I got an idea talking with him.
It was an idea that FSF zealots really don't like, but they lost me in 2006:
http://landley.net/notes-2006.html#03-12-2006
And I've been drifting _away_ from the GPL ever since. Before you blame Tim for my "screw it, BSD license the sucker" decision, read this bit almost TWO YEARS EARLIER:
http://landley.net/notes-2010.html#10-01-2010
> Since uClibc's so obviously moribund, I'm vaguely pondering poking at
And goes on to talk about the merits and drawbacks of BSD licensing.
This was me analyzing some more of Android's licensing decisions a year before I relicensed Toybox:
http://landley.net/notes-2010.html#09-10-2010
So by all means, consider me some kind of strange puppet for Tim that's unable to form any independent thoughts about licensing, let alone make informed decisions like an adult.
Posted Feb 10, 2012 10:16 UTC (Fri)
by khim (subscriber, #9252)
[Link] (7 responses)
Better userspace for Android will be easy sell. GPL infringement facilitator is not. Even if technically it's the same project. P.S. Actually userspace for android is slightly different project because to support Dalvik you need different set of tools then to support traditional POSIX userspace.
Posted Feb 10, 2012 16:19 UTC (Fri)
by landley (guest, #6789)
[Link]
"We'd like to get an alternative to BusyBox to protect ourselves from the insane out of control SFLC/SFC and their demands about third-party binary only kernel modules and vendor toolchains we've never even seen the source code to if we shipped a vanilla unmodified busybox but didn't SAY we shipped a vanilla unmodified busybox."
"We'd like to distance ourselves from this legal quagmire rather than try to navigate an endless shifting maze."
That's not _my_ motivation, but I can certainly see spraying for lawyers holding an appeal for people, especially when legal stuff isn't what they _do_. And if it makes 'em more likely to use the code I already _wrote_ and am still adding to (which is technically better than the alternative)? Sure, why not?
Rob
Posted Feb 10, 2012 16:22 UTC (Fri)
by landley (guest, #6789)
[Link] (5 responses)
Don't put lifeboats on your cruise ship. Make it unsinkable. By planning for what happens if the boat sinks, you're planning to sink the boat! Shame on you, lifeboats are EVIL!
Rob
Posted Feb 10, 2012 17:21 UTC (Fri)
by khim (subscriber, #9252)
[Link] (2 responses)
You are not putting lifebots on a ship. You are adding couple of lifebots to Titanic. This makes no sense whatsoever. If you don't expect for it to be sunk then why bother with lifebots at all? If you do expect crash and burn scenario then why do you plan to save just a handful of people, not all of them?
Posted Feb 11, 2012 14:35 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
She had FAR more lifeboats than were legally required.
And could have saved a lot more people, if they hadn't messed up evacuating the boat. Plus a load of people didn't want to get on the lifeboats because they felt safer staying on board (pretty much the same as happened in the recent cruise-ship sinking in Italy ...)
(I think the law nowadays says you need enough spaces on EACH SIDE of the boat for the entire passenger/crew complement - ie 2 spaces per person. Most boats carry even more. It makes sense, actually, if the boat is listing you can lose half your usable lifeboat capacity in the space of seconds.)
Cheers,
Posted Feb 11, 2012 15:39 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Sure. Law required just 16 lifeboats while Titanic had 20. With total capacity of 1,178 people on a ship with capacity of 3,547. Less then ⅓ space per person. Good idea. Not. That's another issue. Yes, even if you have enough lifeboats you still can lose a lot of lives in a case of crush. But if you don't have enough lifeboats to save all passengers then loss of life is inevitable. Sure. More then one space per person may be good idea. How much more is subject of the debate. Less then one space per person is pointless - and this is exactly how Titanic was equipped.
Posted Feb 12, 2012 15:51 UTC (Sun)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Feb 13, 2012 8:27 UTC (Mon)
by bronson (subscriber, #4806)
[Link]
Posted Feb 5, 2012 12:25 UTC (Sun)
by alankila (guest, #47141)
[Link] (3 responses)
But as you point out, law is essentially insane and random, and stranger things could happen. My personal feeling, however, is that this is not fair nor right, whatever the courts might find.
Posted Feb 5, 2012 15:14 UTC (Sun)
by khim (subscriber, #9252)
[Link] (2 responses)
Nope. Again: context matters. As rahvin already wrote: The court verdicts to date have basically established the precedent that if the intent and use of the product was for the primary purpose of infringing copyright, even if there are legitimate uses that make up a small part of the use case, that the parties responsible are guilty of contributory copyright infringement for the behavior of their users. Not only you should show that someone picked your piece of software because it's under BSD license (that's understandable: less rules to follow), you must show another piece of GPLed code which is commonly used with first one and show that most users of your software not only continue to use it, but also do it in violation of it's copyright. Tall order, indeed. No questions here. I also feel that copyright's power is inflated way, way, WAY beyond any reasonable limits. But... dura lex sed lex. And since Disneys and SONYs of the world were instrumental in said insane inflation it's only proper to apply no mercy, as much punishment as possible principle to them.
Posted Feb 5, 2012 23:13 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (1 responses)
What about the idea of someone picking the BSD-licensed software simply because it was better code than the GPL software (i.e., written by somebody with several years of experience with the GPL codebase, taking into account any design and implementation issues since discovered with the GPL codebase etc., and better targeted towards solving the actual problem that users of the software need solved)?
In that case it would be difficult to argue that the »intent and use« of a BSD-licensed Busybox workalike would be »for the primary purpose of infringing copyright«. Maybe its intent and use is to provide a technically superior all-in-one shell-type tool, and its users prefer it to Busybox on these grounds (with the more liberal license as a fringe benefit). This isn't Napster, after all.
Given this, it would be next to impossible (for someone like the SFC) to show that somebody picked the BSD-licensed software exclusively on licensing grounds, and claiming that this in turn was only done to avoid GPL compliance issues concerning the Linux kernel would border on a conspiracy theory. At the very least, someone like the SFC would have to prove that the workalike was clearly less suited, technically, for its intended use (by the defendant, not the FLOSS community in general) than the original GPLed Busybox, and that the defendant still went for the workalike just to be able to do an end-run round the SFC. Have fun.
Posted Feb 6, 2012 0:33 UTC (Mon)
by khim (subscriber, #9252)
[Link]
I never said it's easy to probe illegality of this work. In fact just a dozen years this question was flat out crazy: it was obvious that if there no copyright violation then there are no material for lawsuit. And as I've already said: it's hard to say a-priori which way the development will go. In fact there already exist alternative BSD-licensed userspace fro Linux: Android's one (albeit in this case it's pretty clear that it's goal was to support Java-based environment and not to act as GPL-free replacement for GNU tools). And if companies that use toybox will be postly good citizens then we'll not a problem: as was shown many times already it's not about busybox or toybox. But Disneys and SONYs of the world are hard at work - and they continue to extend the reach of copyright in the vain hope to squeeze more money from 100 years old creations. If enough guys from enough companies will blab out that they are switching to toybox to solve "SFC problem" then you'll have materials for lawsuit. It'll not matter if toybox is inferior or superior. If proportion of GPL-violating companies will be high enough among toybox users and low enough among busybox users and you'll have direct evidence for a few "switchers" - you'll probably have enough for the court in the current world, where copyright importance is inflated beyond any reason. And in tomorrow's world it may be even easier.
Posted Feb 9, 2012 23:44 UTC (Thu)
by landley (guest, #6789)
[Link] (3 responses)
You're claiming that my new project might be considered an infringement facilitator AGAINST MY OLD PROJECT, and that stopping the lawsuits I _started_ might somehow legally do... something?
Your honestly believe that the legal system can and should forbid people from doing new things that compete with (and obsolete) their own previous work? And you take this position in defense of "freedom", as defined by the FSF?
I ask seriously: are you crazy? Do you need some kind of diagnosis and treatment? (I already _know_ the FSF does...)
Posted Feb 10, 2012 10:06 UTC (Fri)
by khim (subscriber, #9252)
[Link] (2 responses)
Oh yea. Absolutely. This is what this lawsuit is all about. Oracle even explicitly claimed that the fact that the very same people are working on Dalvik that worked on Java decades ago increases Google's liability. Or perhaps you live in some other world where such things never happen? That's different question. I know that the legal system can and does forbid people from doing new things that compete with their own previous work. I'm not saying it's good thing - that's another thing entirely. Law exist without FSF's freedom. Government changes it, not FSF. I've pointed that what you are doing is probably illegal and that you can be sued for doing it in the future. This is almost certainly true. But I'm not saying that this is what FSF should do. Just because you can sue someone does not mean you should. That's different story altogether. Me? I'm absolutely sane. The copyright world is crazy - but sadly I don't know how to cure it.
Posted Feb 10, 2012 17:15 UTC (Fri)
by landley (guest, #6789)
[Link] (1 responses)
Not in California or Texas it doesn't. ("Right to work" states.) There's rather a lot of case law on this. Silicon Valley was _built_ on the "traitorous eight" from Shockley Semiconductor.
http://en.wikipedia.org/wiki/Traitorous_eight
Honestly, if you work in the industry you get to know this stuff...
Rob
(Oratroll is suing over patents, sounds like they're attempting to establish treble damages for wilful violation, ala http://www.ipwatchdog.com/patent/advanced-patent/patent-i... . Which is in fact the reason Linus gives for not reading software patents.)
Posted Feb 10, 2012 17:38 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Sure. These tales are very well-known. But that happened half-century ago. Companies worked diligently to rectify "the problem" all that time. Today the outcome of such lawsuit is quite different to predict. Nope. Copyrights are very much in dispute, too. And outcome is not yet certain. And I'm sure if Oracle will be repelled this time then it'll cooperate with Disneys and SONYs of the world to change the law to make sure next time they'll win. In fact the whole SFC "problem" have one trivial and quite logical solution: change the law, reduce copyright power and make what SFC is doing illegal. Sadly Disneys and SONYs of the world reject this solution out of hand because it'll reduce their copyright power, too. Well, as long as that's the case don't expect me to feel any sympathy to their plight. They brought it on themselves.
Posted Feb 9, 2012 23:36 UTC (Thu)
by landley (guest, #6789)
[Link]
"It's not impossible, I used to bullseye womp rats in my T-16 back home. They're not much bigger than two meters."
I wrote the toybox code, I own the copyright on the code, I issued a second license to my copyrighted code. (A license is a permission statement. The older versions were released under GPLv2 and that was the only set of conditions you had permission to use it under. I have since granted additional permission to use my copyrighted code under less restrictive terms. Legally, the two are unrelated.)
As the guy who _started_ the Busybox licence enforcement suits, as someone who spent a couple years paid by IBM's lawyers as a domain expert to help defend them against legal claims, as someone who had an email exchange with Richard Stallmand in the 90's about nuances of the GPL for a "copyright and licensing HOWTO" that eventually turned into a week-long series of articles on the five types of intellectual property for The Motley Fool:
http://www.fool.com/portfolios/rulemaker/2000/rulemaker00...
As somebody who has studied intellectual property law as a hobby since the 1990's, as someone who has spoken on panels discussing the GPL when the other panelists were professional practicing lawyers, as someone who was once flown to new York to speak on a panel with Eben Moglen (the lawyer co-author of the GPL) about GPL enforcement.
As all that and more, I tell you:
No, it's not "important". You have absolutely no _clue_ what you're talking about, and I don't appreciate the transparent FUD.
Posted Feb 9, 2012 23:17 UTC (Thu)
by landley (guest, #6789)
[Link]
No, it says that past ones didn't. I cut my ties at the end of 2008, I haven't seen anything new show up in the busybox repository or on the mailing list that's attributable to lawsuits since, but to be honest I haven't been paying _that_ close attention. Outside of submitting my patch implementation, fixing busybox vi's horrible serial handling, trying to convince Denys to adopt some of toybox's better infrastructure (such as having all information about a command be in one file per command), and some trivial cleanups to demonstrate the the code doesn't HAVE to be #ifdef salad (I.E. "this is what I added the ENABLE_BLAH and USE_BLAH() macros for 5 years ago, you're using them wrong")... I haven't really paid that close attention to the busybox list. I catch up when I move to a new release, get involved in a thread or two, and then wander away again.
I still seem to have an impact when I do show up. My last exchange was:
http://lists.busybox.net/pipermail/busybox/2011-November/...
Which led to me fairly randomly advocating "some things are better as as shell scripts, not in C":
http://lists.busybox.net/pipermail/busybox/2011-November/...
And then I wandered away again, but this morning I noticed, in year 13 of the project we now have:
http://git.busybox.net/busybox/commit/?id=d0222503ff9ff26...
(My rsync script which syncs my laptop up to my web server also does a git pull on various repositories, and busybox is still in there...)
Sheer coincidence, of course. But given a choice, I'd rather put my energy into Toybox than Busybox. When I worked on busybox, I wanted it to spread up into the desktop and become the standard command line of things like Knoppix while remaining small and simple. Neither happened. Now I want toybox to spread down into android and ride the smartphone up as it displaces the PC the way the PC displaced the minicomputer, and that displaced the mainframe before it.
And before you say "that's impossible", google "Toshiba Dynadock" and imagine what plugging a USB docking station into an android phone containing a native compiler actually _means_...
Rob
Posted Feb 4, 2012 14:30 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Posted Feb 9, 2012 22:54 UTC (Thu)
by landley (guest, #6789)
[Link]
No, Toybox started in 2006, because a troll showed up to take credit for all my work ten years after he last wrote any code (for anything), and disgusted me so hugely I left busybox entirely rather than let him take credit for one more LINE of code I wrote:
http://landley.net/notes-2006.html#26-09-2006
But I still wanted to work on small, simple utilities (I had several half-finished, and I write this sort of code for fun), so I took the excuse to start over from scratch without the decade of legacy design decisions BusyBox had accumulated. Instead of just sulking, after I withdrew from BusyBox I started a new project and sat down to write better code:
http://landley.net/notes-2006.html#01-10-2006
I continued to work on it, on and off, for the next 3 years, until I'd solved all the interesting design problems and knew how the new project should be implemented. But I had a bunch of other demands on my time (aboriginal linux, my tinycc fork, day job), and I had the problem with Toybox: the niche it was going for was already filled. By BusyBox. I'd appointed its current maintainer and handed years of my work off to him, I was going up against something with a 10 year head start, led by a smart active guy, including years of my own work. It was "good enough", merely being technically _better_ wouldn't necessarily draw users away from it. It had a greater "project gravity", and is what people would reach for first to solve the problem both projects addressed.
I started to consider rejoining BusyBox after about 2 years:
http://landley.net/notes-2008.html#30-06-2008
And eventually I mothballed ToyBox and started pushing my work "upstream" into busybox (which was actually a huge port since the point was to base from-scratch rewrites on completely different infrastructure):
http://landley.net/notes-2010.html#11-03-2010
The biggest chunk of infrastructure was my new patch implementation, because BusyBox's was more or less a stub. But I also met denys at CELF 2010 and explained toybox's config and help infrastructure (where all you do to add a command is add a toys/mynewcommand.c file and then re-run the build and it picks everything up from that; in BusyBox you had to touch 5 different files), and so on.
But I liked the toybox infratructure much better than busybox's, even with what cleanups I managed to convince Denys to do. And unfortunately, BusyBox had lost focus on "simple", and moved it down below "small binary size", "fast execution time", and "lots of features". The resulting code was #ifdef salad full of magic annotations and control flow that hid the program's actual entry point in libbb/appletlib.c line 771. The result was just no fun to work on:
http://landley.net/notes-2011.html#08-06-2011
For a couple years I vaguely tried to learn Lua to rewrite toybox in that as a way of giving it a reason to exist separate from busybox (and thus a reason for me to still work on it):
http://landley.net/notes-2009.html#26-02-2009
But lua turns out not to have a standard posix binding, making rewriting toybox in it kinda hard. (If I have to include native C code to extend lua, I might as well write the whole thing in C. Being in a higher level language eliminates the need for cross compiling, but being in a higher level langauge with C extensions _doesn't_.)
So toybox was in limbo for a couple years, with the bits I really _needed_ (for my aboriginal linux project, creating the smallest Linux development environment capable of rebuilding itself from source) pushed into busybox, but busybox being no fun to work on and not seeing much point in pushing toybox up a hill busybox was already at the top of...
Then when Tim contacted me in November, what he did was point out that there _was_ a niche for ToyBox: on Android, which by policy forbids GPL in userspace but has only a stub command line that's crying out to be replaced.
I've considered Android very important for a while now, because it _will_ take over from the PC:
http://landley.net/notes-2011.html#26-06-2011
And Linux won't:
http://landley.net/notes-2010.html#10-03-2010
I just hadn't played with its native development environment much after a bad early experience:
http://landley.net/notes-2010.html#10-01-2010
So when Tim went "android" (and pointed out the AOSP is much less stupid now than it was 2 years ago) I went "D'oh" and started scheming:
http://landley.net/notes-2011.html#13-11-2011
I'd never have left GPLv2 behind if it wasn't for GPLv3. (I seriously doubt Android would have forbid GPL in userspace either, v2 got tarred with the same brush as v3.) I loved GPLv2:
http://sf.geekitude.com/content/pros-and-cons-gnu-general...
But I'm not the one who left the GPL, it left _me_:
http://landley.net/notes-2006.html#03-12-2006
Rob
Posted Feb 3, 2012 22:40 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
Posted Feb 3, 2012 23:56 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
http://www.h-online.com/open/features/We-won-and-we-didn-...
Companies which exclude any piece of GPL'ed software without even considering it are obviously restricting their options, which is unlikely to make them more competitive.
> ... and open-source will IMO reach further than before.
Whether BSD or GPL is more efficient at producing open-source has been debated 5 zillions times already, and the answer is certainly not as obvious as you make it sound.
Posted Feb 2, 2012 15:09 UTC (Thu)
by dwmw2 (subscriber, #2063)
[Link] (2 responses)
The motivation is to reduce the risk and the adverse consequences of a violation — whether it be an intentional or inadvertent violation.
Personally, I don't care care about the distinction between deliberate and accidental violation, which seems to be the major difference between your version and Matthew's statement. If you have taken steps to reduce the consequences of an "accidental" violation, that can only mean that you want to reduce the amount of effort you expend in ensuring that you comply with the licence in the first place. Which makes it, to me, a deliberate choice.
It's a shame that Busybox has been left with the responsibility of bringing errant manufacturers into compliance, and I'm glad that they asked for the manufacturers to comply with the licences of all the software they ship, rather than only asking for the source for Busybox. That doesn't seem like an excessively costly and inappropriate condition, to me.
If one of my children calls the police because I'm beating them, I think it's quite right for the police officer to refuse to leave me alone until I stop beating all of my children; even the ones who didn't make a formal complaint.
Harald has done good work in the past, but as noted elsewhere he's extremely busy with other things now. And if Busybox is no longer going to be able to help to keep manufacturers honest, we do actually need someone like the SFC to be acting directly on our behalf.
I'll be assigning the rights to the SFC to enforce all copyrights that I personally hold in the Linux kernel and any other project they ask me about. I strongly encourage all other kernel developers to do the same.
Posted Feb 2, 2012 19:47 UTC (Thu)
by masoncl (subscriber, #47138)
[Link] (1 responses)
I'd encourage anyone who does so to retain control over the way those copyrights are used. This isn't a dig against the SFC, just a good idea in general.
Posted Feb 2, 2012 19:58 UTC (Thu)
by dwmw2 (subscriber, #2063)
[Link]
We're certainly not talking about copyright assignments or anything like that.
I trust the SFC to handle things appropriately, and if they ever lost my trust I could withdraw my authority simply by sending them an email and telling them so.
Posted Feb 3, 2012 11:50 UTC (Fri)
by dwmw2 (subscriber, #2063)
[Link] (1 responses)
There are plenty of other shopkeepers who have been stolen from. And so far, the stuff that's been stolen from them has been returned after that one guy has gone to the police and the thieves have been caught.
So yes, you can silence that one guy, but you are taking a gamble that none of the others will start to stand up for themselves, now that he's gone.
There are all kinds of other discussions going on in this thread, about how the mayor is evil for "encouraging" stealing, which I don't believe. And how the one shopkeeper is evil for demanding that the thieves return all the stuff they stole, rather than only the stuff they stole from him.
All of those other discussions miss the point, as far as I'm concerned. The point is that this "insurance", which shuts up the one guy who's been calling the police and getting stuff returned for all his friends, is not going to work.
Someone else is just going to call the police instead. It's a PITA for them and it distracts them from the shopkeeping that they prefer to do — but if their friend can't do it any more, they'll just have to do it themselves.
Posted Feb 3, 2012 12:39 UTC (Fri)
by dwmw2 (subscriber, #2063)
[Link]
He might tell tales of police brutality, but be strangely unable to provide actual evidence of this.
He might encourage those people who complain about the police returning stolen goods to everyone, rather than just the one shopkeeper who reported the theft. And try to expand that complaint into something more sinister about the police being "overzealous", but again without any real evidence.
And he might find any other method he can to discredit the police with unfounded claims.
Hopefully, the other shopkeepers would have the wit to see through that deception.
I believe that Bradley Kuhn is telling the truth when he reports what the SFC actually ask for; I find it hard to believe any of the wild claims I've heard, and I trust that their behaviour will be continue to reasonable.
But to a certain extent that doesn't even matter. I don't have to trust that the SFC will always behave reasonably for ever and ever — because if they ever did violate my trust, I'd just withdraw my permission for them to act on my behalf.
I strongly recommend that every kernel developer should work with the SFC and allow them to take enforcement action on our behalf. You don't have to sign in blood. If any of these unfounded claims ever did turn out to be true, you could easily withdraw your permission. It's that simple.
Posted Feb 1, 2012 19:33 UTC (Wed)
by dlang (guest, #313)
[Link] (12 responses)
Posted Feb 1, 2012 19:38 UTC (Wed)
by corbet (editor, #1)
[Link] (11 responses)
Posted Feb 1, 2012 19:45 UTC (Wed)
by armijn (subscriber, #3653)
[Link] (9 responses)
Posted Feb 1, 2012 20:11 UTC (Wed)
by corbet (editor, #1)
[Link] (6 responses)
In other words, it is true that AVC v. Cybits is the only news on gpl-violations.org since 2008. So it looks like not much is going on.
Posted Feb 1, 2012 20:29 UTC (Wed)
by laf0rge (subscriber, #6469)
[Link] (2 responses)
But yes, the project is up and running and we've been doing enforcement all the time along. There's a maximum cap of 10 cases in parallel at this time, to not stretch the thin resources even thinner. The total number of enforcement cases ever since gpl-violations.org has started is certainly beyond 200 now.
Armijn is doing a great job in running the operations, as are other people who are actively contributing but not publicly visible.
I wanted to have at least an annual report on the site every year, but even that didn't happen either. It's pretty depressing if you work 12-14 hours a day, don't take weekends off, not even christmas, and still every day you never find even remotely enough time for all the things you want to do.
Let's see if I can get that report together, but if it will happen, it will probably not happen anytime soon, sorry.
Posted Feb 2, 2012 0:31 UTC (Thu)
by josh (subscriber, #17465)
[Link]
Posted Feb 2, 2012 0:32 UTC (Thu)
by josh (subscriber, #17465)
[Link]
Posted Feb 1, 2012 20:32 UTC (Wed)
by armijn (subscriber, #3653)
[Link] (2 responses)
Posted Feb 1, 2012 21:42 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Posted Feb 1, 2012 22:34 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
Posted Feb 2, 2012 4:03 UTC (Thu)
by rahvin (guest, #16953)
[Link] (1 responses)
I'm curious if Tim is correct in his assertion that there is this huge difference in how the two organizations work and what they demand for cure.
Posted Feb 2, 2012 10:21 UTC (Thu)
by jospoortvliet (guest, #33164)
[Link]
Posted Feb 1, 2012 19:47 UTC (Wed)
by scottt (guest, #5028)
[Link]
Posted Feb 2, 2012 5:05 UTC (Thu)
by martin.langhoff (subscriber, #61417)
[Link] (6 responses)
Now there are two possible angles -- one is whether it is moral or ethical, and I see most of the discussion here trying to sort that out.
The second one -- which I think is more important -- is whether it works, whether it is sustainable long term. If the codebase is good enough, and the license acceptable to a userbase that is ready to improve it -- you are in business. OEMs can be such a userbase.
A BSD-licensed project that moves forward at a steady pace can be very successful. The license doesn't enforce the give-back, but the steady pace can make it painful to maintain a fork, so the incentive to contribute back exists.
Vendors do unspeakable things with Apache, and yet Apache has not withered. As long as the project keeps momentum, anyone who's too forked has to pay a heavy price of rebase / merge. That eventually drives them to upstream or at least modularize to reduce the pain.
Perhaps, with the popularity of Linux on small embedded devices, it's likely that a small BSD-licensed userland for Linux will take hold.
In the end, it is not the "morally correct license" that wins. This isn't a fable. Instead, good software + a core group of develipers that drives a constructive dynamic, cares about its ecosystem (end users, OEMs, distros) and keeps the pace are the key components for a sustainable and successful project.
IMHO
Posted Feb 3, 2012 9:46 UTC (Fri)
by cas (guest, #52554)
[Link] (4 responses)
There is simply no incentive in that context to even maintain their own forks, let alone submit changes upstream.
BTW, your pragmatic angle is only important in the very short term, and even then only in a very narrowly-focused oblivious-to-the-real-world way. It's not even true pragmatism, because it's only a short-term benefit for a long-term loss.
No, it is the moral and ethical issues which are truly important.
They're not a reason to prohibit development of a BSD-style licensed alternative (an absurd suggestion anyway - even if anyone wanted to, no-one has the power). But they are a reason to boycott contributing anything to the project.
One of the reasons why manufacturers dislike the GPL is that the license effectively allows users to extend the lifespan of the "disposable" products they buy, and even re-purpose them. e.g. without the GPL, cyanogenmod wouldn't have recent versions of android running on 4,5,+ year old phones. The GPL gives rights - and options and possibilities and even capabilities - to the end-users...a fact that BSD-advocates either won't/can't see or refuse to place any value on.
This, naturally, conflicts with the gadget-fetishism, the obsession with the new and shiny, the must-have-it-now consumerist impulse that manufacturers want us to have.
Also, and just as importantly, as an occasional consumer of tech. products, I don't want a BSD-licensed userland on devices I purchase, because the BSD license does *nothing* to ensure that the product I buy is actually mine - under my control as well as in my possession. Apple has demonstrated well enough that the BSD license serves the interests of manufacturers and their corporate partners, rather than my interests.
As a user, the GPL is my friend. it gives me rights to the software I use.
as a developer and contributor to FOSS projects, the GPL is also my friend - it ensures that my work, my donation of time and effort and skill will always be available.
Posted Feb 4, 2012 18:33 UTC (Sat)
by alankila (guest, #47141)
[Link] (3 responses)
Posted Feb 4, 2012 18:41 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Feb 5, 2012 3:32 UTC (Sun)
by Fowl (subscriber, #65667)
[Link] (1 responses)
Without kernel source it would 'just' be harder and certain features wouldn't be possible. Look at what the Widows Mobile modding community achieved with no source, for anything.
Posted Feb 5, 2012 3:41 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link]
Posted Feb 4, 2012 4:42 UTC (Sat)
by foom (subscriber, #14868)
[Link]
A couple weeks ago I wanted to use an LDAP authorization feature (nested group membership). After some investigation and surprise, I found that that feature had been committed to the svn trunk in 2007, but has not yet made it into a release. Why? Because there haven't been any new major versions released since 2.2 was released in 2005, 7 years ago! Yikes! (But, I see 2.4 is expected to be released real soon now.)
The glacial speed of releases probably has nothing to do with licenses, but I would guess that anyone who has forked Apache into a proprietary variant has most likely had no trouble keeping up with the rate of change...so you might want to find a new example to hold up. :)
Posted Feb 2, 2012 15:53 UTC (Thu)
by spaetz (guest, #32870)
[Link] (1 responses)
Posted Feb 2, 2012 16:44 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Posted Feb 2, 2012 18:55 UTC (Thu)
by tbird20d (subscriber, #1901)
[Link] (9 responses)
Please see: http://elinux.org/Busybox_replacement_project#FAQ
Posted Feb 2, 2012 19:07 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (8 responses)
You are wrong about this. What you are doing is pushing the kernel developers to use SFC instead of using busybox as a proxy
https://lwn.net/Articles/479010/
"I'll be assigning the rights to the SFC to enforce all copyrights that I personally hold in the Linux kernel and any other project they ask me about. "
Even BSD license has a copyright attribution requirement. Enforcing that vigorously would cause enough pain if a vendor hasn't thought about compliance before.
Posted Feb 2, 2012 20:22 UTC (Thu)
by dwmw2 (subscriber, #2063)
[Link] (7 responses)
There is a cost involved in ensuring compliance for every single product, and with the best of will companies do often get it wrong. A lot of us have violated the GPL at times, quite unintentionally. It's easily done.
The fact of the matter is, it is only busybox which is actively defending its copyright these days. By replacing busybox, they dramatically reduce the risk of sanctions when they fail to comply with the licence.
It doesn't mean that they're intending to break the law; they're just taking the natural step to reduce their risk.
The approach does seem to be based on the idea that only busybox actually holds manufacturers to account, so it's only busybox that they need to replace in order to be able to violate the licences safely.
Even if you don't attribute malice, and you believe there's no plan to intentionally violate the licence of other projects that don't defend themselves, it does seem very cynical.
It's also naïve, because it is effectively a call for copyright-holders in other projects, especially the Linux kernel, to wake up and start to stand up for themselves rather than letting others do it for them.
Posted Feb 3, 2012 4:26 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
Posted Feb 3, 2012 5:26 UTC (Fri)
by dlang (guest, #313)
[Link]
Posted Feb 3, 2012 12:23 UTC (Fri)
by thumperward (guest, #34368)
[Link] (4 responses)
* Risk of shipping violating code
Given that BusyBox is rarely modified to any real extent by the vendors in question, the first risk is only mitigated to the extent of a megabyte of code which probably hasn't been modified anyway. This endeavour is very much intended to counter the second risk. In reality, vendors will still violate the license for software they're shipping, but it will be more difficult to address that because the simplest vector for compliance has been removed.
This is a very pragmatic choice. It is the polar opposite of an ethical one.
Chris
Posted Feb 10, 2012 18:20 UTC (Fri)
by landley (guest, #6789)
[Link] (3 responses)
I personally started the busybox lawsuits. Erik Andersen had a "hall of shame" page during his 7 years of maintainership but, didn't do anything about it. He had his father send out cease and desist letters, but if they were ignored didn't follow up.
Erik did team up with Bradley Kuhn and Eben Moglen and so on to threaten to sue linksys circa 2003, although I believe _they_ approached _him_. (And possibly Harald Welte as well, I'd have to look it up; it was before I got involved.) That action was carefully targetted and gave us openwrt and derivatives. It also caused Linksys to cease all Linux development and migrate its devices to a proprietary embedded OS for several years, but this was considered worthwhile as part of a larger overall outcome. The "embedded home router niche" hadn't _existed_ before Linksys, and now it was a ground-breakingly cheap deployment platform for open source software.
But guess what? The team of people who were _threatening_ to sue Cisco over the GPL back in 2003? They didn't actually file suit:
http://www.forbes.com/2003/10/14/cz_dl_1014linksys.html
All the work was done _out_ of court, and Cisco cooperated to _keep_ themselves out of court. The threat of a GPL lawsuit was just saber rattling to get Cisco's attention, they negotiated the release of source code _without_ever_filing_suit_.
I decided to experiment with filing actual suits to deal with the "Hall of Shame" I inherited from Erik Andersen when I took over as busybox maintainer. There was an existing, specific backlog of reports, which we expected to yield busybox code we could add to the repository. I asked Erik to cosign because he'd collected the hall of shame and what records there were consisted of his inbox, and the versions in question predated my maintainership and often my participation in busybox development. But Erik spent years not doing it, and setting the wheels in motion for it was one of my first acts as maintainer.
The 2003 Cisco effort, settled out of court without ever filing suit and yielding a mountain of useful code that opened up a new ecological niche to Linux, was nothing _like_ the current round of "sue first, ask questions later, and demand tens of thousands of dollars in legal fees and a commitment to keep paying protection money on every new product for years afterwards" the SFLC and SFC efforts have devolved into.
I'm now obsoleting the busybox lawsuits not _just_ because they drive companies away from Linux, but because nothing that's happened since 2006 has come even _close_ to openwrt. We got NOTHING OUT OF IT. All the open drivers for chips from nvidia and ati and broadcom and such we've gotten since then happened either because a company _chose_ to be nice (like Intel, hiring the xfree86 guys to push back against microsoft a bit), or because we _reverse_engineered_them_:
http://bcm-specs.sipsolutions.net/announcement.pdf
And so on. Sometimes Linux got support for hardware _FROM_ BSD:
http://madwifi-project.org/wiki/About/History
All this talk about lawsuits being necessary for hardware support does not match reality, and certainly was not the goal of the guy who started the suits (I.E. me).
I can show evidence that the "sue first and ask questions later" approach of stringing together a series of lawsuits to form a self-financing perpetual lawsuit machine that needs to be fed... that does way, way, way more harm than good. Because I started it, I consider stopping it (and thus ending that harm) to be my responsibility.
You're welcome to believe differently, but the facts do not support your position. I have first person experience here: you do not. You have presented no evidence in support of your position. I've asked for people to show me the code that came out of a busybox lawsuit and got merged, nobody has pointed at any. Instead they choose to weigh a purely theoretical benefit vs actual demonstrable harm.
In insulating your beliefs from challenge by facts, you are taking a position based on ideology, which does not match reality, and thus are a religious zealot, not an engineer. As with "eating meat on a friday" or "we only allow these sexual positions", it's easy to insist things are a sin a priori, because religious questions of morality do not actually require an underlying logic. Thus when logic fails, zealots start talking about morality without being able to show evidence of concrete harm to any specific persons.
(I can debate philosophy with you. But if you don't understand why I believe that we should put a teapot in orbit around Mars in honor of Bertrand Russell, you need to do some reading first.)
Rob
P.S. tl;dr - Bwahahahahahaha.
Posted Feb 10, 2012 18:45 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Availability of kernel source for consumer devices is important, and the uses its been put to are surprising. There are even communities of people who develop replacement firmware for TVs. We've seen what happens without active enforcement of the GPL - most vendors simply never supply their code. Enforcement is a necessary part of giving users the freedoms that the copyright holders intended, and those freedoms make a real difference.
Posted Feb 11, 2012 2:08 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
R300, R600 and R800 now have public documentation and open source drivers. There's a virtual SVGA driver that provides 3D acceleration to guests which is fully mainlined.
Then there's OpenSource Broadcom driver.
Basically, the only major 'bad' companies by now are NVidia and Imgtec (PowerVR developers).
Posted Feb 11, 2012 12:21 UTC (Sat)
by khim (subscriber, #9252)
[Link]
This is factually wrong. They actually did that. As you describe in other place this "cooperation" was in form "let's sweep it under the rug, continue with sweet talk and hope FSF will eventually go away". It didn't work: FSF is extremely patient, but this is more then compensated by it's perseverance. Yes. Once. And it was incomplete. And then Cisco issued new versions of both software and hardware - again with GPL violation. And as your admit when they started new "proper" effort they had no plans to do anything with old violations. Yes, but can you explain just why companies suddenly decided to be nice when they dragged their feet for years? And why are you so sure lawsuits have nothing to do with that? You may have started it, but your certainly don't have power to stop it. Simply because you don't own rights for a lot of GPLed code. As Kleiner said: It's difficult to see the picture when you're inside the frame. You can only talk about direct consequences of all that activity, but how can you claim that Broadcom's change of heart is not related to SFLC and SFC efforts? You are correct when you say Never think you're _irreplacable_. Nobody is. That's certainly true. And if your goal is to make software used by millions then these lawsuits may hurt. But Stallman's initial goal was completely different: the goal was to be able to hack on the software you "own", not to spread your own software as an act of goodwill. GPL was not a goal in itself, but means to this end: if someone uses your code then GPL guarantees that you get your own code back with appropriate changes! Clever hack - but it was broken by tivoization and by blatant ignorance of GPL conditions. Solution to tivoization is obvious: GPLv3. It makes sure that manufacturer can not forbid you to modify your own code. Solution to GPL violations are lawsuits. If manufacturer does not give you enough data to start hacking on your code then what's the point of the whole exercise? From this POV lawsuits are quite successful: a lot of companies published enough sources to make the whole classes of devices hackable. The fact that GPL stopped being the most popular license in the world is unfortunate side-effect, but alternative (GPL continues to be most popular license while manufacturers effectively treat it as BSD license) was clearly worse from FSF's POV. P.S. It's funny that you argue are so adamantly against SFC's efforts where the only "proven disaster" happened because of FSF. FSF certainly started it's efforts way, way before your involvement. In fact G++ story happened before busybox project was even started!
Posted Feb 3, 2012 3:08 UTC (Fri)
by bug1 (guest, #7097)
[Link] (1 responses)
If the GPL isnt enforced then there is an incentive to violate the license, reading, understanding and respecting the license does take time.
I believe a common tactic of violators was to
In particular the FSF used this softly softly approach and had trouble with repeat offenders.
There is a big cultural difference between corporations and Free software, corporations goal is to make money, if violating the license doesnt risk their profits then they have no reason to comply with the GPL.
Posted Feb 10, 2012 0:37 UTC (Fri)
by landley (guest, #6789)
[Link]
I consider GPLv3 yet another proprietary license. I'm sad GPLv3 undermined GPLv2 to the point it's no longer viable in a lot of contexts, but I got over it and moved on. I'm not the only one. GPL use is declining, and more active license enforcement will only make it decline faster.
(I like the Linux kernel, but busybox was ported to run on bare hardware with newlib+libgloss in 2006. Never think you're _irreplacable_. Nobody is.)
And yes, the guy who started license enforcement on BusyBox is saying that. It's what I learned from the experience. Are your positions based on experience, or on how you _want_ the world to behave?
Rob
(What I do worry about is laws that make modchipping an xbox illegal. Vendors lock game consoles down, people open them up to make unlicensed development workstations with aftermarket add-ons, and the _dangerous_ bit is rendering the aftermarket addons illegal. GPLv3 ain't gonna do that because the vendors can write their own kernel if they want to lock down their console, it just excludes our software from the relevant market. What we _need_ are laws making it explicitly legal for me to pick my own lock. These licensing tricks we're getting up in arms about are irrelevant: Linus explicitly allowed tivoization, and if minor developers start suing people over that _he_ might fork his own project enough rip out/rewrite your code, _and_ testify in the defense of whoever you're suing that his public statements on the matter _mean_ something. If they've got the "secure boot" lockdown and it's illegal for you to crack your own box, the rest is details.)
Posted May 31, 2012 20:06 UTC (Thu)
by shentino (guest, #76459)
[Link]
If people weren't so keen on trying to get away with it there wouldn't be such a problem in the first place.
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
rick@linuxmafia.com
A tempest in a toybox
A tempest in a toybox
http://liquidat.wordpress.com/2007/03/04/the-forcedeth-st...
A tempest in a toybox
I think getting the legal system all over code is bad for the code, and there's no real _difference_ between MPAA/RIAA/SOPA, decss and DVDCCA, crypto export regulations, software patents, or the FSF/SFLC/GPLv3.
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
It's not only "not hard", if you think about it (you ought to have a release process in place, no?) it's just plainly trivial to do so.
On the 'death penalty' thing
I've seen binary blobs in source repositories: there are quite few not so bright developers who download random stuff from the 'Net and put it there, because it's a lot easier than going through the company 3PP-inclusion process. Of course, they don't think about it if this ends up in the end product...
On the 'death penalty' thing
On the 'death penalty' thing
This just does not happen... or should not happen. In any case, if people commit *proprietary* stuff to the repository without due dilligence, the stakes are really higher.
Again, everyone should just act -- in the prep of a software-including product -- just as they would if free-licensed software pieces were proprietary-licensed software pieces: with due dilligence.
On the 'death penalty' thing
"The editor" has found it frustratingly difficult to get lawyers to say anything useful about subjects like this. It's unfortunate. There are, in fact, a lot of high-clue lawyers out there; they understand and support what we're doing. But the nature of their profession makes them unwilling to say much of anything interesting outside of the most private situations.
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
However, such work would probably be extremely cumbersome (esp. for a technically-oriented writer): so do not take that for a request. But I am curious if such survey is simply feasible - it seems few trials on the topic have been brought to an actual end. (That's not necessarily a bad thing, but in the meantime, endless discussion goes on.)
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
Wol
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
> immoral or not for companies to violate the GPL, this is *the* core
> question: can you demand things outside of your own direct copyright?
On the 'death penalty' thing
On the 'death penalty' thing
"If the sued companies don't see the terms as acceptable they can continue the court case, where the SFC would presumably ask for a payment or whatever the law allows them to ask for."
Indeed. It seems rather odd to complain that a settlement is unfair to them, and then to accept it anyway because it costs them less than the penalty that the court would have imposed for their crimes.
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
Wol
In the interest of clarity, it's worth repeating an important point here:
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
On the 'death penalty' thing
a license is not a contract
On the 'death penalty' thing
The owner of the copyright (whether licensed under GPL or proprietary) may or may not elect to give you a new license to distribute under whatever terms they decide. The violator either accepts those new terms, stops distributing it, or gets sued for copyright violation.
On the 'death penalty' thing
On the 'death penalty' thing
> license.
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
Seriously?
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
> allowed to work on, or what kind of license they should use".
See the thread here: http://lwn.net/Articles/478257/ .
He personally frowns upon the new project and its license, and is
discouraging anyone from helping.
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
I understand that GPL violators make people upset. They upset me as well. Sony is not involved in this project (other than that I work for Sony), so please take my Sony examples as explanatory only. I wanted to explain something that I haven't communicated very well.
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
Imagine if you were mayor of a town of 300,000 people, and you had to pay a million dollar fine if someone was caught stealing. You have implemented a set of policies to prevent stealing, and to encourage people not to steal. Could you guarantee that no one ever stole? As mayor, would you pay $1,000 for an insurance policy against the fine? That's similar to the cost/benefit calculus for this project, for large enterprises. It's not that executives are unwilling to enforce compliance, or are actively undermining the license of the code their company ships. They just want to reduce risk.
Logical, but I don't buy it.
Your argument is "We try our best, but we're worried that one mistake will cost us." That's easy to avoid. Put a link on your product page, "Open-source licenses and source code". Put another link on that page, "Contact us if you have any concerns". And then just respond to those concerns. Have someone actually answer those emails, someone who has the authority to actually do something about it. If there's a mistake, someone will point it out, you will address it, and you are done. If it takes a long time to address, put up a new webpage explaining all of the issues and how you're addressing them and why it's taking so long, and update it regularly. We are not stupid; we recognize a good-faith effort when we see one. That's how it usually works. The lawsuits and settlements and veto powers and product delays have always come after a company has failed to actually solve the problem.
Even the SFLC doesn't file lawsuits until they have to. In the announcement of the big Best Buy suit:
The First Rule of GPL Compliance: “Be Responsive When Contacted”
The SFLC has dealt with over a hundred compliance matters since its inception on behalf of various clients, including BusyBox and developers of significant portions of the GNU/Linux operating system. The vast majority of these matters usually end with violators voluntarily coming into compliance. In the rare cases when a company refuses to cooperate in good faith, the SFLC has been forced to take legal action on behalf of its clients to enforce FOSS requirements.
About the calculus for the project
About the calculus for the project
Put a link on your product page, "Open-source licenses and source code". Put another link on that page, "Contact us if you have any concerns". And then just respond to those concerns. Have someone actually answer those emails, someone who has the authority to actually do something about it.
The e-mail address is: tim dot bird at am dot sony dot com.
That's me.
The lawsuits and settlements and veto powers and product delays have always come after a company has failed to actually solve the problem.
two words: onus probandi
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
Nothing like publicly calling someone a liar.
About the calculus for the project
Looks like this is about definitions...
About the calculus for the project
I don't think I recall even a single case where a company has openly admitted to their mistake, *responded* and made a good-faith effort to rectify the problem, yet nevertheless ended up in court.
About the calculus for the project
About the calculus for the project
I don't think I recall even a single case where a company has openly admitted to their mistake, *responded* and made a good-faith effort to rectify the problem, yet nevertheless ended up in court.
The guys in taiwan had monkey-patched the old broadcom build system into a horrible mess, all the package versions were 5 years old, and…
But by all means, consider the FSF's actions _useful_. After all, the end result was that all the guys working on getting vanilla Linux working well on the WRT610n were transferred off of Linux development to do Windows and IOS...
About the calculus for the project
http://hg.suckless.org/sbase/
About the calculus for the project
Context: the iPhone is running a bsd derivative already, and it didn't take apple all that long to switch from MacOS 9 to MacOS X
and that was porting the whole of MacOS userspace on top of it, _and_ there was a crazy divergence onto microkernels with mach they had to back out again
Remember how Darwin is technically OpenDarwin?
The amount of engineering effort Google's already devoted to the Android kernel would let it fork a BSD kernel (net, open, free, dragonfly, darwin, doesn't really matter which), port all their new driver stuff to it, and get it reasonably working with their userspace in about 18 months.
Keep in mind, all _they_ want to do is run dalvik. Most of the stuff that Linux _has_, from massive SMP scalability through I/O elevators to container support... isn't really used on Android phones.
Intellectual exercise: what would it take to port Linux 0.0.1 to android hardware? (Linus wrote that in 3 months, as a student. And when he started he didn't know how.)
Now what would it take to extend that to where it could run Dalvik, drive an LCD touchscreen, a speaker and microphone, talk to the flash hardware, and control a dozen GPIO pins for buttons and LEDs and such?
I'd say the android guys clearly _could_ replace the Linux kernel, if pushed.
You rattle sabers all you want, use them for leverage and negotiation. But stabbing somebody with them is an act of war.
Flinging lawsuits around on a regular basis like the SFLC is doing means you're a rogue state, and must be dealt with.
Everybody's flipping out about toybox but totally ignorant of the other projects out there also working on this:
It's like antibotic resistance: use your "defense" stupidly and aggressively enough for long enough and the ecosystem adapts to render it irreelvant.
If it wasn't for the GPL aspect, wouldn't the busybox lawsuit factory be lumped in with the patent trolls and the BSA?
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
if you load the full series of comments and search for 'illegal' you will see it being introduced.
About the calculus for the project
> problem so far. Then later Tim comes along and convinces Rob to change the
> license citing SFC as the reason.
About the calculus for the project
About the calculus for the project
after all, what's linux but a project to let people have a unix-like system without complying with the proprietary licenses of the commercial unix systems?
what's openoffice but a project to let people have an alternative to microsoft office without complying with the proprietary licenses that microsoft sells?
if you go hunting for it, every opensource project can be framed in a way as to be encouraging people to avoid complying with some commercial license (the free as in beer part of freedom), and this is frequently touted as a significant reason for the open software existing by the project itself (not just a third party talking about the project like in the case of toybox)
About the calculus for the project
About the calculus for the project
so if toybox can run on BSD it's legal
but if it only runs on linux it's a circumvention tool and illegal
About the calculus for the project
>
> Oh no. To make it run on BSD is only a first step. Then you need to
> convince people to actually use it in such configuration :-)
>
> If BSD port will just be a curiosity then court will [rightfully] say
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
> this project is "to make it easier to infringe the kernel's
> license." This is simply not true."
About the calculus for the project
About the calculus for the project
About the calculus for the project
> skips mandatory legal checks in order to be first to market.
...
> Note: this has nothing to do with the GPL. It's about software licensing
> and legal reviews *in general*.
About the calculus for the project
About the calculus for the project
About the calculus for the project
Ultimately, what galls me here is that Sony isn't ponying up the developers to actually write the bits of Toybox that they want
About the calculus for the project
Except that, as Tim said before, replacing Busybox is not (at this time) a Sony project. Tim has said this would be a good idea, not Sony. Most of us like to be seen independently of the shadow of our employers, at least some of the time; I think we can grant Tim that favor too.
About the calculus for the project
About the calculus for the project
About the calculus for the project
http://lists.uclibc.org/pipermail/uclibc/2006-July/016032...
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
2. We know that dodgy contractors in general tend to have a strong taste for busybox.
3. Unlike other violations, busybox violations tend to be noticed by people (more thorough than us) and they often have consequences.
Wrong anology
Think of a prepared food producer trying to introduce stricter farming regulations - even when not doing any farming itself (except this one is of course more likely to be moral).
Not moral but perfectly logical.
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
business
business
business
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
So the real problem is FUD?
So the real problem is FUD?
So the real problem is FUD?
So the real problem is FUD?
Note that this clause is triggered only if copyright holder notifies you. If someone else finds out you are using GPLv3 product incorrectly (something like casual "I see you are offering special version of GCC in your SDK, but I don't see neither source nor a way to request said sources") and you react accordingly ("Oh, you know, we just forgot to upload them, can you wait a few days?") then license is reinstated without any strings attached. You can make mistakes as many times as you want till the actual copyright notifies you of the violation by some reasonable means.
So the real problem is FUD?
About the calculus for the project
About the calculus for the project
Did I get that right?
About the calculus for the project
I don't think they'll come after Sony. This seems to keep coming up, so I've addressed it in the FAQ for the proposal.
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
Very few business would be comfortable with all of their hard work feeding in a one-way direction to their largest competitor.
About the calculus for the project
...
> In reality writing Toybox seems more doable than changing some written-in-stone legal policies.
About the calculus for the project
either you're violating the license of Linux, or your company's legal department is already fine with following the GPL
This is not a correct dichotomy. Many companies are fine following the industry consensus interpretation of the GPL, but have difficulty with the interpretation of the GPL by the busybox litigators.
About the calculus for the project
About the calculus for the project
You make a big fuss to make sure everyone knows that you got your own lawnmower
No. I didn't announce this project, Matthew Garret did, for his own purposes. He incorrectly attributed the motivation for this to my employer, which I felt needed correcting. People's own biases have led to a lot of name-calling and fingerpointing and outrage. I'm not trying to rub anyone's face in anything. I've tried to explain my own motivations, and I've been called a liar numerous times.
About the calculus for the project
About the calculus for the project
About the calculus for the project
you may want to actually go look at toybox and it's creator (Rob Landley, a former maintainer of Busybox, and one of the plaintifs in many of the SFLC busybox lawsuits)
Since toybox was a GPLv2 project for several years, it couldn't have been created to make it easy to bypass the GPL.
1. That future lawsuits will probably not bring new enhancements for busybox.
2. It's not simple to comply with busybox's license. It's trivial.About the calculus for the project
About the calculus for the project
you can't have it both ways.
> I have no problems with Rob's work.
> what that project under discussion is doing is most probably flat out illegal.
but you are talking about exactly the same project, Rob's toybox project.
About the calculus for the project
About the calculus for the project
I'm going to eradicate the context:
It generally turns out, as I know from having spent almost a quarter of a century now as a lawyer for hackers, that when hackers pretend to be lawyers, there are certain predictable formulations that they come to; they assume a degree of consistence in legal rules that is not achievable; this is a primary problem which occurs particularly in US focused conversation, such is that in Debian Legal, where the libertarian demand for intellectual consistency, and the hacker belief that laws are form of code that are executed without errors or ambiguities, joins together to create a particular frame of analysis for legal questions.
It doesn't work very well for me as a lawyer, I think it doesn't work very well for lawyers elsewhere in the World, because the one thing which lawyers around the world all share is an awareness of the squishiness of law, it is by no means the hard arthropod carapace for internal soft organs that non-lawyers have a tendency to assume it is....If licenses are being violated on some piece of software, then let those who have the authority sue if they choose to.
If the kernel people do not feel like suing, then it does seem questionable to me that busybox people feel like they have the right to impose settlement conditions on the kernel because of violations on busybox.
Secondly, GPL does not have so much leverage as it once seemed to: there appears to be not-GPL replacements for most if not all the pieces of the system software stack today.
In the end, if all GPL-licensed software becomes replaced then the legal theory you are advancing will fail too, because there is no GPL-licensed software left whose license could be violated.
About the calculus for the project
About the calculus for the project
Q. Is this being done to prevent the SFC from asking for the source to the Linux kernel?
A. No, although it would have that effect. As part of their request to remedy a busybox GPL violation, the SFC does ask for source code unrelated to busybox. Personally, I believe this is improper. However, my main reason for proposing this project is to avoid having the SFC gain review authority over unrelated products produced by a company. The larger the set of Linux-based products that are produced by a company, the greater exposure there is for a possible mistake, and the greater potential costs that would incur in the event of litigation and/or settlement.
Of course he also continues with rhetoric that his goal is not to help copyright violators, etc, but... how much it helped other companies you've mentioned here?About the calculus for the project
> Android's "bionic" project instead, and maybe even their "toolbox"
> project. The first is their libc (uClibc replacement) and the second is
> their coreutils (busybox replacement). They wrote their own because they
> decided they want all the userspace stuff to be BSD licensed, no GPL in
> userspace. Before GPLv3 came out I would have objected to this, but now
> it seems kind of reasonable. (If the FSF is really _that_crazy_, then
> you don't want to get any of it on you.)
If this is all about Android then why the page was started with talks about GPL infringement facilitation? It still talks about this aspect first and about potential usage in Android second.About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
Wol
About the calculus for the project
Actually, that's not fair on Titanic ...
She had FAR more lifeboats than were legally required.And could have saved a lot more people, if they hadn't messed up evacuating the boat. Plus a load of people didn't want to get on the lifeboats because they felt safer staying on board (pretty much the same as happened in the recent cruise-ship sinking in Italy ...)
I think the law nowadays says you need enough spaces on EACH SIDE of the boat for the entire passenger/crew complement - ie 2 spaces per person. Most boats carry even more. It makes sense, actually, if the boat is listing you can lose half your usable lifeboat capacity in the space of seconds.
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
I personally do hope that people would not find this argument reasonable way to think about licenses, because in general case any piece of software that happens to eliminate another piece of GPL software could be argued to help facilitate GPL infringement on the remaining software.
But as you point out, law is essentially insane and random, and stranger things could happen. My personal feeling, however, is that this is not fair nor right, whatever the courts might find.
About the calculus for the project
Not only you should show that someone picked your piece of software because it's under BSD license (that's understandable: less rules to follow), …
About the calculus for the project
About the calculus for the project
About the calculus for the project
You're claiming that my new project might be considered an infringement facilitator AGAINST MY OLD PROJECT, and that stopping the lawsuits I _started_ might somehow legally do... something?
Your honestly believe that the legal system can and should forbid people from doing new things that compete with (and obsolete) their own previous work?
And you take this position in defense of "freedom", as defined by the FSF?
I ask seriously: are you crazy? Do you need some kind of diagnosis and treatment?
About the calculus for the project
> forbid people from doing new things that compete with their own previous
> work.
About the calculus for the project
http://en.wikipedia.org/wiki/Traitorous_eight
Honestly, if you work in the industry you get to know this stuff...Oratroll is suing over patents
About the calculus for the project
> Napster-style copyright infringement facilitator.
http://www.fool.com/portfolios/rulemaker/2000/rulemaker00...
http://www.fool.com/portfolios/rulemaker/2000/rulemaker00...
http://www.fool.com/portfolios/rulemaker/2000/rulemaker00...
http://www.fool.com/portfolios/rulemaker/2000/rulemaker00...
About the calculus for the project
> 1. That future lawsuits will probably not bring new enhancements for
> busybox.
http://lists.busybox.net/pipermail/busybox/2011-November/...
http://lists.busybox.net/pipermail/busybox/2011-November/...
About the calculus for the project
As you say, they are lax. Neither gplviolations.org nor the kernel community have ever taken anyone to a US court.
Uh, that would be because gpl-violations.org operates in Germany. Harald Welte is a kernel hacker, so members of the kernel community certainly have taken people to court -- just not US court.
About the calculus for the project
> reason for Toybox, and its creation is in no way related to the fact that
> the SFLC will sue you when nobody else will.
About the calculus for the project
About the calculus for the project
About the calculus for the project
"Some people have said that what the SFC requests in remedies is not that costly, but I can assure you that large corporations see it very differently. Matthew, in particular, keeps asserting that the real reason for this project is "to make it easier to infringe the kernel's license." This is simply not true."
You both characterise the motivation with dramatically different words. But if we analyse it carefully, you seem to be saying the same thing. I'll try for a more neutral rendition:
About the calculus for the project
Most definitely. A standard agreement along these lines (and I've signed them for Harald in the past too) would grant authority to act on your behalf, on a temporary basis that you can terminate at any time; perhaps with a reasonable notice period.
About the calculus for the project
About the calculus for the project
"Imagine if you were mayor of a town of 300,000 people, and you had to pay a million dollar fine if someone was caught stealing. You have implemented a set of policies to prevent stealing, and to encourage people not to steal. Could you guarantee that no one ever stole? As mayor, would you pay $1,000 for an insurance policy against the fine? That's similar to the cost/benefit calculus for this project, for large enterprises. It's not that executives are unwilling to enforce compliance, or are actively undermining the license of the code their company ships. They just want to reduce risk."
This makes perfect sense to me (ignoring the scale of the numbers). But the analogy is slightly incomplete. In fact there is only one shopkeeper who is making complaints about the theft, and who is causing you to pay those fines. And your insurance policy only covers that one shopkeeper.About the calculus for the project
"Someone else is just going to call the police instead. It's a PITA for them and it distracts them from the shopkeeping that they prefer to do — but if their friend can't do it any more, they'll just have to do it themselves.
Of course, the mayor might realise this; he's not silly. So he might deliberately set about trying to discourage the other shopkeepers from calling the police.
you forgot about gpl-violations
Harald has been busy with other things and doesn't seem to be doing much with gpl-violations.org. That effort has since slowed considerably. They have done some good work with the AVM v. Cybits case, but that is the only news posted on their site since 2008. Undoubtedly there is behind-the-scenes work going on, but a lot of the initiative seems to have moved to the SFC.
you forgot about gpl-violations
you forgot about gpl-violations
Is there any way you can put out some information on what you've been doing, at least in statistical form? There is a fairly widespread perception that, for example, nobody is really doing enforcement in the kernel space at the moment. Making people more aware of what is going on might help to ease some concerns in that area.
you forgot about gpl-violations
you forgot about gpl-violations
you forgot about gpl-violations
you forgot about gpl-violations
you forgot about gpl-violations
you forgot about gpl-violations
you forgot about gpl-violations
you forgot about gpl-violations
you forgot about gpl-violations
you forgot about gpl-violations
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
A tempest in a toybox
FAQ for project proposal just added to wiki
FAQ for project proposal just added to wiki
A. No, although it would have that effect."
If they think it would have that effect, then the reimplementation does make a certain amount of sense.FAQ for project proposal just added to wiki
FAQ for project proposal just added to wiki
FAQ for project proposal just added to wiki
Two different "risks" here
* Risk of being sued for shipping violating code
Two different "risks" here
http://liquidat.wordpress.com/2007/03/04/the-forcedeth-st...
http://r300.sourceforge.net/
http://nouveau.freedesktop.org/wiki/
Two different "risks" here
Two different "risks" here
Two different "risks" here
But guess what? The team of people who were _threatening_ to sue Cisco over the GPL back in 2003? They didn't actually file suit:
http://www.forbes.com/2003/10/14/cz_dl_1014linksys.htmlAll the work was done _out_ of court, and Cisco cooperated to _keep_ themselves out of court.
The threat of a GPL lawsuit was just saber rattling to get Cisco's attention, they negotiated the release of source code _without_ever_filing_suit_.
All the open drivers for chips from nvidia and ati and broadcom and such we've gotten since then happened either because a company _chose_ to be nice (like Intel, hiring the xfree86 guys to push back against microsoft a bit), or because we _reverse_engineered_them_.
All this talk about lawsuits being necessary for hardware support does not match reality, and certainly was not the goal of the guy who started the suits (I.E. me).
I have first person experience here: you do not.
Level Playing Field
- Ignore license
- Lock down device to make it hard to get caught
- If caught claim ignorance
- Wait for the Free Software community to expend time and resource explaining to them nicely what they should have done. (saving the company money)
- Drag feet
- Comply
- Repeat with next product
Level Playing Field
A tempest in a toybox