Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
> Raul Miller wrote:
> >And, if you allow the full definition of a "work based on the Program"
> >from section 0 of the GPL to apply, it's clear that when these
> >collective works are being protected as intellectual creations that
> >you're talking about a "work based on the Program" and so can
> >be granted license by the GPL.
On 5/10/05, Humberto Massa <humberto.massa@almg.gov.br> wrote:
> Raul, I will say that many times before in -legal I agreed with you --
> this time is not one of those, unfortunately. I have a great deal of
> respect for you and I want to re-state that I am not arguing with you,
> but with your particular arguments about your reading of the GPL.
Thank you. I think.
> That aside, I will try to chart my personal, based on my law experience,
> points about the whole issue:
>
> 1. Brazilian Law reads the concepts of "anthology works", "collective
> works" and "derivative works" separately and disjointly.
I believe you mean "searately and distinctly". Disjoint means "having
no elements in common".
> A single work
> cannot be more than one of the above three at the same time; usually
> what happens is that you have a derivative of an anthology or an
> anthology that contains a derivative.
Are you saying that an anthology is not a single work? Because that's
about the closest I can come to making sense of this sentence. If you're
saying that "collective works" and "anthology works" cannot be "single
works" then they can only be "derivative works" and the example you
present (a derivative of an anthology, or an anthology that contains a
derivative) doesn't count as examples involving single works and
therefore can't be a single work that's both a derivative and an anthology.
But that really has nothing to do with your assertion that "ennumerated
items in Brazilian law are disjoint". That interpretation is based on the
idea that only one of the ennumerated items can be relevant, because
you've excluded the other two.
This might be a translation issue -- it might very well be that you're thinking
something which makes sense, but that the words you're using don't
match up with the thoughts you're thinking.
> 3. The disputed (by me and you, at least) phrase in clause 0 would be
> most probably read (by a Brazilian Judge at least) as a definition of
> "work based on the Program" as begin "derivative work". The part after
> the colon would be striked out as an (incorrect) example or explanation,
> because the judge would be compelled to use the most strict definition,
> that is, the most advantageous for the licensee.
You might be right -- I have no knowledge of Brazilian law. However,
since I only have your assertions to go on, and because I can see
what might be translation problems interfering with our exchange of
ideas, it might be that there are similar problems with this prediction.
At the very least, if I were involved in a GPL legal case in a
Brazilian court, I'd want to have the assistance of people skilled
in translating legal concepts from english to portuguese, and I'd
also want the services of a good Brazilian lawyer.
> 4. The grant to distribute anthological and collective works would be
> given by section 1, combined with section 2, paragraph 3 (the dreaded
> mere aggregation one), and sections 5 and 10. So, these are not no-ops.
> They are a broad grant to distribute anthological and collective works,
> notwithstanding the "mere" word.
You've asserted that Section 0 does not come into play, but that means
that the GPL does not grant you rights for these cases.
> 4.a. A Brazilian Judge would strike the "mere" word out, for lack of a
> practical definition. What constitutes mere aggregation as opposed to
> "non-mere" aggregation? This is an impossible question.
http://www.answers.com/mere
"Mere aggregation" means aggregation is a factor, but no other factors
mentioned in the license -- no other factors which are not
aggregation, I mean -- are relevant.
> Which lead me to a conclusion similar to Linus Torvalds' one, about
> kernel loadable modules:
I think it's possible to reach that conclusion without following this path.
For example, there's no need to strike the word "mere".
> 5. The fact of linking and #include'ing a file from another work does
> not make your work a derivative work, nor obligates you in any way to
> put your work under the terms of the GPL, when the original work is
> licensed undef such terms. It's the creative content of your work that
> will determine (and there are the abstraction, filtration and comparison
> tests to assert) the derivative status of a work.
When resolving the question of whether a work can be distributed legally
under copyright law, there are a series of questions you have to ask:
First, is this a work which is protected by copyright law? In other words,
is it a creative expression in tangible form? If not, none of the rest of
these questions are relevant.
If it is a protected work, who holds copyright? To answer this question,
you need to consider the origin(s) of the work. If the work has multiple
copyright holders another question is their work as a whole is
copyright protected, or whether the work can be separated into
distinct entities and considered separately.
What does the license allow? Once you've identified that the works
are copyrighted, and you've identified the copyright holders, you can
recognize which licenses are relevant, you can begin discussing
whether or not the terms of those licenses are being satisfied, and
whether the permissions granted in those licenses are relevant.
And, finally, does the copyright holder care? The rights in question
belong to the copyright holder, but many minor transgressions on
those rights don't matter to many copyright holders. It takes time and
energy to pursue these cases, and in many cases the reward for
pusuing violations isn't worth enough to the copyright holder for it
to be an issue.
In practice, these issues tend to come into play in reverse order,
with the copyright holder making a legal assertion and someone
(perhaps a court) judging whether or not copyright law backs up
this assertion.
In any event, if copyright is an issue, #including a file is just
a part of what was involved in the case in question. In and of
itself, #including a file is not a tangible expression of a
creative work. So, in and of itself, #including a file is not
something which is protected by copyright law. But in
real life people can #include a file as a part of a copyrighted
work.
> 6. There is the issue of the APIs being "uncopyrightable". Ok, I will
> try to define it correctly: the bits and pieces that one computer
> program/library pulls from another computer program/library, binary or
> source, in order to define a boundary of interconnection, are not
> protected by copyrights. The work (such as errno.h) is still
> copyrightable, only the bits and pieces that were pulled from it, and
> similar expressions of the same interface, are considered not infringing.
>
> 6.a. In Brasil, this is stated in our Computer Programs Law, article 6
> (too long to quote)
Sure, but this is a fairly narrow exception. When someone
grants other people permission to use the API that, in
effect, is a copyright grant on the use of that API.
> 7. This (number 6 above) is relevant because even when a work is
> dynamically linked, the binary contains parts of libraries and/or
> headers that were not "included" in the source nor make a part of it,
> but they are "pulled in" (in a grinded form, possibly) into the binary.
> What I am arguing here is that these bits are not protected, and
> henceforth the binary's derivative/collective/anthology status is
> unchanged by this process.
Sure, but the right to use an API doesn't grant you the right to
make copies the code behind that API.
> 8. I argue further: it's my opinion that even when you redistribute a
> binary statically linked, what you are distributing is an anthology
> work, and in the case of using a GPL'd program, you are allowed to do
> that by means of sections 1, 2§3, 5 and 10.
In essence, you are correct.
But if you claim that section 0 does not apply, then you are claiming
that the GPL does not grant license for this work, which means that
either (a) you're not talking about a copyrighted work, or (b) you're
talking about a copyrighted work which you don't have license for,
or (b) you're talking about a copyrighted work which is available under
some different license.
Which leads us back to the question of who holds copyright on that work?
If the GPL copyright holder holds copyright on that work, and the GPL
is the relevant copyright to consider whether that part of the work is
distributable, then you need the GPL to grant you license to distribute
that part of the work.
> 9. There is no reason for panicking and "oh my god someone get a GPL
> compatible libsnmp5-dev replacement", because there is no problem in
> linking a GPL program with a non-GPL'd library (or vice-versa) *at*
> *all*, as long as said program is not a derivative work of said library.
I'll agree with your words here, but I'm not convinced that what you think
they mean is what I think they mean.
In essence: you seem to be saying that if this routing software can
be separated into independent works such that the program as a
whole isn't copyright protected, that the GPL doesn't need to be
considered because these are really independent works. If that's
what you really mean, then I believe you are logically correct.
> 9.a. And I think that the facts that (I) those programs and libraries
> are dynamically-linked to each other and (II) the libraries are
> implementing documented APIs add weight to my opinion.
I don't think that this issue really resolves things in either direction.
> 9.b. As a side comment: If there *is* a GPL compatible libsnmp5-dev with
> all its functionality, even better! I am in favour of getting GNUTLS in
> shape! It would help cut down the license proliferation issues. But I
> think it's not necessary to yank half the repository just because of
> (dynamic) linking issues.
Sure.
--
Raul
Reply to: