Slashdot Mirror
Enforcing the GPL On Software Companies?
Piranhaa"I currently use an IPTV box that runs software by Minerva Networks. When you ssh into the box, you are greeted with a BusyBox v1.00 (ash) shell. It's clearly running a flavor of Linux (uname -apm outputs: Linux minerva_10_0_3_99 2.4.30-tango2-2.7.144.0 #29 Wed Mar 16 16:16:16 CET 2005 mips unknown). However, when you look at their Web site there is no publicly available source code. Since the GPL in both BusyBox and the Linux kernel require that anyone using and distributing the binaries of this software make source available to everyone, what would one do in order to enforce this? I've personally emailed Minerva and left voicemails with no reply."
Sounds like you need to take the GPL quiz. This particular issue is addressed in Question 1 of said quiz.
Don't worry, you're definitely not alone in any misunderstandings of the GPL...lots of people think they understand all the legal aspects of it completely when they don't. I used to be guilty myself. Now I just don't claim to know everything about the GPL ;-).
The Right Reverend K. Reid Wightman,
Sometimes companies with hotshot lawyers deliberately put their head in the sand regarding the GPL. They want to use the code but don't want to make their changes public for "intellectual property" reasons, even if it's something as trivial as a few patches to fix some bugs in Linux or some existing drivers. They will "educate" staff as to why they can do what they do with GPL software "legally." The hotshot lawyer has it all figured out, and engineers don't really need to know the details. The excuse is that they "buy their Linux" from a 3rd party so that means that all the conditions of the GPL are not relevant for some lawyerish reason. Oh, and the GPL is "contentious" about what you actually have to do regarding distributing source.
If you want news from today, you have to come back tomorrow.
FSF and gpl-violations.org are co-operating closely. gpl-violations and FSF have handled some cases regarding busybox before and have handled them successfully (i.e., out-of-court settlements have been achieved).
And a settlement resulting in GPL compliance - that's what enforcing the GPL is all about.
As Eben Moglen, legal counsel to the FSF for many years, put it (in a keynote address in October 2006):
---
When I went to work for Richard Stallman in 1993, he said to me at the first instruction over enforcing the GPL, "I have a rule. You must never let a request for damages interfere with a settlement for compliance."
I thought about that for a moment and I decided that that instruction meant that I could begin every telephone conversation with a violator of the GPL with magic words: We don't want money. When I spoke those words, life got simpler. The next thing I said was, We don't want publicity.
The third thing I said was, We want compliance. We won't settle for anything less than compliance, and that's all we want.
Now I will show you how to make that ice in the wintertime. And so they gave me compliance.
---
http://www.geof.net/blog/2006/12/10/eben-moglen
It is, isn't it? While Richard Stallman certainly did not write all of it, the document shows his experience and intelligence at dealing with odd interactions. It's what I'd expect from someone so deeply involved in creating gcc and glibc and emacs, and the development of so many other GNU software tools.
Richard does not put in the odd language or strange requirements for no reason: he's usually quite correct in being paranoid of those strange cases, because as an experienced programmer and now an experienced political activist he's seen compelling reasons to handle them specifically. It's why code by older programmers often is longer and more extensive than the simpler, cleaner, but more trusting software written by less experienced developers. The new developers with exciting new approaches often haven't learned the lessons of our experience, and by the time they've done all the patching to avoid the same pitfalls, their code will be as arcane as ours.
I was actually just thinking about this, and here's a thought. If you have actually been damaged by someone refusing to distribute the source code as required by the GPL, you may be able to bring a lawsuit as an intended third-party beneficiary of the contract between the copyright holder and the licensee. If you really want a good time, and you and other people have had small but measurable damages, you could bring a class action.
Yeah, that is correct. I am work for a company which I won't name(Not the company that the OP is talking about) that uses exactly this provision in the GPL to keep Source Code off of the main Website. I know that sounds bad, but the real reason is that we don't actually have 100% of the source code our self.
One of the original developers that worked on this product got lazy and originally most of the smaller parts of the system were actually pulled into the project in binary form from several different Linux distributions. The problem is we too this day don't know for sure where he got all of this stuff. We have been weeding it out of the image as time goes on but I know that even today there are a few things that are just being pulled into new images in binary form. I know that currently most of the stuff still in binary form is stuff that could be replaced with BusyBox but we don't like the busybox version for one reason or another.
But one really interesting thing I have learned is since we actually see all of the code requests come in is that so far nobody has really wanted to the code for a practical reason. All of the requests have been done for "GPL Activism". In the majority of cases when people ask for code they just wanted to see if we would let them have it. I only one case that I know of did anyone go so far as actually getting code. I am rather sure we just shipped him a burned CD with all of the code on it. But after he got it he told us that he didn't really want the code, he just wanted to see if we would give it to him just like all of the other requests.
In most cases these forms of source code dumps don't really give you much of anything useful. What you end-up with is a source code package on company server that may or may not have anything really useful the to rest of the open source community included in it. Someone could diff the public version and these private forks, generate patches and see if anything would be useful to merge into the mainline. But that is a lot of work for something that you don't even know is worthwhile from the get go. I will tell you that the majority of the software included in our firmware isn't modified.
I feel instead that when the company in question makes changes it's FAR more important that they submit patches to the mainline developers for possible inclusion. This is what we are actually doing, we have been working very closely with normal maintainers to add some major new networking features to Linux. And I know patches are going into the mainline version. I guess in the end what would most people rather have... Some files on a webserver that might have something really useful buried inside them or companies working with developers to get new features added to the mainline source code. I feel that this pressure to have source code posted on websites would be better spent trying to actually get a real dialog between these companies and the open source developers. Working with a developer is always going to be harder than just slapping up some source code on a webserver. Which is why I feel that it's just an easy out in many cases but doesn't really help the community.
p.s. Our biggest sort-of competitor also uses open source software... They allow everyone to download the software in binary form. But if you want source code... you have to Wire Transfer ~$50 to former a USSR country... which in and of itself is a violation of the GPL. And given some of the features that they have added is to software packages that they don't even list as being included really makes me wonder what you get for $50...