Does the GPL have any teeth?

Posted 15 Aug 2000 at 18:52 UTC by advogato Share This

A disturbing thread came up at the recent VA Printing Summit. Under one interpretation of the GPL, dynamic linking of proprietary and GPL'ed code is allowed. If this is the case, then is dynamic linking a hole big enough to fly a spaceship through?

The Gnu GPL clearly forbids distribution of a binary containing both GPL code and proprietary code, as this binary constitutes a derived work. However, with dynamic linking, there is no single binary to point to as the derived work. Instead, the two separate object files, each with their own license intact, get delivered to the user, and only get combined when the program is actually run.

There is a context in which this loophole may actually be useful for some people - when manufacturers wish to provide drivers without revealing secrets which they may consider valuable. We've seen lots of binary-only drivers from both XFree86 and the Linux kernel. Happily, in most cases these binary-only drivers are simply a stepping stone to full source drivers released under an open source license.

The Linux kernel, which is GPL'ed, has an explicit policy of allowing these binary-only drivers, and also has a kernel module system that facilitates the release. On the other hand, Linux doesn't go the extra step of promising stable binary API's. Thus, the incentive to release as source is pretty strong.

Another example, the Alsa project, has essentially the same policy as the Linux kernel; binary modules are expressly permitted, but discouraged. As in Linux, no promise is made of a stable binary interface. The Alsa website has an excellent discussion of these issues.

However, a GPL program loading proprietary modules is not what concerns me today. Rather, I'm most worried about a proprietary program loading a GPL'ed library.

For example, if somebody wanted to create a highly retargetable yet proprietary C# compiler, a proprietary front end might simply dynamically load GCC, then call the appropriate functions to optimize, generate object code, etc.

This prospect disturbs me greatly, both because of the prospect of GPL software being plundered by the proprietary world, and because it could interfere dramatically with the dual licensing plan I have for Libart: all development done immediately on the GPL version, but with a proprietary license also available for a fee. I fear that this loophole may seriously cut into the incentive for software to be developed in this way.

I see linking rights as a spectrum, with distribution of statically linked binaries on one end and fork/exec() on the other. Most any reasonable person would agree that the GPL prevents the former but allows the latter (even if techniques like CORBA are used to intertwingle the two processes). However, for at least one stop in the middle, loading of dynamically linked modules. I feel the issues are a little less clearcut. The LGPL allows this. What's not clear to me is whether the GPL provides substantially different protections in this case.

A further distinction that might be worth considering is whether the binary modules are packaged together (on the same CD, for example), or separately. In the case of a hardware driver, for example, the manufacturer may include a disk with the binary driver only, stating "works with Red Hat 6.2" or somesuch.

Thus, I'm interested in the following questions:

1. Am I missing something in assuming that the GPL may contain this loophole? The issue here is not what we want to be the case, but something that would actually convince lawyer-types.

2. What are the constraints on a license to prevent linking with proprietary code? Is there a solution to these constraints that's also consistent with the Debian Free Software Guidelines? Clause 9 looks the most relevant here.

3. If so, is it possible that a future version of the GPL might do so?

I ask for informed discussion only, please. Speculation and your standard licensing flamewars are not welcome. Thanks.


the changing meaning of linking, posted 15 Aug 2000 at 20:44 UTC by stefan » (Master)

As technology evolves further, the goals of a GPL like license have to be rephrased. I'm thinking of CORBA and its possibilities to tightly bind foreign components into a 'distributed program'.
It is certainly an important question what the current version of the GPL allows. However, we must ultimately define ourselfs what we want and then reformulate the GPL to reflect these changes. I think this has already been discussed with RMS.

I think it is in accordance with the goal of the GPL if the term linking is extended to shared libraries and even remote CORBA components. The goal is (IMO) to keep all new tools which are created by means of a GPL'ed component as free as the original part. Whether this part be formed by via static or dynamic linking, or via some other way of communication.
My emphasis is on tool, i.e. I think what is to be protected by this interpretation is the freedom to use and extend a means of production. The outcome (for example if the tool is a compiler) doesn't need to be concerned by it.

I ask for informed discussion only, please. Speculation and your standard licensing flamewars are not welcome. Thanks.

Fine. Just to clarify my thoughts: I'm not implying that I would necessarily use such a modified GPL in all my work. I'm merely pondering about the original goal the GPL was written in and how to conserve that while the problems it technically attacks, change.

court case to determine if symbolic linking is usage or derivation, posted 15 Aug 2000 at 20:58 UTC by sej » (Master)

It will take court cases to determine if symbolic linking is usage or derivation (or whether the line between usage and derivation needs be drawn elsewhere, like the difference between library calls and framework inheritance). The FSF seems purposefully vague about the meaning of derivation as used in the GPL, as a means to maximizing the effectiveness of the license. Conversely the FSF is quite explicit in drawing a similar boundary in the LGPL. They can do it when they want to.

Which components of libart are GPL, and which are LGPL? Does the GNOME canvas use GPL portions of libart?

Also applies to non-traditional applications, posted 15 Aug 2000 at 21:03 UTC by flaggz » (Journeyer)

I was arguing nearly this very issue yesterday over lunch with some friends. The discussion drifted towards licensing, and I claimed that proprietary web based applications (such as those being touted by Microsoft's .NET) should _not_ be able to link/include GPL'd code. My friend countered and said that the GPL specifically requires binary distribution, and since web based remote execution is not binary distribution, the GPL does not protect authors or users in this case.

I agree on a literal basis, but this really seems to violate the spirit of the GPL. The way I see it, the GPL or some similar license should enforce compliance any time the code is used(distributed) outside of a closed group. Language about linking/distribution methods just pollute the spirit the license is attempting to communicate.

In response to advogato's questions:

> Am I missing something in assuming that the GPL may contain this
> loophole? The issue here is not what we want to be the case, but
> something that would actually convince lawyer-types.

No, I don't think you are missing anything. My friend was right, the language clearly states binary distribution is required.

> What are the constraints on a license to prevent linking with
> proprietary code? Is there a solution to these constraints that's
> also consistent with the Debian Free Software Guidelines? Clause 9
> looks the most relevant here.

I feel that the license should not get entagled in technical issues of code inclusion, but rather state that if a piece of software depends on another to operate then it must fall under the terms of this license.

I've always thought this was the main philosophical distinction between the GPL and the LGPL. The GPL should require any software depending on a GPL'd piece of code to adhere to the license. The LGPL makes no such demand.

> If so, is it possible that a future version of the GPL might do so?

I doubt it. I would imagine the concept of 'this depends on that' is too nebulous for the legal community.

Libart, posted 15 Aug 2000 at 22:10 UTC by raph » (Master)

sej: we're not talking about symbolic linking here, but dynamic linking. Two different beasts.

Most of Libart is now LGPL, including all parts used by the Gnome Canvas. There are some components under development that are GPL'ed (like some advanced spline things). I might put the PDF 1.4 blending code under GPL too. So far, I've very much been feeling my way as I go forward.

GPL section 2, posted 16 Aug 2000 at 00:31 UTC by lauris » (Master)

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
I seems almost clear to me.

If your program cannot work without certain GPL libraries, it cannot be considered independent and separate piece of code - and has to be licensed under GPL. The only exception being the well known operating system clause.

If there exist some library, functionally identical to GPL one, and under license allowing linking your code to it, and distributable together with your code then your code is separate and independent. And in that case you can distribute GPL library together with your code and other library, and allow user to choose, whether to link with it, or other library (well, at least you cannot forbid user doing that).

Do the simple test: remove all GPL programs, except those falling under "operating system" clause. If you program still can execute and fill its main function, it is independent. So if you have mail reader, using some GPL program (through pipe for example) for displaying images, it can be considered independent. If it uses GPL program for simply displaying messages, it certainly is not.

Re: GPL section 2, posted 16 Aug 2000 at 00:59 UTC by jmg » (Master)

But what if you create a stub library that just returns false for all the calls of the GPL'd library. You can link with the stub library and the program would still be runable.

The argument that the non-GPL'd library has to be fully functional is not stated in the license. I, as a software author, have every right to write a 100k line application and the only thing it does is print out "Hello, World." There is nothing in the GPL that can protect a library from this.

Spaceships are flying through already., posted 16 Aug 2000 at 04:18 UTC by shawn » (Master)

I've had some discussions with RMS via e-mail about similar issues, to try and determine if the GPL on certain GIMP plugins was being violated. If you use dlopen(), he seemed to indicate it would rely on the complexity of the interfaces used between the main program and the object code. There is certainly no definitive or easy answer.

The way GIMP is architected, plugins are execvp()'d from a LGPL library. So the plugins are external programs to the main core. This makes it very easy for proprietary companies to simply modify the GPL'd plugins, and provide all the stuff they used to do it (so we can recompile them).

A prime example of this is HumanTouch's product Easel which runs on BeOS. Their website is http://www.humantouch- inc.com/. They have a link with info on GIMP filters (which did not exist back in September when I was trying to determine the legality). Read it, and be amazed at GPL GIMP filters being run by a proprietary program.

I'm not sure if the GIMP Filters on Easel's web page are even executed as seperate processes anymore. I think they might just be dynamically loaded with the BeOS equivalant of dlopen(). It would probably be easy to determine now, as the package they have up there sounds more complete than what I received in September. Maybe someone else would like to take a look.

The GPL seems pretty worthless right about now.

err, dynamic linking, posted 16 Aug 2000 at 05:10 UTC by sej » (Master)

Err, I meant dynamic linking, not symbolic linking. Somehow "shared library" and "dynamic linking" got melded in my brain, and the inaccurate "symbolic linking" came out. After too many years of programming in isolation English is no longer my first language :-).

