Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/12/05, Humberto Massa Guimarães <humberto.massa@almg.gov.br> wrote:
> > > Assume every work eligible for copyright protection, for the
> > > sake of the argument, and for $DEITY's sake. AND we're talking
> > > ONLY about dynamic linking. AND, to boot, that those bits that
> > > end up in a compiled work by way of being in a .h file (for
> > > instance) are not eligible for copyright protection.
> >
> > This is even more confusing. "assume every work eligible for
> > copyright protection...are not eligible for copyright protection"?
> > In principle, I ought to be able to figure out what you're saying
> > by looking at the grammar of your sentences, but in this case I
> > can't.
>
> I thought that one was simple:
>
> 1. please assume every work mentioned in the argument (unless
> otherwise noted) eligible for copyright protection;
Ok. This leaves open the question of how thin that
protection would be (which in turn depends on the
specific work(s) in question). But it does eliminate
some scenarios.
> 2. please assume we are talking (unless otherwise noted) about
> dynamic linking; and
Dynamic linking of what, with what, in what fashion?
> 3. please assume that those bits that end up in a compiled work by
> way of being in .h file or any other similar thing are not eligible
> for copyright protection (this is an explicit exception to #1
> above).
So basically, any bits which are in the executable which
would not be there if all .h files were removed are not
eligible for copyright protection? That's tantamount
to saying that the binary isn't copyrightable.
Alternatively, you're trying to make some kind of statement
about the mechanisms of the compilation process and
the information density of .h files, but that kind of reasoning
seems to beg the question of what's derived from what.
> > One of the confusing things is where you say "by way of being in a
> > .h file (for instance)". As an instance of what?
>
> Yes. one nice example are text of non-trivial inlined functions.
So, perhaps you're saying that all .h files in the cases
you're interested in are trivial?
> > > Is B a derivative of M? Is A a derivative of M? -- those are
> > > the million-dollar questions.
> > >
> > > I don't think so, because there is no intellectually-novel
> > > transformation of M that produces A or B.
> >
> > I'm trying to find an interpretation of this sentence that has
> > some meaning and I'm clueless.
> >
> > As a general rule, all derivative works are produced by humans.
> >
> > As a general rule, when we talk about transformations we're
> > talking about processes -- something outside the scope of
> > copyright law (thought not outside the realm of human activity).
>
> Why is it outside the scope of copyright law?
Processes are not fixed in a material form. If they are, they
cease to be processes and are instead something else (perhaps
a symbolic description of some process).
> The copyright law
> itself defined a derivation as the result of said processes. 17USC
> enumerates some processes, and Brazilian Author's Rights acts
> defines them.
I don't know what you're talking about here.
> > [For now, I'm skipping sentences which seem to depend on this
> > "intellectually novel transformation" sentence for their meaning.]
>
> Intellectualy novel transformation is the text of the code law that
> defines "derivative work" in Brasil. I suspect -- but I don't have
> the time right now to confirm -- that this text (which is already in
> one of my recent posts) is directly copied from the Geneva
> convention text. IOW, it's the letter of the law.
I think I know what you're talking about here.
Basically: stuff can be copyrighted if it's something which has concrete
existence, which a person put creative effort into making.
For example, a person could write something with a pen, and that
could be copyrighted. Now, you could look at what a pen does --
it mechanically transfers ink onto paper, and if you focussed just
on that, you wouldn't have anything copyrightable. Further, you could
take this work and you could run it through a photocopier -- so
running it through a photocopier does not in and of itself make a
work copyrightable.
But, still, the output of the photocopier might have copyright protection
because of something which happened earlier -- before the photocopier
was used.
This same rule must apply works which use dynamic linking.
The dynamic linking doesn't mean that the work is protected by
copyright. It doesn't say who has the copyrights. It might be
an interesting thing to discuss, but dynamic linking isn't a
process which makes a work a copyrighted work or a derivative
work or not a copyrighted work or not a derivative work.
Dynamic linking does have something to do with the copyright
status of a work, because it has something to do with the
existence of the work -- and only works that exist get copyright
protection.
Similarly, the binding on a book has something to do with the
copyright protection on that book. The binding serves to show
that the book is a work as a whole. But bindings on books
don't really say whether or not a work is copyrighted, derived
or much of anything else.
That's what kind of thing we're talking about when we talk about
the transformation involved in dynamic linking.
> > I'm interested in what you mean by "relevant" here. Do you mean
> > relevant to Debian's treatment of some software package? If so,
> > which software package would that be?
>
> Yes. The whole argument is: Can Debian distribute program X,
> dynlinking to libcurl, dynlinking to openssl? Or MUST Debian make
> its version of program X dynlink to libcurl + gnutls? Even if the
> latter has worse performance than the first AND openssl is in the
> distribution anyway?
And the answer to that question has to do with the creative work
which went into those programs, starting with program X.
Lacking any more specific information, I'd be inclined to answer:
probably, but not necessarily.
> > There are elements of glibc which "don't have much creativity",
> > and thus have only very thin copyright protections. As almost no
> > programs use glibc as a whole (most programs incorporate only a
> > small fraction of glibc), this can become relevant in some
> > examples. Of course, in other cases it's not at all relevant.
>
> The relevance here is: do you consider MD5() and SHA1()
> non-protectable? If you do, your argument leads to: Debian can
> distribute program X dynlinking to libcurl dynlinking to openssl
> without any preocupation.
I believe both of those two are in the public domain, but I could be
wrong. I don't have time to look this up at the moment, so you
should assume I'm wrong.
--
Raul
Reply to: