Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
Raul Miller wrote:
On 5/8/05, Michael K. Edwards <m.k.edwards@gmail.com> wrote:
Actually, Raul, I'm impressed. You have found enough ambiguities in
the GPL to exhibit a way to construe limits on dynamic linking and
packaging dependencies that are not far from the FSF FAQ's
prescriptions and Debian's current practices -- though by a completely
different logical path. Namely:
1. Ignore the meaning of "derivative work under copyright law", in
fact strike out the either/or phrase in Section 0 altogether, and take
instead the paraphrase "a work containing the Program or a portion of
it, either verbatim or with modifications and/or translated into
another language". That's a gross distortion of the grammar of that
sentence, and replaces language with a definite, indisputable legal
meaning with an incorrect paraphrase, but that's OK -- RMS says he
could have sworn that he read somewhere that that's what "derivative
work" meant in the first place. And it's not like it's his counsel's
job to explain otherwise to him -- this doesn't come up in law school
or anything.
I belive this step is unnecessary.
The only time a collective work is not a derivative work is when the
the collective work lacks sufficient originality under copyright law
to be granted separate copyright protection.
Come on, Raul: a collective work is NEVER a derivative work. Never ever
ever.
A collective work CONTAINS another works, and is copyrightable per se if
it is intelectually novel by virtue of its selection and disposition of
contents.
A derivative work is the result of an intelectually-novel TRANSFORMATION
of other work. And not, putting it in a bag with other works does not
count as transformation.
Since the GPL is a license grant, it can be construed to only apply
where license needs to be granted.
Separate licenses NEED to be granted to make a collective work and to
make a derivative work. The GPL contains both. The (conditional) grant
to make a derivative work is in section 2, caput, limited by section 2,
a, b, and c. The (unconditional) grant to make a collective work is
given IMHO in section 2, paragraph 3, and you disagree with me on it
(it's the dreaded mere aggregation clause). BTW, I don't think that this
is a no-op: I think that this, combined with sections 5 and 10, they
form the grant to make collective works.
2. Construe "mere aggregation" in section 2, out of thin air, to mean
"coexistence as separate 'files' -- no smaller (contiguous byte
ranges), no larger (entire CD images) -- within the innermost object
on a volume of a storage or distribution medium that can be 'mounted'
as a distinct 'filesystem'". And while you're at it, make it apply to
in-memory copies at run-time too, so that it's a sort of contributory
infringement on the distributor's part for one file to contain
annotations which cause another with a conflicting license to be
loaded together with it at run-time -- but not if it's in a separate
process address space. Oh, and that's also OK if one file is the
Program and another the data on which it operates -- even if that data
is itself program text under a different license. That should be
obvious to anyone, right?
That's not how I construe the mere aggregation clause. Mostly
because you've added a lot of details which need not be
relevant.
SOME detail need to be relevant, because you are not explaining where
your interpretation of the GPL draws the line between mere aggregation
(which I happen to think is another name for collective works) and works
based on the program (which I think is another name for derivative works).
You *seem* (that is the way I am interpreting your quotes up to now) not
to accept that there is a different kind of work (collective, anthology)
that happens to contain another one, and to suppose that there is an
inferior and a superior limit on the "relative size" of things governed
by the GPL when they contain a (whole or part of a) GPL'd work.
M.K.Edwards set those in your discourse as being one filesystem entity
(as in a file) and one filesystem (as in a CD/HD image), but I did not
see those, too. So, I would like you to clarify to me what do you think
are those limits.
IOW: How exactly do you construe the mere aggregation clause? What are
-- exactly, in your opinion -- the technical boundaries of "mere"
aggregation?
3. Read the "mere aggregation" clause, not as an afterthought to
reassure people that the drafter didn't intend to stop them from using
GPL works on Unix systems or putting them together on a distribution
tape with other stuff (which is the actual history as I have read it),
but as a limit on what subset of "works based on the Program" Section
2 is actually intended to cover. It's in the wrong place for that (at
the end of the section after all of the conduct options have been
prescribed), but never mind that -- standards of clarity in grammar
and organization don't apply to the GPL. This isn't a contract, it's
a revolution -- see the 1710 Statute of Anne for details! Implicitly
rewrite each paragraph in Section 2 as if it contained the "mere
aggregation" exception.
I agree that this paragraph fairly accurately conveys the intent
of that clause. It would be easier to read if you'd left out the
editorializing, and I'm not commenting on the accuracy of most
of what you've written here.
It's a pity that you will not comment on the "editorializing", because
it looks like if you really agree with the intent of this clause. But
this goes together with: if everything that contains (in whole or a
piece of) the Program is a "work based on" it, what is the concrete
limit where the aggregation is "mere" or not?
4. Extend the "mere aggregation" exception implicitly to Section 3,
since it contains the parenthetical comment "(or a work based on it,
under Section 2)" in place of the exact phrase "work based on the
Program" that was defined in Section 0. Don't worry about Sections 5
and 6, which use the phrase "work based on the Program" unqualified,
since there's at least one way to read them in which they would have
the same meaning whether or not the "mere aggregation" exception
applies.
In essence, yes.
And yet you cannot see the flaw in your logic? Even if the English
grammar were ultra-flexible, it's not (better yet -- it should not be)
when applied to contracts and other legal texts. There, you MUST use the
formal grammar, and you MUST read those terms under the rules of the
formal grammar.
5. What do you do when the implications of this construction for any
particular piece of FSF software (such as gcc, flex, bison, glibc,
classpath, ...) are too strict? Fudge the license for that particular
piece of software until enough people put aside their reservations and
start using it. The FSF of course can do that because they follow a
strict copyright assignment policy -- none of this "retain copyright
and use the GPL so no one else can weaken it" business for FSF
contributors! Make sure to put in language allowing this fudge to be
"upgraded" to the GPL so you aren't hoist on your own petard, and
discourage other people from using the fudge on their own programs.
Oh yeah, use different fudges on different programs so that they can
only be combined under the GPL. And make sure to keep GNU readline
GPL so that you have an anecdote about how you succeeded in
intimidating somebody way back when into releasing something under the
GPL because they were foolish enough to use your readline
implementation instead of somebody else's.
That's pretty much what the FSF has done -- they've granted
explicit exemptions on on the outputs of these programs. Though,
again, your editorializing detracts from stating these issues
clearly.
No, I don't think the editorializing detracts from it. I am a Free
Software enthusiast, and I respect RMS profoundly. But I do not *trust*
the FSF as I used to, because some of their actions made my trust
thinner, including the below-mentioned DFSG-foo.
6. What do you do when people start using their liberty under your
existing licenses of redistributing only the bits they want out of
your software and documentation, omitting your political speeches
(except the one that you've bolted onto the license itself)? Reissue
under a license (the GFDL) that says they can't do that! What about
the rest of your contributors? Who cares, they assigned their
copyright to you (see above) -- they must have trusted you to do
whatever you want with their work. Oh yeah, make sure people can't
get around it by "upgrading" to the GPL -- if they want to copy and
paste back and forth between program and documentation, they're going
to have to do so under the FSF's wing.
I've no opinion on this issue -- I've not studied it.
You should. And I mean this in the most friendly way possible.
5. The Debian CD set contains lots of non-GPL material that can be
pulled into a process's address space at run-time along with some
piece of GPL material. Hmm, how do we offer all of those run-time
"works" under the GPL so that we dodge that "contributory
infringement" bullet? I know -- implicitly offer every "work"
containing GPL material that can be constructed at run-time from
Debian packages under the GPL, in addition to whatever less
restrictive license the other bits are documented as having. That way
the end user has the option of accepting the GPL on, say, the net-snmp
libraries when they form part of a "work based on the Program (but not
formed by mere aggregation)", such as when they happen to be running
inside Quagga, and also of accepting their upstream license when
they're running inside a net-snmp command-line tool. Don't bother
identifying which components are implicitly dual-licensed this way;
everyone knows which licenses can be "upgraded" to the GPL, and they
must know that's what you meant because otherwise you wouldn't have
been permitted to release Debian CDs at all.
This doesn't seem to be put together logically. Appearing in VM
seems to me to fall under mere aggregation unless there's also
some specific use of non-exported functionality.
How so? You did not explain what are the technical boundaries of
"mere"-ness for the aggregation, and I would like you to elaborate on it.
8. What about the "automatic termination" clause, which has of course
magically happened to Debian a zillion times over (such as when Quagga
got built against net-snmp on some Debian autobuilder and thus against
libssl)? Oh, don't worry about that -- we only use that to try to
club people whom we don't like because they don't construe our license
the same way.
Huh?
IOW, asking M.K.Edwards for his permission:
1. the automatic termination clause is abusive;
2. if it's valid, and if your interpretation of the GPL is correct, the
GPL was automatically terminated via clause 4 many times over debian.
OK, so there's a way to construe the GPL to ban dynamic linking to
non-GPL-compatible material. Completely far-fetched, in my view. But
I think I'll stick to the contention that contracts are to be
construed against the offeror and that it is my, perfectly reasonable,
interpretation that the outermost boundary of a "work based on the
Program" is the smallest identifiable self-contained work of
authorship (such as a library with a published API) that is itself a
derivative work of the Program. Build bigger programs based on this
block any way you want, linking statically, dynamically, and
Republicratically. Any other customarily observed limitation is a
matter of conflict avoidance and courtesy to the FSF in homage to the
role it once played in opening up the software commons.
This seems to be based on a concept of "derivative works" which
is at odds with that held by the U.S. Copyright office.
But not with Berne convention, in principle? My knowledge of US
Copyright office memos and circulars is not very good, but my knowledge
and research of Brazilian Authors' Rights Law [9610/98], Computer
Programs Law [9609/98], and Industrial Property (=trademarks+patents)
Law [9279/96] is very reasonable in my (paralegal) grasp.
I highly recommend you read circular 14, and pay particular
attention to the examples which use the phrase "based on".
Could you please quote -- with a reasonable amount of context -- said
examples, so those of us who do not have any access to search them can
verify what you are saying?
HTH,
Massa
Reply to: