Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/15/05, Humberto Massa Guimarães <humberto.massa@almg.gov.br> wrote:
> > 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.
I don't know what "completely original" means.
Computer programs are always built on the work of others.
Ok, maybe I should make an exception for Chuck Moore. After all, he
invented his own language, designs his own VLSI, and so on. But
most people base their work on other people's work.
Anyways, if I take you literally -- if a work really is completely original,
then obviously it's not a derivative work. But in the current context,
I'm dubious that there are any real examples that fit your description.
> > > 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.
This begs the question.
> > > 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?
No, I'm arguing that this is a trivial example -- beneath
the notice of copyright law.
> (just to be clear, assume I did the same throughout a very complex
> program instead of the simple example I gave).
In that case you're including the .h file contents in your program,
and this really devolves to a question of whether those specific
contents were copyrightable.
If the contents are trivial (as in your example here), then your copying
is beneath the notice of copyright law. But if the contents are
complex (as might be implied by the assumption you're asking me
to make) then you've got a copyright issue.
> > 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.
This is true for some cases involving some computer programs.
If it were a universal truth, you could quote the relevant law for me,
and we wouldn't be having this discussion.
> 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.
TYPICALLY, *.h files are made available under terms such that this
isn't an issue. This is because most people want this kind of thing
to be generally available.
There are additional cases where *.h files are not copyrightable
because their creative contents are trivial (and in some cases
this is because they're derived with minor changes from something
available under a more permissive license).
But are we talking about the typical case? You can show something
is true for the typical case, but when you get to a specific case
you still have to analyze it on its own merits.
> > > > 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).
You might be right for the case of Brasil law. I don't know much
about how copyrights work in Brasil.
However, there's no such automatic mechanism in U.S. law, or
U.K. law, and I doubt there's very many countries other than
Brasil which would delegate the issue of "is this work creative?"
to this kind of mechanism.
> > 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".
In other words: a work can only be a creative work if it was created
by a person. An automated computer process can transform a
creative work into some other form, but does not in and of itself
make a work protected, or not protected.
Unless we're talking about hypothetical artificial intelligences which
are recognized as having the same creative potential as humans.
[Since we don't have any such AIs packaged in debian, I think
we can defer that discussion.]
The issue that comes up in the context of a mechanical
transformation is: how much of which original works are
incorporated. It doesn't matter that a compiler, a
printing press, a scissors, or a fork-lift is not adding creative
content.
> > > 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.
Sure. Same holds for printing, packing cases full of DVDs, binding
pages in books, and so on and so forth. The work has to already
exist.
Basically, the distinction between "static linking" and "dynamic linking"
is like the distinction between case binding (like a hardback book) and
ring binding (like a loose-leaf notebook).
If someone ships a book as several parcels, each containing a
stack of shrink-wrapped paper, and a separate three-ring binder,
and instructions on how to sort and assemble the result, does
that mean that the result is not eligible for copyright protection?
Let's say, for the sake of argument, that a million identical
copies of this book get shipped...
> 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.
The license on visual studio doesn't really matter here. What
matters is the license on the SDK (which has fairly generous
terms for stuff you write yourself).
> > > 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?
Sorry, I meant to say: "Lacking any specific information, a work
is probably but not necessarily protected by copyright in a
problematic way."
Put differently: in the libssl case, why are we talking about one
program, rather than two independent programs? If they're
really independent, this is just bad packaging.
That said, I'd really like to re-engineer the whole c compilation
process. I don't like that libc is a huge monolith, rather than
a thin shim. If I had my way, a shared library could be represented
as a directory structure rather than as a single file.
Also, for the most part, dynamic linking adds more headaches
than it relieves. This isn't entirely the case, and there are
definitely problems it solves, but this tangle we're currently
talking about has a lot to do with lazy engineering.
(In other words, yeah, there would be performance problems if you
blindly used "shared libraries are directories" as a drop in replacement
for "shared libraries are single files". Then again, most code
nowadays is hugely redundant and verbose, in part because
it's so easy to write code that way. And there's other solutions
-- good solutions -- for most of these problems.)
--
Raul
Reply to: