A Group Conversation with Eben Moglen, Part II - page 5
Software as Service and GPL 3
Question: Is there any provision on GPL V3 regarding linking? I'm not a lawyer so bear with me; from what I've understood there was always some conflict or some different opinion between what happens when you link with GCC statically or dynamically regarding what your source code should be in the GPL, or not. And I don't think this question has always been clearly answered.
Moglen: I think the question was largely an imposition of uncertainty by outside forces and myself. But what GPL3 did to attempt to resolve it in this very sentence that Mark was asking about the definition of corresponding source code says that the corresponding source code to a work includes all those libraries linked statically or dynamically, which the work requires an order to run that are not system libraries. So the answer to your question, we hope, is this time clear; the Foundation always believed and continues to believe that codes statically linked to other code can be part of a single combined work. Where it is part of a single combined work you need copyright permission to copy, modify, or redistribute that work as a whole. And if you distribute it in ways which are--which have the result of reducing other people's rights below you're either infringing or you're secularly liable for infringement. The requirement would be to prove that the dynamically linked work is--despite the dynamic linking situation in which the code establishes its connections--nonetheless part of a single work.
Are there times when from a copyright law point of view you would find code dynamically linked to other code--part of a single work? Yes; I have no doubt. If you take a thing which is an intrinsically single program and you split it in half and put half its routines into something which then is linked together to make it share the library, and you run the executable with half the routines against it, and they share their control blocks in a completely indiscriminate fashion, and they write in one another's memory areas --if the only thing that happens is every jump instruction reads a table first to figure out where to go to, then nothing has happened from a copyright law point of view that should change our judgment about what's going to work and what isn't.
At the same time, if it is clear that that dynamically linked library exists for hundreds of purposes, that there are other substitute dynamically linked libraries which could have been used instead right--I use readln sometimes but Ted doesn't use readln; he wishes to use something else and the thing that he wishes to use is a complete substitute for readln and then there's no way in the world that one would want to say that those two dynamically linked activities are part of the same work.
So I think that the static linking, dynamic linking distinction was under-specified. What it should have said was static linking is a necessary and sufficient condition to find the presence of a single work. Dynamic linking is neither necessary nor sufficient but a dynamically linked work may be either a separate and independent work with outside the boundaries of GPL or part of the same overall work requiring treatment under GPL and it is the facts of how the programs or routines communicate, which makes the difference.
Question: You need to tell the Debian mechanical interpretation league that.
Moglen: No; you need to get agreements with the Debian mechanical interpretation league. Merely telling it something is not sufficient. And convincing is hard as you know.
But I agree with you that it would be a bad idea to try to get mechanical interpretation here. One of the basic problems that we confront is that the unit of copyright law is a thing called The Work and that's not a unit of computer science in whatever form computer science shows up this morning. Sometimes computer science shows up with modules or routines; sometimes it comes with objects or soap, but whatever computer science is selling today it isn't the Work. So there's an intrinsic mismatch in the quanta of the two areas.
And because the quanta are never in any way coincident, mechanical interpretation, attempting to map copyright law into computer programs or computer programs into copyright law will fail. This is not a theoretical proposition beyond proof; you can show this comparatively easily, but the pressure for mechanical interpretation by engineers of legal material is perfectly understandable.
Legal material otherwise behaves in a fashion that engineers hate; it's non-linear. It's affected by environment in all kinds of weird ways; every answer is it depends. Stresses are not calculable; effects of forces are unknown, right? No engineer in her right mind wants to work with materials like that. And faced with materials like that, the engineer's overwhelming impulse is to apply some chemical, mechanical, or electrical process to render the stuff tractable. The Debian legal mechanical interpretation machine is an attempt to render legal material tractable by yelling it. It doesn't work. But you can understand why people try. Every parent knows. So this is the problem then, and we're all going to face it forever. It's why early legal help is like yeast. You just got to get there early in the life of the dispute and say, look, we don't have to try and shock the material into submission. There's a way of talking about this within our two cultures that will work, but that's tough labor. Anything else? All right; well, thank you very much for your time.
- 1Linux Top 3: Network Security Toolkit, Untangle NG Firewall and IPFire
- 2Linux Top 3: Fedora 24, Peppermint 7 and Solus 1.2
- 3Linux Top 3: Alpine Linux 3.4, deepin 15.2 and Linux Lite 3.0
- 4Linux 4.7 Set to Boost Live Patching, Security and Power Management
- 5Linux 4.6 Charred Weasel adds USB 3.1 Support