On Monday 13 October 2008 21:54:03 Alain M. wrote: > I have followed this thread and nowhere I have seen two important points: > > 1) a GPLed software like Busybox can be used in a proprietary product, > as long as not linked at all with the proprietary part. Even in an > embedded it can be used.
As long as you abide by the license terms, which means providing source code. And before you say "but the source is already available elsewhere", read on, I'll get to that. The text of the license obliges you to provide source code for binaries you distribute, and gives you exactly three options for providing source code. These options are spelled out in section 3 of the LICENSE file in the busybox source tarball: A) bundle the complete corresponding source with the binary B) bundle a written offer good for three years to provide source upon request (these days this is often a URL). C) point you users at the upstream source (I.E. pass along somebody else's 3B offer). Now section 3C is what most open source people use, and it's so lenient lots of developers don't even think about it. Technically 3C is also full of restrictions (it's "allowed only for noncommercial distribution", and it only applies if you're redistributing a binary you didn't build yourself) intended to push people to use 3A or 3B, but the busybox project has generally let those restrictions slide (as has most of the rest of the open source world) when dealing with people who are acting in good faith. So if you built an unmodified busybox release and you point people at the URL to the _SPECIFIC_ source tarball on busybox.net you built it from and truthfully say "that's it, no patches", we've accepted that as compliance even from commercial companies. (We're not really interested in forcing random strangers to mirror stuff we've already got. OSUOSL provides very nice high bandwidth hosting for us, and if they didn't there's always sourceforge and savannah and ibiblio and kernel.org and...) The word "specifc" above is very important. If you don't even _identify_ the source that comes with your binary, there's no way you can say your distribution complied with the license terms. This means that even if you didn't modify it (and thus the source code in question is already widely available) you still need to _tell_ us what source code this binary comes from. (Yes, busybox prints out a version number but are you distributing a release, or a nightly snapshot, or what?) That's an obligation you have under GPLv2 when you distribute a binary: show us the code. Secondly, even if you didn't modify it, if you don't explicitly _tell_ us you didn't modify it how are we to know? I could spend weeks combing through an assembly dump of your binary, or trying to find the exact cross-compiler version you used to produce a byte-for-byte identical file, but the license says I shouldn't have to. Proving a negative is a lot of work, and making me do this work is again shirking your obligations under GPLv2. Why am I harping on "specific" so much? Imagine somebody takes a release version and backports a half-dozen patches out of svn. I can say from personal experience that trying to figure out what version _that_ is gives you a real headache. (Giving us a tarball of the source code you built is indeed one way to comply, and I'm not saying you _shouldn't_ do that if it's what you have lying around, but on more than one occasion just telling us "We're using version blah plus backports of SVN# blah, blah, blah, blah, and blah" would have saved me personally several hours determining that there wasn't actually anything _new_ in it. And yes, even though we theoretically have all this code already, the way you put it together is kind of unique and not necessarily trivial to reproduce. Or, for that matter, untangle.) The above is a fairly lenient interpretation of GPLv2 that works a bit like the BSD license's "advertising clause": that one required you to thank the university of california, this one requires you to identify the specific source code of the GPL binaries you distributed. The GPL actually allows us to be more draconian than this (for starters, clause 3C doesn't have to apply to commercial companies at all), but as long as everybody's acting in good faith most projects seem happy with just identifying the specific source for binaries built from an unmodified upstream version. Obviously if you did modify the source to the binary you distributed, and you don't think you need to at least provide us a _patch_, you've missed the point of GPLv2 entirely. This is another incentive to get your patch merged, so you can ship a vanilla upstream version and not have to host your patch on your own website for 3 years after you _stop_ distributing your product. The next paragraph right after 3C essentially says you're supposed to give us your .config file as well, and sometimes we've asked for that as long as we're contacting people anyway. But to be honest, if we don't need to contact you to get the other stuff anyway, we seldom bother. (We can generally figure that one out for ourselves. I note that Linux kernel .configs are harder to reverse engineer, for that you'll probably need to provide a .config for to make the developers happy, but they put in a /proc/config.gz option to make it easy. :) Now the above is what happens when people are acting in good faith. I note that the GPL imposes upon you the obligation to provide source code _when_you_distribute_. Whether you're using 3A, 3B, or 3C, they all start "Accompany it with", meaning source goes with binary at time of distribution. So if we get the binary from you and there's no _mention_ of source code, your distribution of that binary didn't comply with the terms of the license. At that point, you're already in breach of the license terms, and it's now about _fixing_ it. So if we have to approach you after the fact to get this information, we have the option to be really nasty about it. We're not _required_ to be nasty, and we prefer not to. An honest mistake that a company is willing to fix is understandable, and as far as I know we've always started out with "excuse me, could you fix this please" and not made a fuss. Most of the time, it doesn't go beyond that, we get back an email "oh, sorry, it's version blah, and here's the three line patch we used to change a default value", and we're happy. (We keep meaning to start a "hall of fame" with the _positive_ compliance information we've got...) And some companies are disorganized but honest about it, and go "um, we lost track of this information and the guy who did it left the company, can you give us some time to dig it out of the archives?" And if they're making an honest effort, we're polite about that too. But the "hall of shame" proved that being polite wasn't always enough. Some companies ignore the polite requests entirely, and go all deer in the headlights on us, or maybe hope that if they ignore us long enough we'll go away. Those are the ones that the SFLC sends _impolite_ requests to, asking for far more than the original request did back when they were being nice. For starters, if the SFLC has to actually sue someone to get their attention, they bill them for expenses. (They have an office in New York City, you _really_ don't want to go there. Also, they usually make the company appoint an "open source compliance officer" and deliver quarterly reports. And make them try to contact the old customers they shipped product to without source and let them know where the source is. All this is the lawyerly equivalent of "raising your voice to be heard". I've only seem them take the gloves off once. They've only _needed_ to once.) A lot of companies get in trouble because although they use an upstream vanilla source tarball, they don't say what version it was, or they don't explicitly say it wasn't modified. Then when we approach them for more information, they don't understand what we could possibly want, and panic. (Panicing bad. Please don't panic, this is actually pretty easy to get right. Ignoring repeated polite requests is not going to end well. Please be polite _back_. Ask for clarification if you don't understand something, it's not an admission of weakness. If you ignore us until we stop knocking, these days it may mean we're getting the battering ram. This is not an improvement for anyone concerned.) Another common failure mode is companies that redistribute some vendor board support package they bought, and when we ask them they brush us off with "we got it from a vendor, go bug our vendor, not our problem". Dude, you're copying and distributing GPL code too. If the license is the only thing that gives you permission to do that, then that license applies to you too. Really. If your vendor complied with the license terms but you didn't, you're not off the hook. This is not a scavenger hunt, nor is it the episode of M*A*S*H about getting tomato juice to Colonel Potter. We asked _you_, and you have an obligation to provide this information. If you don't even know what it _is_ when we ask, something is _wrong_. If you'd reprinted somebody else's documentation and stripped out BSD advertising clause notices, do you think you could then say "but the original PDF we got from our vendor had the notice in it, so we're ok, don't bother us"? Or would going "oops, here's one with the right data" be _your_ responsibility? Fixing this is not _our_ job. "We ask, you answer" is us being _lenient_, the license technically says we shouldn't have had to ask in the first place, you were supposed to provide this info when you shipped. And even if we're letting you delegate the implementation, you can't delegate the _responsibility_. Don't make me look up how to spell "fiduciary". (And delegating it to _nobody_ really isn't as solution. Asking us to track down an ex-employee of a defunct Taiwanese company where nobody spoke English just _doesn't_go_over_well_...) Sorry about that. Scars from the "hall of shame" days. We have lawyers now. They're very nice. Where was I? A company that wants to be legally paranoid will make a source CD for the GPL portions of their entire product (build scripts, cross compiler toolchains, and all), and either include the CD in the box with the product (clause 3A) or put the ISO up on the web and mention the URL to it in their product's documentation (clause 3B). They don't need our say-so to be satisfied with that, even a strict reading of GPLv2 says that complies with the license terms. (You can probably even email the SFLC guys about what exactly should go on the CD, [EMAIL PROTECTED]) This is the "make it go away" preemptive nuclear strike approach, and probably a good idea for Fortune 500 companies that have their own legal department to do _anyway_. Ideally, what the busybox developers really want is for people who develop a product using BusyBox to post a message to the busybox mailing list when their product ships. What's most useful to _us_ is something like: A) a description of the product (including the build environment: processor type, libc version, kernel version) B) identify the specific version of busybox it uses C) identify any modifications made to that version (either by linking to a nicely broken up series of "diff -u" patches on the web, or attaching the patches to the message, or explicitly saying it isn't modified) D) attaching the busybox .config file you used to build the thing. This is the "being nice to the developers" approach, which acts as a sort of free advertising within the developer community, and would let us put your project in a "hall of fame" page on busybox.net if we ever get around to doing that. (Heck, if traffic of these messages got high enough we could create a list just for them. Such problems we should have.) You really can't go wrong with either approach: you can obey the letter of the license according to a strict reading, or you can make the developers as happy as possible so they not only have no reason to make trouble, but actually like you. (Heck, we won't complain if you do both. :) Rob _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
