Re: GPL, yet again. (The kernel is a lot like a shared library)
** Raul Miller ::
> 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.
>
> 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.
Remember what I said some messages ago: we must start from somewhere
simple, to get to some conclusions and then, later, add the
complexities.
By "completely original" I meant "programX's author sat down and
wrote the whole thing without copying code from anyone". He could
(should?) have used #includes, etc., but those (for now) are not
relevant.
>
> > > > 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.
What begs what question?
> > [removed parts]
> > 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.
I specifically said (below) that you were to assume that I'm talking
about a complex program, and that the simple thing I did above was
repeated throughtout said complex program, to eliminate the "this is
not protected" case.
> > (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.
My point is exactly: by law (codelaw in Brasil and caselaw IIRC in
the US) I do NOT get a copyright issue because the law permits me to
do just that, up to a point.
> > > 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.
I already did. I cited in March or April in our discussion codelaw
from Brasil and some caselaw that specified exactly that.
In Brazilian codelaw, with a quick search I find:
Law 9609/98 (Computer Programs Act):
"""
Art. 6. Do not constitute infringement on the computer program's
author's rights: [...] III- the ocorrence of similarity with another
preexistent program when it's decorrent from the functional
characteristics of its application, from the observance of normative
or techinical precepts [*], or from limitation of an alternate form for
its expression.
"""
Sorry for the horrid translation, but the law is written using an
inverted "verb predicate: subject1; subject2; subject3" construction
that exists in Portuguese (especially used in legalese Portuguese).
The clause marked with [*] "normative or technical precepts" was
already tested in our courts as encompassing published APIs. That is
to say: there are limited ways of describing (for instance) the
OpenSSL API as an openssl.h file, or even as a set of *.h files, so
similar *.h files are not infringing.
This is why I told you on-list, four or five months ago, that *.h
files are in principle not protected. Explaining better: is not that
they are not protected: is that copyright protection is EXTREMELY
selective when you are talking of things that are TYPICALLY in *.h
files.
IIRC Michael K. Edwards brought relevant similar US codelaw or
caselaw.
> > 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.
No. OpenSSL *.h files are available under OpenSSL's license; libcurl
*.h files are available under the GPL. As Debian believes the
licenses are incompatible, Debian forbids a packager from packaging
a program that (at run time) dynamically links both OpenSSL and
libcurl. So, that means their *.h files are made available under
terms such that they ARE an issue.
And this issue is what I am trying to iron out here.
> 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.
I believe (with good reason) that this is the typical case.
No one made me a believable case where a program that REFERENCES a
library is a derivative work of said library. And typically,
programs only reference libraries, using their functionality thru a
semi-fixed API, and in the case of dynamic linking, thru a FIXED
ABI.
> > [more cuts, for brevity sake]
> > 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.
The problem is not exactly "is this work creative": the problem is
"are the parts of Y.h that end up in the executable
/usr/bin/programX infringing the copyright terms of Y.h when Y.h is
licensed in incompatible terms than programX.c?" The answer to this
question, in Brasil is: "no, because of art.6,III of the law".
> [more cuts]
> 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.
Yes.
> 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.]
And we would have to wait for legislation that permited their works
to be protected. Brazilian civil code, at least, limits
intelectuality for human beings so, no, hunchback whales' songs are
not copyright protected in Brasil, nor is painting made by a chimp
or a gorilla. [I recall seeing nice paintings made by a gorilla over
the net about an year ago]. IOW: yes.
> 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.
Yes. Now we're talking. But issue really is "how much of the
original works are incorporated (into the binary) and if those parts
incorporated were protected when incorporated by this specific
method (normally not)".
> > > [more cuts]
> > > 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).
Dynamic linking is more like no binding at all. You can -- and most
certaily do -- distribute a dynamic linked binary without the
linking libraries. It's like printing on a loose leave of paper with
a small print on the bottom: "continue".
> 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...
The result is not different from the sum of the parts.
To put it differently: do you think J.K.Rowlings' publishing company
needs a special permission in her contract to distribute all of Harry
Potter's books in the same box? I don't think so, because in theory
they already have the permission to distribute each book separetely.
Now, if they wanted to do a single book "The Complete Potter", then
probably they would need the permission for a compilation work.
BUT, those boundaries _are_ difficult to determine, yes. Back in the
case, I think that Debian does lawfully distributes libcurl,
lawfully distributes libopenssl, and it can lawfully distribute
both... and no license clauses accepted by Debian in order to do so
change this if libcurl happens to dynamic link at runtime with
libopenssl.
> > 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).
Do you sincerely think MS would have such generosity? Those terms
are there because the army of in-house-lawyers knew that other, more
restrictive terms would be unenforceable.
> > 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."
What do you mean with "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.
Which two independent programs?
> 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.
I will have to ask you to elaborate on this in a private e-mail:
sounds like a fun project to me as a coder.
> 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.
Yes, the main engineering problem with dynlinking ATM is: registry
of functions/components/objects/whachmacallits, with versioning,
origin, maybe cryptographic signing, and security checking. An
innocent program can be completely subverted by a malicious dll.
> (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.)
But we are way off the topic here already, so I'll leave you the
important question you did not answer: what would take for you to
consider a programX as a derivative work of a libraryY, which said
program uses thru its published API/ABI, considering that the the
distributed binary /usr/bin/programX is dynamically linked to
/usr/lib/libraryY.so?
--
HTH,
Massa
Reply to: