Slashdot Mirror
What is the Best Way to Handle a GPL Violation?
DeadSea queries: "When you find that somebody is violating the GPL by distributing your code or a derivative of your code as a closed source product, how do you go about handling it? I have found two violations of the GPL for my Java Utilities, in the last month. The Free Software Foundation says that the copyright holder is the only person empowered to act. If you are the copyright holder, how do you communicate with the offenders? I know folks here must have dealt with this before: Linksys, SCO, Castle Technology, United Linux, and others. Personally, I would like to believe that with a little nudging (and without lawyers), I can resolve the things. As such, I would especially appreciate any example letters or other documents that might be effective."
Or in the first place did you intend to demand that changes be rolled back into your project?
Well, duh. If I gave something away for free and then someone uses it to make a profit and doesn't even bother to help you out in the way you've helped them, I'd be pretty pissed off too.
Don't get me wrong, the BSD license has it's place, but if the main point is to keep the code free, what would you choose something that lets anyone take the code and make it non-free?
Not everybody misunderstands the thrust of the GPL. When I release code under the GPL, I do so for a very specific reason: I want to keep that code free. If I were to release something under the BSD license, it would likely only be because I don't much give a damn about that code anymore.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
I've sent emails, asking for the reasons why snippets of our source end up mysteriously in their commercial applications. In one case, a company (in Germany) came back stating that they happen to have the 5 same exact function names in their application, and byte-for-byte identical perror() strings to our application, but they insist they're not using any of our code, but claim that they did use it "for documentation purposes" when writing their application. That one is still open and pending, and we'll be doing protocol sniffs to see if theirs match ours. We have certain "fingerprints" in our protocol, which can only be done by using the source directly.
Another company I just found several days after the one above, seems to be using our code in a commercial BeOS project. They responded to my email, claiming that our code was used "as is" in their project, and then goes on to say "the use was re-configured to allow for easier additions". I don't see how they can claim both, in the same project. Either the code was used as-is (impossible, our code doesn't build on BeOS), or they modified it (and they must give us back the changes to those sources).
Another company directly took our code, removed all of our names from the project, replaced them with their own, slapped their own (non-GPL) license on it, and sold it to "partners" for quite a hefty fee. When we confronted them asking for an explanation, they basically told us to piss off. When we escalated, the CEO came back with, and I quote "If we end up in court, I will bankrupt these guys".
We also contacted this company's "partners", and asked them for the source to the changes they were also distributing. Every time we would contact these companies, the original company would threaten to sue us if we contacted their partners.
The FSF is involved in all of the cases. The investigations are still open, and pending.
Companies seem to think that because they have money, and most Free Software developers do not, that they can just slap us around left and right. The other point companies seem to try to "leverage" when they are clearly violating the GPL, is that the common myth that the "GPL Has Never Been Tested In Court(tm)", and since it has no basis, they can take whatever they want, and not give back. They seem to forget that the U.S. Copyright system backs up all of this code.
So what do we do? There are dozens upon dozens of cases where the GPL is clearly being violated; the MPlayer violation from KISS Technologies, the BusyBox Hall of Shame, and many more.
No, companies rightfully think that because the GPL has yet to be tested in court, there's no case history, and they'll be able to drag it out in the courts forever...that they can walk all over you.
The only answer is to dot your i's, cross your t's- give the offender all reasonable chances to comply. If they don't do it in a timely manner, SUE.
Let me repeat that.
SUE.
Why? First off, chances are most of these companies really can't afford a legal battle either. If you file papers- I'd bet a lot of companies would simply recognize you're serious, and cave in. You negotiate for your legal fees and force compliance on them, and you're done. If not, and you have what most people feel is a solid case, you'll have the whole Open Source community behind you, because we'll realize just how important your case is. The FSF assists your lawyer(they specifically state they'll assist- they just can't pursue on their own), we help you pay for your lawyer with a legal fund through donations(I'd donate!), and so on.
Not to mention, it's a lot easier to ask a judge for access to the company's source code than it is to go through all sorts of hoops to prove it. Show the trail of breadcrumbs leading up to the door, and the judge won't have much of a problem letting you open the door to see if there's a mouse nibbling on a cracker behind it.
So we loose some market share because people think we're evil bad guys who go around suing(this is why it's important to give people a chance). Who gives a fuck about market share? We're in this for the CONCEPT. Loosing some market share is better than the open-source concept becoming a joke("why should I open-source my stuff, if someone's just going to rip it off tomorrow, and I'll have no recourse against them?")
All it will take is a few lawsuits, and everyone else chasing down violators will have ammunition and WON'T have to sue...but our "nice guy" methodology isn't going to play, because we have no teeth to back up our "please comply" requests.
Please help metamoderate.
You can run an obfuscator, like Retroguard.
Most obfuscators are based on constant pool attacks. They go through the constant pool and give your fields and methods lovely names like void, int, class, and new. (Along with the standard fare- as many overloads as possible of a(), etc.) The JVM doesn't care, but the language spec does. So you can still decompile it, and the decompiler will cheerfully spit out code that doesn't compile because many of the variable names have been renamed to reserved words.
However, constant pool rearrangements don't significantly change the bytecodes. (And generally, obfuscators don't mess with the order of entries in the constant pool. If they do, they have to run through the actual bytecodes and fix the operands of certain instructions.) So bytecode is not altered by most obfuscators and you can easily develop a hashcode function for a class file definition that is based on the bytes in the bytecode segments and that will produce the same hashcode for a class before and after treatment by a run-of-the-mill obfuscator. So if you're trying to prevent people from copying your code, obfuscators work pretty well. If you're trying to hide stolen code from the original author who may be looking for such hash collisions, you have to use a better obfuscator which will screw with the bytecode itself.
Obfuscation has a nice side effect of shrinking the final JAR file, since most of the bulk of a Java class is in the constant pool and the obfuscator tries to rename everything to "a". In fact, I heard someone saying that the word "java" appears so many times in the constant pool of Java's standard library that if the name "Oak" hadn't been taken, the typical size of a JVM download would have been reduced by some absurdly significant percentage.