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:
> ** 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.
That's not starting out simple.
Starting out simple starts us without any #includes.
> > > > > 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?
"What is the scope of the copyright problem?"
> > > [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.
You explicitly left that case in for the #includes.
Basically, you're arguing both sides of the fence. You're
arguing that "everything is protected" except for the
stuff that's not. And that's fine, except it isn't a basis
for proving anything else.
We SHOULD be taking an individual work and analyzing it
for creative content. Not cooking up arbitrary hypotheses
and pretending they mean something
> > 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.
Ok, I'm not educated enough to read the law in its original
Portuguese, so let's assume that your interpretation is correct.
> IIRC Michael K. Edwards brought relevant similar US codelaw or
> caselaw.
The caselaw he referred to does not have anywhere near the
sweeping impact that you claim for the Brasilian code.
Mind you, the Brasilian approach might very well be superior,
from a technological point of view or a philosophical point
of view. It's just that that's not the law up north.
> > > 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.
And that's hardly the typical case for the programs we deal
with.
Anwyays, if we want to tackle that case we should look at
the program itself, and why it needs these *.h files. The
result matters, and that's probably where we should
start, if we want to know the nature of the creative work.
> > 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.
So let's take a look at the specific program.
And keep in mind that, for better or worse, we can't rely on Brazilian
law to solve our problems for us. That would be choice of venue,
or something.
> > 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".
Ok, I'll accept that simply because I have no other sources of information
on this issue (and I've read, in the past, that Brasil has an approach
to intellectual property issues that make people in other countries
nervous).
> > > > [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".
And people distribute loose leaf binders without any paper in
them.
The point here is that if intent can be demonstrated in a
significant fashion, that matters -- judges care about that
kind of thing.
> > 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.
Likewise, the sum of the parts is not different from the result.
> 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.
Agreed.
> 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.
I'll agree that no license clauses change.
The question is whether the license clauses which don't change become
significant in that context. And you know which clauses I'm talking
about.
> > > 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.
Or because it's in their best interest, economically.
Microsoft hands out advertising, for free, even though that advertising
has rather expensive creative content in that. That gets them
customers.
It *would* be pretty funny if they put an EULA on their ads, such that
if you didn't accept the license you couldn't look at those ads. Ok,
you can claim that their lawyers force them to release their ads for
free. Personally, though, I'm going to think they give their ads away
for free because they want to attract customers.
> > > 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"?
I mean "in a fashion which is in some way restricted".
> > 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?
One which delivers the functionality of the dynamically loaded
library, and the other which delivers the functionality of the
program which is a creative work independent of that library.
> > 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.
I'm not sure what specifically you want me to elaborate on --
I certainly don't have a working body of code that works this
way. But, sure, I'll be happy to take this to private email.
> > (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?
I don't have a specific answer. That depends on the creative content
of X and Y.
But, in general terms, I'd be looking for creative ideas (ideas first
expressed in Y) which are incorporated into X. For example, if
X will serve as a replacement for Y, that would strongly hint (but
not guarantee) that X is a derivative of Y.
--
Raul
Reply to: