About the calculus for the project [LWN.net]

About the calculus for the project

Posted Feb 1, 2012 20:12 UTC (Wed) by ovitters (guest, #27950) [Link]

SFC is doing far less than what they could do.

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.

About the calculus for the project

Posted Feb 1, 2012 21:39 UTC (Wed) by jimparis (guest, #38647) [Link] (33 responses)

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

Posted Feb 1, 2012 21:49 UTC (Wed) by raven667 (subscriber, #5198) [Link]

> We are not stupid; we recognize a good-faith effort when we see one

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.

About the calculus for the project

Posted Feb 1, 2012 23:39 UTC (Wed) by tbird20d (subscriber, #1901) [Link] (31 responses)

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 site address is: http://www.sony.net/Products/Linux/common/search.html
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.

So say you.

About the calculus for the project

Posted Feb 2, 2012 0:30 UTC (Thu) by jubal (subscriber, #67202) [Link]

two words: onus probandi

About the calculus for the project

Posted Feb 2, 2012 0:38 UTC (Thu) by mitchskin (subscriber, #32405) [Link]

> So say you.

I haven't seen you give a specific example that contradicts what he said.

About the calculus for the project

Posted Feb 2, 2012 3:33 UTC (Thu) by rahvin (guest, #16953) [Link] (28 responses)

>So say you.

Nothing like publicly calling someone a liar.

About the calculus for the project

Posted Feb 2, 2012 4:24 UTC (Thu) by tbird20d (subscriber, #1901) [Link] (27 responses)

Nothing like publicly calling someone a liar.

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.

About the calculus for the project

Posted Feb 2, 2012 7:47 UTC (Thu) by ekj (guest, #1524) [Link] (26 responses)

It's not -guaranteed- if you violate the license, even accidentally, there's no *guarantee* that you won't run into a hostile and agressive litigant.

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.

About the calculus for the project

Posted Feb 2, 2012 10:03 UTC (Thu) by khim (subscriber, #9252) [Link] (25 responses)

Looks like this is about definitions...

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.

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.

About the calculus for the project

Posted Feb 9, 2012 21:26 UTC (Thu) by landley (guest, #6789) [Link] (24 responses)

Actually Cisco outsourced the old linksys Linux stuff to a taiwanese company after the first lawsuit, washed their hands of Linux, and switched the Linksys router line to using some other embedded OS. (PNX? I forget.)

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

About the calculus for the project

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:

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.

because

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 still had no plans to ever produce sources for the devices they continued to ship.

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...

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.

About the calculus for the project

Posted Feb 10, 2012 1:56 UTC (Fri) by landley (guest, #6789) [Link] (20 responses)

I've never been a kernel developer. I've patched it occasionally, but it's never been something I write new chunks of for fun. So _I_ don't personally plan to do anything there.

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/
http://hg.suckless.org/sbase/

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.

About the calculus for the project

Posted Feb 10, 2012 9:47 UTC (Fri) by khim (subscriber, #9252) [Link] (19 responses)

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

Yup. Measly ten years (NextStep was bought in 1996 and MacOS Classic was abandoned in 2006).

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

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).

Remember how Darwin is technically OpenDarwin?

That's prehistory - and another ten years of development (from about 1985 to 1996).

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.

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).

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.

...today. But with 8-cores on the horizon and other similar development it may become important before long.

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.)

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.

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?

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.

I'd say the android guys clearly _could_ replace the Linux kernel, if pushed.

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).

You rattle sabers all you want, use them for leverage and negotiation. But stabbing somebody with them is an act of war.

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?

Flinging lawsuits around on a regular basis like the SFLC is doing means you're a rogue state, and must be dealt with.

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.

Everybody's flipping out about toybox but totally ignorant of the other projects out there also working on this:

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.

It's like antibotic resistance: use your "defense" stupidly and aggressively enough for long enough and the ecosystem adapts to render it irreelvant.

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 it wasn't for the GPL aspect, wouldn't the busybox lawsuit factory be lumped in with the patent trolls and the BSA?

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.

About the calculus for the project

Posted Feb 10, 2012 16:05 UTC (Fri) by landley (guest, #6789) [Link]

> Perhaps. That's why I asked what you plan to do to replace Linux kernel.

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

About the calculus for the project

Posted Feb 10, 2012 18:32 UTC (Fri) by dlang (guest, #313) [Link] (17 responses)

be very careful about your argument that a project may be illegal if it exists to let people avoid complying with the license for some other application.

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)

About the calculus for the project

Posted Feb 10, 2012 18:50 UTC (Fri) by raven667 (subscriber, #5198) [Link] (6 responses)

> 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)

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.

About the calculus for the project

Posted Feb 10, 2012 19:03 UTC (Fri) by dlang (guest, #313) [Link] (5 responses)

I think it makes as much sense as the argument that it's illegal for Rob to write toybox under a BSD license because it allows people to avoid complying with the GPLv2 because toybox can be used to replace the Busybox code that Rob also wrote.

I think that both arguments are nonsense, but if you believe in one, the other comes along as baggage.

About the calculus for the project

Posted Feb 10, 2012 19:27 UTC (Fri) by jake (editor, #205) [Link] (3 responses)

> argument that it's illegal for Rob to write toybox under a BSD license

and who on earth has made this argument? not liking him doing so is hardly a claim that it's "illegal" ...

jake

About the calculus for the project

Posted Feb 10, 2012 19:37 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

there are posts in this topic claiming that toybox is illegal code on the basis that it is being written to contribute to copyright infringement. Raven667 is one of the people making this argument and is using the example of napster as justification.

if you load the full series of comments and search for 'illegal' you will see it being introduced.

About the calculus for the project

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

if you load the full series of comments and search for 'illegal' you will see it being introduced.

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.

About the calculus for the project

Posted Feb 11, 2012 22:30 UTC (Sat) by landley (guest, #6789) [Link]

> 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.

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.

About the calculus for the project

Posted Feb 10, 2012 19:33 UTC (Fri) by raven667 (subscriber, #5198) [Link]

The argument is that this does not happen in a vacuum, context matters and that this might be argued to be similar to the Napster case. I'm pretty doubtful that either a lawsuit or this interpretation of the situation will ever be realized. In any event I objected to the ridiculous straw man arguments chosen in favor of just arguing on-point since you clearly do understand what was intended.

About the calculus for the project

Posted Feb 10, 2012 19:49 UTC (Fri) by khim (subscriber, #9252) [Link] (9 responses)

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?

… 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.

what's openoffice but a project to let people have an alternative to microsoft office without complying with the proprietary licenses that microsoft sells?

… and without use of any proprietary code at all. Important milestone was reached when openoffice was freed from all binary blobs.

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)

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.

About the calculus for the project

Posted Feb 10, 2012 20:09 UTC (Fri) by dlang (guest, #313) [Link] (8 responses)

so if toybox can run on BSD it's legal, but if it only runs on linux it's a circumvention tool and illegal

suuuuure.....

About the calculus for the project

Posted Feb 10, 2012 20:26 UTC (Fri) by khim (subscriber, #9252) [Link] (7 responses)

so if toybox can run on BSD it's legal

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.

but if it only runs on linux it's a circumvention tool and illegal

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.

About the calculus for the project

Posted Feb 12, 2012 16:55 UTC (Sun) by landley (guest, #6789) [Link]

> > so if toybox can run on BSD it's legal
>
> 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

*plonk*

Rob

P.S. http://lmgtfy.com/?q=plonk+usenet

About the calculus for the project

Posted Feb 12, 2012 18:59 UTC (Sun) by armijn (subscriber, #3653) [Link] (3 responses)

So reimplementing standard UNIX commands under a BSD license if they only run on Linux is illegal? You lost me.

About the calculus for the project

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.

About the calculus for the project

Posted Feb 13, 2012 8:18 UTC (Mon) by bronson (guest, #4806) [Link]

> If it's goal is to conceal an infringement - then it's illegal.

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.

About the calculus for the project

Posted Feb 13, 2012 22:15 UTC (Mon) by docwhat (guest, #40373) [Link]

Huh? Your legal theory is pretty out there. Do you have anything to back this up? Anything at all?

About the calculus for the project

Posted Feb 12, 2012 22:57 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

claiming that software is illegal based on how some people (who aren't the authors of the software) choose to use it is a very dangerous thing to do.

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.

About the calculus for the project

Posted Feb 13, 2012 0:05 UTC (Mon) by dlang (guest, #313) [Link]

this topic has now made it's way onto a very select list, the list of free software / open source related lawsuits that I would like to see happen on the basis that the people making the claim are doing enough harm with their FUD that a lawsuit to set a precedent would be a good thing.

About the calculus for the project

Posted Feb 9, 2012 22:42 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> the goal of getting the most people to use the best software

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.

About the calculus for the 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.

About the calculus for the project

Posted Feb 1, 2012 21:47 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

"I believe eliminating the possibility of a license violation is a valid, although not ideal, solution. "

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.

About the calculus for the project

Posted Feb 2, 2012 8:54 UTC (Thu) by fb (guest, #53265) [Link]

> 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.

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?

About the calculus for the project

Posted Feb 1, 2012 22:19 UTC (Wed) by jonasj (guest, #44344) [Link] (1 responses)

> 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 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?

About the calculus for the project

Posted Feb 1, 2012 22:28 UTC (Wed) by jonasj (guest, #44344) [Link]

Sorry to reply to myself but I feel I need to point out that I wouldn't be posting such a comment if it wasn't for the fact that your argument relies on your lack of trust in the SFC not to misbehave, which I just find incredibly hypocritical considering the organisation you're working for.

About the calculus for the project

Posted Feb 1, 2012 22:44 UTC (Wed) by marcH (subscriber, #57642) [Link] (2 responses)

> 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.

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*.

About the calculus for the project

Posted Feb 9, 2012 21:35 UTC (Thu) by landley (guest, #6789) [Link] (1 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.
...
> Note: this has nothing to do with the GPL. It's about software licensing
> and legal reviews *in general*.

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

About the calculus for the project

Posted Feb 12, 2012 15:35 UTC (Sun) by nix (subscriber, #2304) [Link]

Quite. Nobody ever looks up patents. Every large software company I have ever worked for specifically forbids its developers from doing patent searches without the cooperation of the corporation's top lawyer, which says something about how common they expect such things to be. (From asking a few such people, the number of patent searches they actually get asked to do by software developers is one or two a *year*. In large multinationals.)

About the calculus for the project

Posted Feb 1, 2012 23:39 UTC (Wed) by PaulWay (guest, #45600) [Link] (5 responses)

> 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.

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

About the calculus for the project

Posted Feb 1, 2012 23:49 UTC (Wed) by tbird20d (subscriber, #1901) [Link] (4 responses)

Ultimately, what galls me here is that Sony isn't ponying up the developers to actually write the bits of Toybox that they want

I've already contributed personally to the code.

About the calculus for the project

Posted Feb 2, 2012 0:56 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

Personally as in, your own time or Sony? If Sony is supporting the project, you can't deflect criticism directed at Sony for exhibiting a level of hypocrisy. If it is your own time, the original criticism you are responding to, is still valid.

About the calculus for the project

Posted Feb 2, 2012 1:13 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)

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.

In a sense, Rahul, this is like us giving Red Hat grief for supporting rpmfusion - or not supporting it.

About the calculus for the project

Posted Feb 2, 2012 1:51 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

I am very well willing to grant the favor to Tim but I want to clarify the details first. If Tim is working on behalf of Sony or if Sony is permitting Tim to work on this project during work hours, then regardless of whose project it is, there is a association which cannot denied and hence the action of the company reflects on the individual or vice versa.

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.

About the calculus for the project

Posted Feb 9, 2012 21:48 UTC (Thu) by landley (guest, #6789) [Link]

> Personally as in, your own time or Sony?

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
http://lists.uclibc.org/pipermail/uclibc/2006-July/016032...

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.)

About the calculus for the project

Posted Feb 1, 2012 23:51 UTC (Wed) by i3839 (guest, #31386) [Link] (16 responses)

Your arguments sound reasonable, but are rubbish:

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.

About the calculus for the project

Posted Feb 3, 2012 0:24 UTC (Fri) by marcH (subscriber, #57642) [Link] (15 responses)

I think you missed one case: they don't know wether some of their contractors used a modified busybox and which contractors, but they know it is quite likely.

About the calculus for the project

Posted Feb 3, 2012 2:56 UTC (Fri) by i3839 (guest, #31386) [Link] (14 responses)

If you can't find Busybox, you can't replace it either. If you can find it, then you can compare the source to the official one and check if anything was modified. That's just one diff. If that is too much, just tar it up as it is and provide that to comply with the license. But finding a stolen Busybox and either not removing it immediately or not immediately complying with its license is plain wrong.

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.

About the calculus for the project

Posted Feb 3, 2012 9:33 UTC (Fri) by marcH (subscriber, #57642) [Link] (13 responses)

I think you still do not get their approach. While I do not agree with it I do appreciate its logic. It seems to go like this:

1. We do not have time to ask/check what our dodgy contractors are doing, (incredibly wrong in the first place) but:
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.

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).

Wrong anology

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

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).

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.

Not moral but perfectly logical.

Yup. The same as with food producers. Yet somehow aforementioned practice is universally despised while similar deal WRT software is supposed to be applauded.

About the calculus for the project

Posted Feb 3, 2012 18:30 UTC (Fri) by raven667 (subscriber, #5198) [Link] (6 responses)

> 1. We do not have time to ask/check what our dodgy contractors are doing, (incredibly wrong in the first place)

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.

About the calculus for the project

Posted Feb 3, 2012 23:33 UTC (Fri) by marcH (subscriber, #57642) [Link] (5 responses)

> > 1. We do not have time to ask/check what our dodgy contractors are doing, (incredibly wrong in the first place)

> 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.

About the calculus for the project

Posted Feb 4, 2012 14:51 UTC (Sat) by marcH (subscriber, #57642) [Link] (4 responses)

And by the way... http://queue.acm.org/detail.cfm?id=2030258

"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)

About the calculus for the project

Posted Feb 5, 2012 12:35 UTC (Sun) by alankila (guest, #47141) [Link] (3 responses)

I was already ready to say that if such a rule would come to govern free software, then all software I would ever release, regardless of its purpose, would be strictly anonymous and in public domain, because it would be very hard to accept any kind of personal liability for software given out for free.

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.

business

Posted Feb 6, 2012 9:03 UTC (Mon) by marcH (subscriber, #57642) [Link] (2 responses)

Another quote from the same article:

"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.

business

Posted Feb 6, 2012 11:31 UTC (Mon) by alankila (guest, #47141) [Link] (1 responses)

I think there's no point to make it hinge on money exchanging hands, especially as a liability rule such as this would lead to it being a standard practice to obfuscate this sort of liabilities.

business

Posted Feb 6, 2012 16:47 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

The reason money is a factor (AFAICT) is that in many cases your liability is limited to what you were paid for the product. Ergo, if you give something away for free, your liability is minimal, whereas if you sell it, your liability could potentially be greater than your net profits.

About the calculus for the project

Posted Feb 9, 2012 22:03 UTC (Thu) by landley (guest, #6789) [Link] (4 responses)

Heh. Dodgy contractors.

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

About the calculus for the project

Posted Feb 10, 2012 14:30 UTC (Fri) by marcH (subscriber, #57642) [Link] (3 responses)

If your company is messy and messes with licensing then it deserves to die under lawsuits initiated by "Hostile Copyright Owners" (tm). Sooner is better: makes room for slower but more serious companies (like mine). Special bonus points if said company lobbied hard to harden copyright laws.

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.

About the calculus for the project

Posted Feb 10, 2012 16:11 UTC (Fri) by landley (guest, #6789) [Link] (1 responses)

"s/copyright/patent/"

Let the backpedaling commence.

About the calculus for the project

Posted Feb 10, 2012 16:45 UTC (Fri) by marcH (subscriber, #57642) [Link]

> "s/copyright/patent/"

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.

About the calculus for the project

Posted Feb 12, 2012 15:44 UTC (Sun) by nix (subscriber, #2304) [Link]

Well, yes, except that *all* companies rapidly become a bloody mess because of accumulating history and staff turnover. It's impossible to keep in license compliance as long as any staff can drop off the face of the earth with a month's notice without documenting anything or ever communicating with the old workplace again (and, alas, that has been the tradition everywhere I've ever worked: they've routinely been shocked when I've presented them with an email address they can send queries to, FFS. Is supporting your own old stuff so radical? Apparently it is, to many people.)

So the real problem is FUD?

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.

So the real problem is FUD?

Posted Feb 2, 2012 1:36 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

GPLv3 bring in several other clauses that cause even more fear.

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)

So the real problem is FUD?

Posted Feb 2, 2012 1:40 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

I don't see any notion of repeat offenders in

http://www.gnu.org/licenses/gpl-3.0.en.html

So the real problem is FUD?

Posted Feb 2, 2012 1:44 UTC (Thu) by neilbrown (subscriber, #359) [Link] (1 responses)

Third paragraph of section 8.

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.

So the real problem is FUD?

Posted Feb 2, 2012 10:14 UTC (Thu) by khim (subscriber, #9252) [Link]

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.

About the calculus for the project

Posted Feb 2, 2012 4:24 UTC (Thu) by Company (guest, #57006) [Link] (42 responses)

What you are saying and what other people don't understand is that Sony does not care about legality (or legitimacy) of its actions at all. Sony solely operates on risk.

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?

About the calculus for the project

Posted Feb 2, 2012 4:35 UTC (Thu) by tbird20d (subscriber, #1901) [Link] (41 responses)

Did I get that right?

No. We have extensive mechanisms in place for compliance, for both business and moral reasons.

About the calculus for the project

Posted Feb 2, 2012 10:18 UTC (Thu) by jospoortvliet (guest, #33164) [Link] (40 responses)

So then the real problem is that you're so afraid of making a mistake in your compliance procedures (despite believing they are quite good) and getting sued the sh*t out of you by SFC that this project was started?

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?!?

About the calculus for the project

Posted Feb 2, 2012 18:59 UTC (Thu) by tbird20d (subscriber, #1901) [Link] (39 responses)

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

Posted Feb 3, 2012 11:01 UTC (Fri) by fb (guest, #53265) [Link] (38 responses)

Hi,

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.

About the calculus for the project

Posted Feb 3, 2012 18:53 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

> 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.

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.

About the calculus for the project

Posted Feb 3, 2012 19:37 UTC (Fri) by khim (subscriber, #9252) [Link]

Very few business would be comfortable with all of their hard work feeding in a one-way direction to their largest competitor.

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.

About the calculus for the project

Posted Feb 3, 2012 22:11 UTC (Fri) by jimparis (guest, #38647) [Link] (34 responses)

> many companies will -for whatever reasons- simply not touch anything with GPL on it.
...
> In reality writing Toybox seems more doable than changing some written-in-stone legal policies.

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.

About the calculus for the project

Posted Feb 3, 2012 22:38 UTC (Fri) by tbird20d (subscriber, #1901) [Link] (32 responses)

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.

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.

About the calculus for the project

Posted Feb 3, 2012 23:29 UTC (Fri) by jimparis (guest, #38647) [Link] (31 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.

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.

About the calculus for the project

Posted Feb 4, 2012 0:29 UTC (Sat) by tbird20d (subscriber, #1901) [Link]

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.

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.

About the calculus for the project

Posted Feb 4, 2012 0:41 UTC (Sat) by dlang (guest, #313) [Link] (27 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.

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.

About the calculus for the project

Posted Feb 4, 2012 0:46 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

Tim contacted Rob asking him if he'd be interesting in working on a liberally licensed Busybox clone. Rob's clearly working on Toybox for his own reasons, and I think they're all perfectly justifiable. Tim's interest in it is another matter.

About the calculus for the project

Posted Feb 4, 2012 1:10 UTC (Sat) by khim (subscriber, #9252) [Link] (25 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)

I have no problems with Rob's work.

Since toybox was a GPLv2 project for several years, it couldn't have been created to make it easy to bypass the GPL.

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.
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.

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?

About the calculus for the project

Posted Feb 4, 2012 1:25 UTC (Sat) by dlang (guest, #313) [Link] (23 responses)

you say

> 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.

About the calculus for the project

Posted Feb 4, 2012 11:21 UTC (Sat) by khim (subscriber, #9252) [Link] (22 responses)

you can't have it both ways.

Yes, I can.

> I have no problems with Rob's work.

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).

> what that project under discussion is doing is most probably flat out illegal.

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.

but you are talking about exactly the same project, Rob's toybox project.

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.

About the calculus for the project

Posted Feb 4, 2012 19:04 UTC (Sat) by alankila (guest, #47141) [Link] (20 responses)

I'm going to eradicate the context: you are basically advancing a theory which states that relicensing one software from GPL to BSD is illegal because some completely unrelated GPL-licensed software's license can then be violated without legal consequences?

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.

About the calculus for the project

Posted Feb 4, 2012 21:22 UTC (Sat) by khim (subscriber, #9252) [Link] (19 responses)

I'm going to eradicate the context:

Which will make the further discussion pointless.

Eben Moglen said it best here:

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....

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.

If licenses are being violated on some piece of software, then let those who have the authority sue if they choose to.

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.

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.

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!

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.

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.

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.

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.

About the calculus for the project

Posted Feb 5, 2012 11:12 UTC (Sun) by rahvin (guest, #16953) [Link] (10 responses)

An interesting argument I hadn't considered. In the interest of adding to your supposition I'll add the following. The theory of copyright infringement facilitation without engaging in actual infringement yourself has been used successfully in court several times in the US.

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.

About the calculus for the project

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:
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

Posted Feb 10, 2012 0:18 UTC (Fri) by landley (guest, #6789) [Link] (8 responses)

No, Tim asked me if I knew anybody who'd want to work on extending Android's crappy Toolbox so people wouldn't need to replace it with software that can never ship as part of Android, due to Google's existing "no GPL in userspace" policy which most android vendors inherit:

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
> 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.)

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.

About the calculus for the project

Posted Feb 10, 2012 10:16 UTC (Fri) by khim (subscriber, #9252) [Link] (7 responses)

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.

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.

About the calculus for the project

Posted Feb 10, 2012 16:19 UTC (Fri) by landley (guest, #6789) [Link]

"We'd like to get as many patents as possible to protect ourselves from the insane patent system via mutually assured destruction and cross-licensing agreements."

"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

About the calculus for the project

Posted Feb 10, 2012 16:22 UTC (Fri) by landley (guest, #6789) [Link] (5 responses)

By the way, another analogy for all the insane GPL zealots to ponder:

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

About the calculus for the project

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?

About the calculus for the project

Posted Feb 11, 2012 14:35 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

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.)

Cheers,
Wol

About the calculus for the project

Posted Feb 11, 2012 15:39 UTC (Sat) by khim (subscriber, #9252) [Link]

Actually, that's not fair on Titanic ...

She had FAR more lifeboats than were legally required.

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.

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 ...)

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.

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.

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.

About the calculus for the project

Posted Feb 12, 2012 15:51 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

btw, you might stand more chance of convincing people rather than repelling them if you didn't routinely call them insane. Just a thought.

About the calculus for the project

Posted Feb 13, 2012 8:27 UTC (Mon) by bronson (guest, #4806) [Link]

This is true. But I don't think Rob is calling all GPL zealots insane...? That's just a tiny subset.

About the calculus for the project

Posted Feb 5, 2012 12:25 UTC (Sun) by alankila (guest, #47141) [Link] (3 responses)

Thank you for a thoughtful reply. 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

Posted Feb 5, 2012 15:14 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

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.

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.

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.

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.

About the calculus for the project

Posted Feb 5, 2012 23:13 UTC (Sun) by anselm (subscriber, #2796) [Link] (1 responses)

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), …

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.

About the calculus for the project

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.

About the calculus for the project

Posted Feb 9, 2012 23:44 UTC (Thu) by landley (guest, #6789) [Link] (3 responses)

I'm the ex-maintainer of busybox, who started toybox before I actually did the last release of busybox. I'm the one who _started_ the busybox license enforcement lawsuits (and recruited Erik Andersen in into it, and yes I still have my old email).

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...)

About the calculus for the project

Posted Feb 10, 2012 10:06 UTC (Fri) by khim (subscriber, #9252) [Link] (2 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?

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?

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?

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.

And you take this position in defense of "freedom", as defined by the FSF?

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.

I ask seriously: are you crazy? Do you need some kind of diagnosis and treatment?

Me? I'm absolutely sane. The copyright world is crazy - but sadly I don't know how to cure it.

About the calculus for the project

Posted Feb 10, 2012 17:15 UTC (Fri) by landley (guest, #6789) [Link] (1 responses)

> 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.

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.)

About the calculus for the project

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

http://en.wikipedia.org/wiki/Traitorous_eight

Honestly, if you work in the industry you get to know this stuff...

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.

Oratroll is suing over patents

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.

About the calculus for the project

Posted Feb 9, 2012 23:36 UTC (Thu) by landley (guest, #6789) [Link]

> BSD-relicensed (that's important) toybox looks very much like
> Napster-style copyright infringement facilitator.

"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...
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...

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.

About the calculus for the project

Posted Feb 9, 2012 23:17 UTC (Thu) by landley (guest, #6789) [Link]

> What does it say to you? Two things.
> 1. That future lawsuits will probably not bring new enhancements for
> busybox.

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/...
http://lists.busybox.net/pipermail/busybox/2011-November/...
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

About the calculus for the project

Posted Feb 4, 2012 14:30 UTC (Sat) by nix (subscriber, #2304) [Link]

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

Posted Feb 9, 2012 22:54 UTC (Thu) by landley (guest, #6789) [Link]

> 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.

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

About the calculus for the project

Posted Feb 3, 2012 22:40 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Or the position they seem to be taking, IIUC, that GPL enforcement for Linux is NotTheirProblem(tm).

About the calculus for the project

Posted Feb 3, 2012 23:56 UTC (Fri) by marcH (subscriber, #57642) [Link]

The reality today is that every other company in the world is using GPL software, most notably Linux

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.

About the calculus for the project

Posted Feb 2, 2012 15:09 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] (2 responses)

"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:

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.

I think it's high time that Linux kernel developers joined in and granted SFC or other organisations the authority to act on our behalf too. Then we won't need to rely on the fact that Busybox is usually also pirated; we can act directly when there is a violation on the kernel itself.

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.

About the calculus for the project

Posted Feb 2, 2012 19:47 UTC (Thu) by masoncl (subscriber, #47138) [Link] (1 responses)

> 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.

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.

About the calculus for the project

Posted Feb 2, 2012 19:58 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

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.

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.

About the calculus for the project

Posted Feb 3, 2012 11:50 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] (1 responses)

"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.

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.

About the calculus for the project

Posted Feb 3, 2012 12:39 UTC (Fri) by dwmw2 (subscriber, #2063) [Link]

"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.

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.