About the calculus for the project [LWN.net]

About the calculus for the project

Posted Feb 1, 2012 23:51 UTC (Wed) by i3839 (guest, #31386)
In reply to: About the calculus for the project by tbird20d
Parent article: A tempest in a toybox

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.

to post comments

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