Abusing the GPL?

Anonymous with good reason, a reader would like to bring this important question to your collective attention: "Our (technically savvy) lawyer has advised my company that 'incidental resources' do not a work derive. For example: If I have a student's version of a development environment whose license does not allow me to distribute code compiled with it for commercial use, I am legally allowed to use the environment to create my ANSI C++ code, which, when I compile it with GCC, I am free to use to whatever commercial end I like. This seems fairly intuitive. (After all, you could have written the same thing in a text editor, and the debugging, etc, that you need the IDE for doesn't actually 'show up' in the final code). Here's the kicker: My company wants to translate this to an abuse of the GPL and has been advised 'full speed ahead!'"

"How, you may ask?

Integrate the highly useful GPL code we're eyeing into our only slightly more complex (but much more lucrative) project, thereby saving us at least 30% of the coding involved. The company then go all the way to production with it, but instead of finally compiling the actual project for distribution, they instead compile a bunch of incomprehensible gobbledygook that just happens to compile to the same bytecode. You know the game: globally replace every function name, variable name, and so on from our code with nonsensical names (or random characters), remove all of the comments, and any other form of obfuscation they can introduce. They will then GPL the obfuscated gobbledygook, which isn't much more useful to anyone than reverse-engineered bytecode would be (it is a complex project). 'Voila!' All the benefits of a huge GPL project and countless thousands of volunteer hours and unreadable, incomprehensible source tree.

For the record: I do not think this is right yet, I have not been able to find any precedent for why the GPL should protect against this kind of abuse.

I'm not trying to snitch on my company -- or lose my job, which is why I am posting anonymously -- but hopefully some lawyers out there could point out some iron-clad legal reason preventing this sort of thing. I've read the GPL through at least a dozen times since yesterday, and so far it looks like our lawyer is right. I have not found any relevant linkage either, as I have mentioned. Links to extended legal analyses of the GPL from a technical standpoint (if any exist) would be the most helpful. All help is appreciated."

Comments

Total obfuscation is not possible

[jsmyth]

Previous article: On the (Im)Possibility of obfuscating programs.

Pretty boring stuff, but the overall point is that once the end product is GPL'd, it won't take long for someone in the bazaar to figure out a meaning for "asdfgh", and do a s/asdfgh/meaningfulName/g through the whole thing. Or even figure a way to diff it with the original source.

As long as it's GPL'd, the source will be available, and it'll be figured. You're wasting a lot of your time (and the rest of the community's) for very little reason.

No matter how complex your obfuscation, it's likely much less complex than, say, CSS or DES was.

Re:Your lawyer is a fucking retard

[IPFreely]

If you start with the code, remove comments, change variable names and whitespace... it's still the same code, AND it's a derivative work, subject to the restrictions on the GPL.

From my reading, that is not the problem. It appeared that the company did release the code with source as GPL along with their product. They just obfuscated it before releasing it. That is not directly a GPL violation.

There have been cases before of obfuscated GPL code (Some video drivers in the Linux Kernel I believe) but those were original source from the manufacturer.

This article is about taking someone elses GPL code, obfusacting it, then re-releasing it with GPL intact.

You don't understand the spirit then.

[Chris Burke]

I don't see how this violates the spirit of the GPL, since there are no provisions in it for the quality or readibility of code.

The "spirit" of the GPL is about being able to make modifications to the code. That is one of the rights that the GPL is trying to preserve. It isn't just about being able to get a free copy of the code you can compile (and if you're lucky for different platforms).

As at least a dozen other posts under this article have already said, there is language in the GPL providing for quality -- or at least editability. The source must be in the "preferred form" for editing. Because releasing a .asm file that is just the disassembly of your binary isn't very useful for preserving the right to modify the program. Neither is deliberately and cleverly obfuscated source.

The authors of the GPL understood that "openess" depended on at least the level of usability that was present when the code was written. Hopefully we've cleared this up (and this guy's company lawyer has been sacked).

Re:You don't understand the spirit then.

[earlytime]

from the GPL:

"The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable."

I interpret this to mean something equivalent to ASCII, depending on platform. Or the form of source that is usually sent to the compiler, or the form of source that the (original) developer is accustomed to working on. In other words, C source code, not XORed EBCDIC, nor a JPEG of the ASCII source, nor a stereogram, nor a t-shirt with a poetic interpretation of the algorithm used(ala DeCSS).

IANAL, so it's really up to a judge to decude what exactly this means. But i think that obfuscated source is just as good as well-documented cleanly formatted code for satisfying the GPL. Obviously the clean source is preferred, but not required.

Couple of points...

[Noryungi]

IANAL, etc... etc... yadda, yadda, yadda.

The company then go all the way to production with it, but instead of finally compiling the actual project for distribution, they instead compile a bunch of incomprehensible gobbledygook that just happens to compile to the same bytecode.

You know the game: globally replace every function name, variable name, and so on from our code with nonsensical names (or random characters), remove all of the comments, and any other form of obfuscation they can introduce.

They will then GPL the obfuscated gobbledygook, which isn't much more useful to anyone than reverse-engineered bytecode would be (it is a complex project). 'Voila!' All the benefits of a huge GPL project and countless thousands of volunteer hours and unreadable, incomprehensible source tree.

Here is my take:

• Doing this would be a sure-fire way to royally anger every sane-minded person out there. No legal action possible, of course, but a lot of ill-will, screams, flames and gnashing of teeth, especially if said GPL'd code includes volunteer work (which you seem to imply). Boycott of the company's product seems a logical conclusion.
• What can be done in one way, can be done in the other way. If the project is interesting, and if volunteers are angry enough, they may well go through the code with a fine comb, clean it, insert understandable variable names, comment and generally un-obfuscate. Not an easy task, but one which is possible if motivation is high. See previous comment.

Other things to take into account:

• Never understimate the power of UNIX text-processing tools. Perl, awk, Python and sed are your friends in this kind of GPL obfuscation. Again: if the motivation is here, and the project justifies it, the code will get cleaned-up. Even if the obfuscation reaches magnificent levels of deviousness and evil, the "Open Source" community will provide an alternative.
• If the code is un-obfuscated (or an alternative is provided), I am sure a lot of companies and institutions who care about GPL would gladly host the project. Add a storm of negative comments and, bingo! code fork and instant (open/GPLed) competition... Your business is cooked and your revenue stream is dead,a nd I mean dead, since people will make a point of boycotting your products. Think SSH/OpenSSH. And (here is the nice part) there is nothing your company can do about it anyway... It's GPL code, remember?

Conclusion?
Bad idea. VERY bad idea. Release code under GPL, play nice, and nobody gets hurt... (wink! wink!) ;)

IMHO, any company who tries that kind of stunt is going to end up on the trash-pit of dot-coms faster than you can say "GNU General Public License".

Re:Don't be so sure.

[Znork]

Yes, it does:

'The source code for a work means the preferred form of the work for making modifications to it.'

Incomprehensible gobbledygook does not the preferred form make, any more than machine code.

What a lot of people appear to miss a lot of the time is that the GPL is _not_ one of those 'thrown together in a week' opensource licenses. It was developed over several years, and reviewed and rereviewed by the FSF legal counsel. It doesnt have holes like this.

Newbie lawyers looking at it for a few hours always misinterpret it. They dont have the technical savvy, nor the persistence to grasp the actual meaning and how thorough the GPL actually is when it comes to accomplishing its task.

The current MySQL AB/Nusphere legal issue isnt the first court case on the GPL because nobody has tried to violate the GPL before. It's because everyone else has realized they dont have a chance in court, and have given up rather than trying to persue a case which their lawyers have eventually realized they will lose.

You are not anal enough either. (IAAL)

[SPYvSPY]

First of all, IAAL. Second, the GPL's definitional distinction between source and object/executable form relies on two key terms that cannot be objectively measured: "preferred" and "normally". I defy you to provide me with objective metrics for measuring what is "normally distributed...with the major components...of the operating system on which the executable runs." Equally imnpossible is a definitive response to the question "what is the preferred form of the work for making modifications to it?"

In order to impart meaning to the GPL distinction between source vs. object/executable, one must go on a fact-finding parade to measure industry practice, and other wishy-washy standards. In the context of a dispute over a GPL'd bit of code, you can be damn sure that the GPL will collapse under the weight of this fact-finding process, and that the party with more patience and money will win that battle.

There are some things that lawyers understand better than geeks, believe it or not. We are (generally) excellent at spotting weakness in prospective arguments. In the case of the GPL, there are drafting holes big enough to drive a Trident submarine through. I've said it before, and I'll say it again: the GPL won't hold water in a dispute. The reason no one has given you any precedent (as per your request) is that the GPL has not been truly tested in court. Since the GPL eschews the lessons that lawyers have learned about drafting in the past (largely in order to score points with geeks by being colloquial in manner and sounding un-lawerly), it cripples itself with imprecision and ambiguities. The weakness in its core definition of source vs. object/executable is merely one of many fatal flaws in the document. To be perfectly frank, the GPL is a POS contract and I would arguably be liable for malpractice if I advised a client to use it for reason other than their unbending adherence to open source dogma.

In conclusion, you are likely to see many companies "abusing" the GPL. Rather than use the loaded term "abusing", I would prefer to characterize this behavior as "exploiting" the unsophisticated and niave drafting of the GPL's language.

Since I said "IAAL", I must also say that the above does not represent a formal legal opinion, that I do not represent you (the reader) as your lawyer, and that you should not treat this message as my legal advice to you. Laugh all you want -- I'm just sticking to my ethical directives, kids.

misc thoughts, but im not a lawyer....

[jreames]

I'm not an expert with legalese, but:

First arent all the copyright notices inside comments ?

Removing comments with the copyright notices would immediately violate T&C section 1. (while indicating acceptance of the whole document as per section 5), but then you aren't allowed to remove the comments. The obfusciation is seemingly permitted so long as the copyright comments still remain along with additional comments documenting the changes as required by section 2.

The obfusciation is seemingly a process of derivation, that is you start with GPL product and do some M-x replace-string's... This derivation process means that the "proprietary intellectual property" is still GPL'ed...

The GPL does NOT apply to sections not derived from GPL code, but only when they are published apart from the GPL portion. when the whole package is published it is still GPL'ed by inclusion of the GPL code (does anyone remember the Nvidia driver issues?)

Also according to section 5 the fact that you edited the GPL code at all indicates acceptance of GPL terms and conditions. Failure to accept prohibits you from making modifications (such as the string search and replace described)

The whole process seems expressly in violation of section 4, but i am no expert...

What I fail to see is how anyone can avoid GPL except by producing clean-room-code. I seem to recall Nvidia having this problem with their drivers a while back.

As an aside, isnt "chicken noodle soup" less than 30% chicken by volume? (but it is still considered a chicken product.) Your company's project might be 30% GPL code that was heavily edited (IMHO the only real weakness in the GPL is no "real" definition of "derived", however the common meanings of derive include "to trace the deveolpment of", which has been done...)

A couple of questions: Is it possible to write a perl/awk/sed script (or otherwise algorithmically describe the obfusciation? (since global replaces are used i would dare way yes...) If this is true then an argument can certainly be made that the work was "translated" from "ANSI c++" to "ANSI c++" (hasnt anyone done english-to-english translation between say a lawyer and an engineer? or perhaps heard of such things?). This translated copy would seemingly be covered by section 0 and all other sections (as incorporated into the defitition of modification)

just a few cents worth
-j.

Re:You are not anal enough either. (IAAL)

[WNight]

You may be a lawyer, but no other lawyers seem to agree with you.

I went across the hall at work yesterday and asked two lawyers who I often see over lunch about this. They said that while "preferred" and such terms are often fairly vague and cases hinge on those, in this case, where you can simply show the inability of the company to use the obfuscated code, and the obfuscating programs used, that it's dead simple.

Too bad modern judges can't hand down rulings that really cut to the heart of the problem...

Ruling that the company must delete all other source code and forever maintain the project using only this source code and other code in this form would quickly show if this was the preferred method. :) When the company goes out of business it'll show they were lying.

(With creative and honest judges we could get by with a lot less of your type.)