A quick note on this note: My musings were not originally going to be for public release, and hence this note isn't as polished as I'd like for a public document. Unfortunately I don't have the time to polish it right now... maybe next week? - Will
There are a few reasons for this comment on the GPL:
All of these questions deal with the interface between GPL software and the surrounding environment. The current GPLv3 draft says that:
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, except its System Libraries, and except general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.and
You may copy and convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: [mechanisms removed]
It is interesting to compare this with the GPLv2 mere-aggregation FAQ:
Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.
Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them.
What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Lets consider a web browser plugin written for the NPAPI web browser plugin API that is publicly available. Most browsers implement this API. We want our plugin source to be available under the GPL. Assuming web browsers are "general-purpose tools", we would probably be allowed to do so.
Now consider a similar situation where instead of a web brower, someone wishes to make a GPL'd plugin to, say, Adobe Photoshop, as these people do. Photoshop is not a System Library, or a general-purpose tool, and it certainly isn't free software. It would seem that while this was possible under the GPLv2, it is no longer possible under the default GPLv3.
It is interesting that plugins and interfaces are also the essence of the Tivoisation issue. If you have a GPLv2 plugin, with a non-GPL main program or hardware, then the containing program can check that the plugin hasn't been modified, and so remove a freedom. It does this by adding an extra mechanism external to the plugin API by which it checks that the GPL'd module hasn't been modified. Under the GPLv3, the definition of Corresponding Source has been expanded to include signing keys, etc. This has provoked some friction with the Linux Kernel developers who are happy to have their code run on a system with such extraneous checks, believing that the market will control such abuses.
A situation where a GPL plugin and signing keys could be useful is a mobile phone. Most transmitters are heavily regulated. You are not allowed to write an arbitrary piece of software for a software controlled radio. One might imagine a system where the govt digitally signed approved software, and the mobile phone hardware would only load appropriately signed binaries. It would still be good to have GPL software in this situation. You are legally not allowed to have freedom 1 where you adapt the program, without govt approval. But you could still use open source development to develop the code, and then submit other versions for approval. With the current default GPLv3, this would not be possible.
Another area of interest is whether it is possible to write a non-GPL plugin for a GPL program.
There are some common areas where this comes up:
With version 2 of the GPL, there was a separate license, the LGPL, used to handle the interaction of GPL'd libraries and non-GPL'd libraries. The draft version 3 of the LGPL incorporates the main GPL license with a specific 'Additional Permissions' section granting the defined exceptions. It is because of this possibility of 'Additional Permissions' that I have used the phrase 'default GPLv3' above. With these additional permissions, many of the things listed above become possible. The main purpose of this comment is to request a 'standard library' of additional permissions to handle the above situations.
For example:
One interesting point here is that it seems that the definition of Corresponding Source as currently defined could be made more restrictive. One could remove the exception, "except its System Libraries, and except general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work", and simply make this a standard additional permission. If someone wished to remove that additional permission then they'd be left with software that could only be run on a completely free system. (You might want to also modify the distribution section so that you can distribute parts of the Corresponding source in different ways: e.g. the OS one way, and the program source another.)
In this formulation, by default, everything that interfaces with the GPL must be GPL. However, additional permissions allow the developer to define interfaces, on the other side of which can sit non-GPL software. Having these interfaces well defined would significantly reduce FUD about the GPL.
In order to make the system of additional permissions workable, I think it would be good to adopt something like the creative commons Deed system, where by standard additional permissions (interface definitions) are selectable. That would mean that people would tend to use the same sets of additional permissions and things would be clear and easy for everyone to understand. The new LGPL is already of a similar form.
I can imagine the following set of 'standard additional permissions':
One might also want to consider including something like the "Or later version" text in the GPL Additional Permissions deed so that these little sub-licenses can be upgraded as necessary without having to upgrade the entire GPL (as the current LGPL does).
It needs to be clarified whether or not additional permissions can override section 3 of the GPL, entitled "No Denying Users' Rights through Technical Measures".