modification would create a shrinkwrap licence?, posted 16 Aug 2000 at 09:34 UTC by cannam » (Master)

The GPL depends upon an existing concept of a derived work, found in copyright case law. Problems like this one arise because it's increasingly unclear what constitutes a derived work, because this case law has not been well tested against programs. (I suspect this is true regardless of what the GPL says about independent and separate works: the GPL does not make copyright law.)

The power of the GPL comes from making a specific relaxation of normal copyright restrictions (in contrast to a shrinkwrap licence, which extends copyright by restricting use as well as distribution). However, the normal copyright for a work only applies to another work when the second work is derived from the first.

Thus, if the GPL is found not to apply to a program because that program is not a derived work, then no other licence that works by relaxing copyright can apply either: if program B is not derived from program A, the copyright of A is quite irrelevant to B. The only way to "fix" the GPL so as to make it apply to program B at all would be to make it restrict use as well as distribution -- in other words, to make it a shrinkwrap licence.

That said, if there genuinely is no case law that applies to this sort of dependency, then at some point some will have to be made. At that point a test like lauris's for establishing whether something is independent or not would be a reasonable one to use; the problem is that it's already usually accepted that fork() does not create a derived work, whereas by lauris's definition it might. Legal cases do have a tendency to hinge upon what is already accepted.

proprietary apps using GPL libraries, posted 16 Aug 2000 at 11:29 UTC by jamesh » (Master)

If you do get a case where a proprietary app is using a GPL'd library, chances are that the app is using some of those headers distributed with the library, which should have GPL notices at the top. Those bits of code (even though they are just declarations, they are still code) are certainly linked to the app, which is definitely a breach of the licence with no dynamic linking issues to cloud things. In any case, I think it is against the intent of the GPL for this to be allowed.

Another interesting question is what happens if I put a GPL notice at the top of an IDL file describing a CORBA interface, would it be ilegal for proprietary programs to use that interface? The stubs generated from the IDL certainly have the idl as source, and would be linked into the proprietary program. Could a proprietary program get around this using the dynamic invocation interface (ie. no code from the GPL'd IDL is included in the app), or would these DII calls be derivatives of the IDL? Is this a way to protect our Free Software as we move towards component based systems?

Re: proprietary apps using GPL libraries, posted 16 Aug 2000 at 12:02 UTC by cannam » (Master)

jamesh:
> what happens if I put a GPL notice at the top of an IDL file
> describing a CORBA interface, would it be ilegal for proprietary
> programs to use that interface?

That's got me quite confused.

Thinking the other way around, if the IDL file was published under some pernicious proprietary shrinkwrap licence as part of a commercial product, could you legally write code to that interface without regarding the licencing terms of the product?

I had thought that writing code to talk a particular protocol or use a particular file-format was legal regardless of the licencing terms of the program where the protocol or format originated (disregarding those weird new American laws for the moment), because the protocol or format was seen as clearly a public interface that must be available for interoperability. Yet an IDL file and even a conventional header file are clearly also intended to be public interfaces, which suggests you can't effectively licence them at all.

I think we're suffering from Slashdot-style we-are-not-lawyers syndrome here.

GPL, headers, and copyright, posted 16 Aug 2000 at 12:31 UTC by eivind » (Master)

jamesh, please do not talk about how copyright works without knowing the relevant precedents. No, the declarations are not code. The precedents are that interfaces are not copyrightable. This again would most likely make dynamic linking avoid the derived work problem - though if the library is made only to avoid that (so the interface is hapzard and another implementation would be a waste), I suspect that a court might rule otherwise. If the interface is well crafted and would be a generically useful library, I believe a consumer of the library would not be considered a derived work.

Whether this is a good (my opinion) or a bad thing is a separate discussion.

Eivind.

Re: GPL, headers, and copyright, posted 16 Aug 2000 at 15:16 UTC by bernhard » (Master)

It seems to me that you could use header-files to force the GPL on a program that links dynamically to a GPL'ed library. The declarations alone don't do that but complex macros might if a program uses one of them. With C++ this becomes even easier because inline functions/methods and template functions and classes must be defined in the header-files and they're expanded in the program if they're actually used so that the program itself becomes a derivative work.

It's possible for the library user to work around the macro problem by defining functions that do the same things and putting them into a derivative of the library and link dynamically to that. This would perhaps even be possible for the C++ constructs but it would be considerably more inconvenient than for macros.

The rpc trick, posted 16 Aug 2000 at 17:17 UTC by imp » (Master)

I talked with Tom Christianson a few years ago while helping a buddy move about this concept. He doesn't like the GPL for a variety of reasons and came up with an interesting way around it: rpc.

take an rpc implementation (say sun's). When you want to use an interface, you connect to yourself at a well known port (or better yet a pipe) and talk over it with rpc (either Sun's, or your own). That way the GPL contaminated sources live in a different address space and there isn't even dynamic linking. You distribute the source to this server, which is basically useless to most people because all it does is wrap the functionality.

He allowed as how you would also have to create a minimally functional library to provide the same API/ABI as the gnu one. This would free you from any possible claim that your program could not work without the gnu library. He said it didn't matter if this library was less featureful than the gnu one, only that your program had to work, for some accepted definition of work, with it.

This is a lot of work the first time, but once you have a framework in place, it should be relatively easy to do other libraries.

In theory, one could do this to gcc, so long as you release the sources to the gcc backend that you've hacked to do this. If you talk to it over a pipe, then you are in a separate address space. You'd likely have to release the communications routines for that pipe, but even that might not be that huge a deal since you could release them under a license compatible with inclusion in a GPL program (eg BSD's or phk's beerware license), but a license that wouldn't force you to release your proprietary code (or just dual license it, same code, GPL for one program, your propritary one for another). You could then write a c# front end and keep it proprietary and still be within the letter of the GPL. It would take a court case, I think, to clear this matter up.

Of course that's the big problem with GPL. There's too little case law to support it or the legal theories that underpin it.

GPL becomes the industry standard, posted 17 Aug 2000 at 01:45 UTC by atai » (Journeyer)

While not exactly on topic, it is great to see the GPL is becoming the industry standard license. The Mozilla group has announced they will dual license Mozilla under the GPL and the MPL. The GPL is more important than ever...

The LGPL is still solid, posted 17 Aug 2000 at 02:27 UTC by Bram » (Master)

LGPL, which is only viral to direct derivative works rather than linked things, is on much more secure legal footing.

It's quite possible that in court tests the GPL will be hammered down to be a bit more LGPL-like, but suspect the LPGL will survive mostly unscathed.

I prefer LGPL on general 'reasonableness' grounds - it's too bad that RMS is calling it the 'lesser' GPL now instead of the 'library' GPL.

Re: The LGPL is still solid, posted 17 Aug 2000 at 15:16 UTC by bagder » (Master)

Regarding the solidness of LGPL.

Please read paragraph (3) of the LGPL once more. It gives the right to anyone, at any time, to change the license over to GPL. What strikes me is that I haven't yet heard anyone bring up a case when that would be useful (in other ways than to "hurt" closed-source programs or similar that use the library). Especially since RMS claims LGPL and GPL are "compatible" allowing you to copy and paste source code between projects using either of those licenses.

No, I am not a friend of the "viral" aspects of GPL.

Re: The LGPL is still solid , posted 17 Aug 2000 at 16:19 UTC by bernhard » (Master)

badger:
Please read paragraph (3) of the LGPL once more. It gives the right to anyone, at any time, to change the license over to GPL. What strikes me is that I haven't yet heard anyone bring up a case when that would be useful [...]. Especially since RMS claims LGPL and GPL are "compatible" allowing you to copy and paste source code between projects using either of those licenses.

As far as I can tell, this clause is there precisely so that LGPL code can be used in a GPL program. The other direction is not possible, though. If you copy GPL source into LGPL'ed code that code must also be put under the GPL.

In a way, this is explicitly stated in the same paragraph (3) of the LGPL:

Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.

Re: The LGPL is still solid, posted 17 Aug 2000 at 16:54 UTC by bagder » (Master)

bernard wrote:

    As far as I can tell, this clause is there precisely so that LGPL code can be used in a GPL program. The other direction is not possible, though.

Hm, true, that section probably the reason why they are "compatible". I still think it [*beep*].

When you release your software as LGPL it must be since you want it to be more lax about being used in non-GPL software. Still that clause is there to at any time allow anyone to put harder restrictions on the software than you intend when you release it as LGPL...

Or can it be seen differently?

Re: The LGPL is still solid, posted 17 Aug 2000 at 19:56 UTC by bernhard » (Master)

badger wrote:
When you release your software as LGPL it must be since you want it to be more lax about being used in non-GPL software. Still that clause is there to at any time allow anyone to put harder restrictions on the software than you intend when you release it as LGPL...

Yes. Unfortunately, any GPL compatible license must allow the recipient of the code to rerelease the code under GPL, otherwise it wouldn't be GPL compatible. The road to GPL is a one way street.

License? Community?, posted 22 Aug 2000 at 02:26 UTC by lilo » (Master)

It seems to me that the most important aspect of free software is not the license, but the community. Licenses can be considered contracts in some sense, but the weak link in a contract between two entities is usually the third entity implicit in the contract, i.e., the government under whose laws the contract is enforced.

The more a free software license tries to do, the more likely it is for significant license features to be interpreted out from under the participants via the courts.

The key element is the community which responds to such problems by, if need be, coming up with new licenses and new modes of interaction. Let's not fall into the trap of thinking that the formalisms we live with are the soul of the community. They are merely one expression.

everything is a process, posted 24 Aug 2000 at 14:08 UTC by cmm » (Journeyer)

lilo writes how the specific license text is just a formalism, and what matters is the community.

there also is the phrase (don't remember by whom): security is a process.

there's also the saying: love is what you make it.

and here's my generalization for today: everything lasting is a process.

I only waste the bandwidth because I think the above generalization is very important, and because too many people in the Free Software community prefer not to view things this way and find it more comfortable to obsess over small stupid things. (like overgeneralizing insignificant aspects of their pet projects. or worrying too much about licensing. also, the sheer amount of people here that seem utterly brainwashed by the XML hype is, well, symptomatic of the same geek escapism).

well, enough rambling for now.

GPL Interface Copyrights?, posted 26 Aug 2000 at 20:13 UTC by argent » (Master)

This is all very interesting.

A few years ago a commercial crypto application tried to use a GPLed library (the details have been lost to my memory), but at the time RMS claimed that if you linked to an interface for a library that was only available in GPLed form, then in his opinion you were making a derivitive work. Even if you used a stub library to do the linking.

The only way I could see this working was that he was claiming a copyright on the interface itself. Which of course makes things hard for him when he wears his LPF hat... but of course he doesn't see the conflict.

Now it sounds like he's had to soften this stance... and of course you're absolutely right. Dynamic linking does provide a hermetic seal which can be used to bottle up the GPL.

And since you can take *any* GPL work and wrap an API around it, then link to it from a commercial application, I don't think that the GPL does have any teeth if someone is sufficiently well motivated to violate the intent of the document.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page