Re: GPL, yet again. (The kernel is a lot like a shared library)
** Raul Miller ::
> 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.
Assume that programX is a complex (>10000 SLOC) program, written by
a single author, and completely original.
>
> > 2. please assume we are talking (unless otherwise noted) about
> > dynamic linking; and
>
> Dynamic linking of what, with what, in what fashion?
Everything that is a part of the programX /per/ /se/ may be
statically linked, but every library not written by the programX's
author is dynamically linked.
>
> > 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.
Why? if I do in my source code
---
#include <cstdio>
void f() { write(fileno(STDERR), "ola Raul\n", 9); }
---
and then I remove the #include, meaning *no* bits of cstdio are
included in my program, I get a compilation error, but *my* program
copyright status is unaltered IMHO. If I want to make it compile
again, I just need to alter this to:
---
void f() { extern int "C" write(short, const void *, unsigned);
write(2, "ola Raul\n", 9); }
---
and voila. I have a program which does not include *any* bits from
cstdio. Are you arguing that the copyright status of my program
changed?
(just to be clear, assume I did the same throughout a very complex
program instead of the simple example I gave).
> 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.
No. I am just stating what some codelaw from Brasil I have already
mentioned here (and IIRC some US caselaw MKE dug up): computer
programs have parts of them which are not eligible for copyright
protection because of the use of said parts as descriptions of
interface -- such parts are extremely limited in the creativity
versus the functionality they present. One classic example of said
parts are *.h files. I am NOT saying that every single bit of .h
files is uncopyrightable. I AM saying, instead, that TYPICALLY every
bit of information that ends up in the a.out file that came from a
library .h file, in the case of C programs, especially, in
non-protected.
>
> > > 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?
No, you got me wrong. I am saying that if the text of
---
template <class I> void sort(I, I);
---
ends up in a program a.out because a.cc #included <algorithm>, this
sort of partial copy is part of the limitations of the copyright
statute -- i.e., in that specific case, the text of sort() would NOT
be protected by copyrights. Why? In Brasil, mainly because an
"drop-in" alternative STL could bring to the same program other text
-- or none at all (in the case sort() is not inlined in the
alternative STL).
> 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).
I was not talking about processes, but about the RESULT of
processes. For instance, if I translate this e-mail from English to
Spanish, this is a process. The translated e-mail is the result of
said process, and it's fixed on a material medium (my HD). The
translated e-mail, supposing the original was eligible for copyright
protection, is a derivative work of the original. THAT is the
definition of derivation: the RESULT of processes. In case of
Brasil, the result of "intelectually-novel transformations".
>
> > 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.
But dynamic linking takes place AFTER the work already exists. Take
a look in the example I gave to Andrew Suffield about programX
versus openssl versus (ficcional) novossl.
More: you can develop (with some care) a program in Visual Studio,
using MS's headers and (dynamic) libraries, and take this program
/ipsis/ /literis/ and compile it under other platform. Not even
MSVCRT's terms of use try to determine what you can do with your
program -- they DO regulate how you are distributing MSVCRT.DLL
itself, but they DO NOT talk about your program.
> 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.
Yes. That is my answer too.
>
> Lacking any more specific information, I'd be inclined to answer:
> probably, but not necessarily.
Probably what? Probably Debian can distribute? Your answer wasn't
clear. The "but not necessarily" part is interesting: what would it
take, in your opinion, to make a programX a derivative work of the
libraryY from which it uses the standard, published API?
>
> > > 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.
Don't worry, I do (ok, kidding...).
--
Hope to Help,
Massa
Reply to: