About the calculus for the project [LWN.net]

About the calculus for the project

Posted Feb 2, 2012 4:24 UTC (Thu) by tbird20d (subscriber, #1901)
In reply to: About the calculus for the project by rahvin
Parent article: A tempest in a toybox

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.

to post comments

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