About the calculus for the project
About the calculus for the project
Posted Feb 3, 2012 2:56 UTC (Fri) by i3839 (guest, #31386)In reply to: About the calculus for the project by marcH
Parent article: A tempest in a toybox
Knowing that some subcontractor somewhere violates copyright doesn't help to solve the problem if you can't find out which software that is. If you have no access to your own device's source code you're totally screwed, one way or the other. How can you check your (sub)contractor's work if you can't see what they did?
That companies want to avoid GPL software altogether in the future is something I can understand, especially with scare tactics like losing the license forever. The GPL is too often misunderstood, partly because of FUD. But that is only possible if they are in control of the software. If they are then they have no excuses at all to not comply with all licenses. If they aren't, then writing non-GPL replacement software won't change anything.
Posted Feb 3, 2012 9:33 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (13 responses)
1. We do not have time to ask/check what our dodgy contractors are doing, (incredibly wrong in the first place) but:
Solution: influence the "market" by creating an alternative to busybox attractive enough to be selected by dodgy contractors. This will *statistically* reduce the risk of being caught.
Not moral but perfectly logical.
Think of a prepared food producer trying to introduce stricter farming regulations - even when not doing any farming itself (except this one is of course more likely to be moral).
Posted Feb 3, 2012 10:45 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Nope. Stricter farming regulations will be requirements to send the GPL code along with busybox binaries. What happens here is the coercion to replace products produced by farmers with concoction of flavour enhancers potent enough to cover the odour of rotten meat. Yup. The same as with food producers. Yet somehow aforementioned practice is universally despised while similar deal WRT software is supposed to be applauded.
Posted Feb 3, 2012 18:30 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (6 responses)
I think that is a mischaracterization of the stated concern, its not that they are being willfully ignorant of their suppliers its that in a large organization it's easy for some team to accidentally distribute pirated software by not doing due diligence on the vendor (or the vendor lying). The belief, right or wrong, is that a hostile copyright owner could cause a lot of trouble so to reduce this risk they are going to work on liberally licensed software that they own the copyrights on so that the components they maintain don't have piracy issues and presumed-hostile copyright owners.
Maybe Bradly Kuhn is some moustache twirrling ogre who's just itching to screw over some poor defenseless large manufacturer, the people involved probably know better than I, but I don't see any evidence in the publicly available information to support that hypothesis.
Posted Feb 3, 2012 23:33 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (5 responses)
> I think that is a mischaracterization of the stated concern, its not that they are being willfully ignorant of their suppliers its that in a large organization it's easy for some team to accidentally distribute pirated software by not doing due diligence on the vendor (or the vendor lying).
I think this is an overly nice way to say the exact same thing.
You MUST carefully select and watch your suppliers, period. Make sure they have a good reputation, tie them in very strict contracts, make sure they are too big too fail (and can pay you any damages back), force them to give you their source code and audit it yourself... this is really just business 101. If the managers of your company cut corners on business 101 in order to be first to market, then I sincerely hope your company dies in copyright litigations (GPL or else) because for sure my company forces us to be thorough and extremely careful, which obviously has a cost, and I would hate you beating us on the market because of that.
[Don't take it personally: it was just easier to give you the role of the bad guy]
> "Hostile Copyright Owner"
Too bad neither Hollywood nor the BSA never cared educating the masses with this new and interesting "HCO" concept.
Anyway I agree with i3839 to some extend. Even assuming that the most HCO owns and defends busybox today and that busybox gets successfully replaced, the most HCO will be someone owning something else in one year time and back to square one.
Posted Feb 4, 2012 14:51 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (4 responses)
"Some say the only two products not covered by product liability today are religion and software. For software that has to end;"
"If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then the builder shall be put to death." (Hammurabi's Code, approx. 1700 BC)
Posted Feb 5, 2012 12:35 UTC (Sun)
by alankila (guest, #47141)
[Link] (3 responses)
Then I read the link and observed it advocates liability only for closed source software, where the author of the software must be trusted, and eliminates it for software with source code, where the user could (in theory) become fully informed consumer of the software product.
Posted Feb 6, 2012 9:03 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (2 responses)
"if you make MONEY selling something, you'd better do it properly, or you will be held responsible for the trouble it causes" (emphasis is mine).
It's really more about *business* rather than closed source. If you sell open source then you are accountable (or should be). If you give closed source software for free then you should not. In the latter case you typically do not even know who is using the software and for what.
Posted Feb 6, 2012 11:31 UTC (Mon)
by alankila (guest, #47141)
[Link] (1 responses)
Posted Feb 6, 2012 16:47 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link]
Posted Feb 9, 2012 22:03 UTC (Thu)
by landley (guest, #6789)
[Link] (4 responses)
I worked at a place that checked all the source code into horrors like "Accurev", "Rational", or whatever that one beginning with a P is I've blotted out. Starting with a tarball (no history beyond that) and checking in local changes on top of that.
Then the _fun_ ones go on to check the _result_of the build into a _second_ source control system, populated entirely with binaries and tracking the root filesystem layout (or RPM binaries, or whatever they ship).
Impedence matching between the first source control system and the second source control system is entirely ad-hoc. Bonus points if they're different technologies left over from a department merger and/or partial migration that never removed the "legacy" system. (Adding new one in parallel: easy. Removing old one: hard.)
I didn't fight with this stuff in a license enforcement context. I fought with it in a "I'm working a 3 month contract to fix accumulated customer bugs in a legacy system they've forgotten how to _build_. They have partial source code for their product, but no longer have the context it built in and the people who did this moved on years ago" context.
It's lucrative, yet horrible. (I remember a contract at Dell where they paid Red Hat to support Red Hat Enterprise 2 _after_ it was end of lifed because they'd done shared libraries in C++ which did an "extern C" around all their library exports and then returned a pointer to a class instance, so all the funky name mangling changes between gcc versions bit them on the nose and they either had to upgrade bangalore, raleigh, and austin all at the same time _and_ ship a flag day release to all customers (of this funky high-end SAS array diagnostic/monitoring tool) or stick with the old compiler forevermore. They got _into_ that state because nobody had realized the full ramifications of their build. Getting a handle on the real dependencies and reproduction sequence of modern software builds is _hard_, at least when the FSF was ever involved in any way. Grub 2. *shudder*)
The real world is messy. This is not new. You're talking about BusyBox, a project that at one point had FIVE shell implementations that didn't share code. If _we_ couldn't get that cleaned up in the first decade of the project's existence, why the heck are you holding others to a higher standard?
Rob
Posted Feb 10, 2012 14:30 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (3 responses)
This is just natural selection. Bye. It will incidentally make room for higher quality software and more interesting jobs - I'm sure you will like it.
This might delay a bit the release of the next great smartphone/set top box/you name it - we will all survive.
Poor attempts to ask the "community" to rewrite this or that piece under a BSD license for you are laughable and you will buy very little time (assuming they succeed in the first place).
Once again: nothing GPL-specific in the above.
Posted Feb 10, 2012 16:11 UTC (Fri)
by landley (guest, #6789)
[Link] (1 responses)
Let the backpedaling commence.
Posted Feb 10, 2012 16:45 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
No.
The copyright system is not perfect and probably too hard but it's fair and basically working. The current patent system is completely broken and totally unfair.
Imagine you write some code, then I copy and massage a few lines of it and bang I get the copyright on the whole thing. This is how the copyright system would look like if it were managed by the USPTO.
Posted Feb 12, 2012 15:44 UTC (Sun)
by nix (subscriber, #2304)
[Link]
About the calculus for the project
2. We know that dodgy contractors in general tend to have a strong taste for busybox.
3. Unlike other violations, busybox violations tend to be noticed by people (more thorough than us) and they often have consequences.
Wrong anology
Think of a prepared food producer trying to introduce stricter farming regulations - even when not doing any farming itself (except this one is of course more likely to be moral).
Not moral but perfectly logical.
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
business
business
business
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project
About the calculus for the project