The StorageTek DMCA decision

Posted Sep 1, 2005 21:55 UTC (Thu) by kevinbsmith (guest, #4778)
In reply to: The StorageTek DMCA decision by lutchann
Parent article: The StorageTek DMCA decision

I could be wrong, but I don't think the GPL prevents linking with proprietary binaries. It prevents distributing code that does binary linking (that's a vague hand-waving phrase because I don't have time to research and compose precise wording). It's the distribution that's covered by copyright, not the execution (or "use").

I trust someone with more legal/GPL expertise will clarify this.

The StorageTek DMCA decision

Posted Sep 1, 2005 23:06 UTC (Thu) by lutchann (subscriber, #8872) [Link] (4 responses)

The FSF asserts that the act of executing a dynamically-linked program, which causes the program plus libraries to be loaded into the same address space, creates a derived work. This results in the strange situation in which the proprietary software vendor (who linked their proprietary code against a GPL'd library, for example) is not violating the GPL by distributing their proprietary executable, but all of their users are by running it. The FSF resolves this by making the dubious claim that dynamically-linked executables constitute a derived work if they link against a GPL'd library even if no GPL'd code is compiled into the executable.

There has been a lot of speculation as to whether this would hold up in court, and I don't personally think it would. If not, the result would be that the GPL would be more or less equivalent to the LGPL, and anybody could combine GPL'd code into their proprietary apps simply by turning it into a shared library. Of course, the question of whether binary-only Linux kernel modules are legal would be resolved once and for all.

The FSF will probably clarify the dynamic linking restriction in GPLv3, and the fact that copyright covers the act of executing the program is the only basis they'd have for making this enforcable without turning the GPL into a contract, which wouldn't be practical. That's more of what I was getting at with my original comment.

Unfortunately, it's not clear that this can be easily resolved in GPLv3, since the definition of "dynamic linking" is pretty vague these days. RPC allows function calls between different address spaces (and hosts even), MMU-less systems load all their executables into the same address space, and virtualization even makes the concepts of "loading" and "running" vague. I expect that GPLv3 will be much longer than v2.

As an aside, it's really too bad that litigation in modern times is so expensive that most copyright disputes are settled out of court. We really need case law to catch up to the state of the art.

(Usual disclaimer: I am not a lawyer. I have had no legal training. Seek the advice of a qualified attorney or tax professional. Past performance is not an indication of future results. May contain peanuts.)

The StorageTek DMCA decision

Posted Sep 1, 2005 23:59 UTC (Thu) by giraffedata (guest, #1954) [Link] (1 responses)

I agree that the idea that copyright law lets the author control loading into memory for execution is nonsense. (It really isn't much different from creating a copy of a book page on your retina for the purpose of reading it). Mine isn't a legal opinion either.

But does that make GPL the same as LGPL? LGPL lets you _statically_ link the licensed material with some other stuff into a single executable and distribute that executable without licensing the whole thing under LGPL, doesn't it? GPL does not.

The StorageTek DMCA decision

Posted Sep 2, 2005 1:40 UTC (Fri) by lutchann (subscriber, #8872) [Link]

Well, I did say "more or less". :-) You're right, technically the LGPL would still be more permissive since statically linking to GPL'd code and distributing it would be a clear copyright/license violation. It's been years since I've seen a vendor satisfy LGPL requirements by distributing the unlinked object files, though, so I think the net effect would be the same.

The StorageTek DMCA decision

Posted Sep 2, 2005 4:05 UTC (Fri) by kevinbsmith (guest, #4778) [Link] (1 responses)

I know the FSF believes that binary dynamic linking creates a derived work. However, it does not necessarily follow that the act of executing such a work would violate the GPL. Do you have any links where I could read more about that claim?

Right near the top of the GPL, we see: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted..."

My interpretation remains that one could create a derived work (e.g. something dynamically linked), and could run it on their own computer for their own use. But they could not distribute it to anyone else, except under a GPL-compatible license.

Kevin (also definitely not a lawyer)

The StorageTek DMCA decision

Posted Sep 2, 2005 15:11 UTC (Fri) by lutchann (subscriber, #8872) [Link]

Ahh, OK, I spent some quality time with Google this morning and it looks like my facts are about 30 years out of date. The Copyright Act of 1976 specifically exempted the act of copying executable code into memory for the purpose of executing it from copyright protection. See this Q&A by Lawrence Rosen:

http://www.linuxjournal.com/article/4754

This casts serious doubt, in my mind, that any copyright license (i.e. not a commercial-software-style license agreement, which is governed by contract law), could have any basis for precluding dynamic linking. Again, I sure wish we could see how this would play out in court.