[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GPL, yet again. (The kernel is a lot like a shared library)

** Andrew Suffield ::
> On Wed, Sep 07, 2005 at 06:50:00PM -0400, Joe Smith wrote:
> > While I would like to belive that the FSF knew exactly what they
> > were doing, I am not certain.
> > 
> > It is generally belived that the GPL 'derivative' clauses may
> > actually be upheld in the case of static libraries. The fact
> > that linking the .o's of the library directly with your program
> > is equivelent to linking the library with the object files of
> > your program, seems to verify this.
> > 
> > The question still debated is whether Shared libraries are like
> > this also.
> It's the wrong question. This is a FAQ here.
> Stop thinking about libraries. Libraries are not relevant. You're
> getting misled by technial details of how libraries are
> implemented, when in fact the whole issue is a red herring. Start
> thinking about source.
> The question you need to ask yourself is: Is this piece of
> software, in source form, a derivative of openssl?

Up to this point, you are 100% correct.

> If it has been written to include and extend the behaviour of
> openssl by calling its functions - for example, the piece of
> software is an implementation of HTTPS, an SSL-derived protocol -
> then the source is probably a derivative of openssl.

NOOOOOOOOO !!!! Please, no!!! Never !!! Substitute that for:
If it has be written applying any kind of intellectually-novel
(which rules out *any* kind of automated/automatable) TRANSFORMATION
over the source code of OpenSSL -- for instance, assuming OpenSSL is
written in C, if you port function-by-function the code to Pascal,
having to think and apply your craft in the art of programming to do
so, then the source is a derivative of openssl.

What you said is false, and its falsehood is trivially demonstrated
-- imagine the following C program:

#include <stdio.h>

int search_ascii_for_my_name_amongst_the_digits_of_pi(char *name) {
  //... non-trivial implementation here.

int main(int argc, char **argv) {
  printf("hello, %s!\nyour name is in the %dth digit of pi!\n",
  return 0;

-- end

the program above includes and extends the functionality of libc, by
calling its functions to make it print your name (given to it in the
command-line) and where is the ascii for your name in pi. It's a
derivative work of libc, as per your reasoning. Ah, but which libc?
MSVCRT? BSD libc? glibc?

> The shared library form is then trivially a derivative because
> it's a transformation of the source, but we don't actually care
> about that - the fact that the source is a derivative is enough to
> be a blocking issue.

Beware of the use of "transformation" here... transformation of
source into binary form (static, shared, library, program) is NOT
intellectually-novel. Does _not_ generate a new copyrightable work,
the work is still the same, it does just generate a copy that is in
another format.

> You will note that this allows for the possibility of software
> linked to openssl that is not a derivative of it. The trivial
> example is to take a copy of GNU hello, and add "-lssl" to
> LDFLAGS. That doesn't make it a derivative of openssl.

hello is not derivative of openssl even if you make it print the MD5
and SHA1 of the string "hello, world.", as calculated by openssl.
No intellectually-novel transformation was applied over openssl.
> You will also note that this excludes the possibility of being
> able to evade copyright law via technicalities of how you build
> the software. That's an expected property of a well-formulated
> law.

Yes. And this is exactly WHY you are wrong. If my program above
could be deemed a derivative work on MSVCRT, this would open a
Pandora box.

> I do not know how a program that really used openssl, calling its
> functions, could avoid being a derivative. I can't rule it out but

Because you seem not to know what a derivative is. I repeat, and I
refer you to 17USC: transformation, transformation and
> I've never seen a plausible argument for it and I can't imagine
> what one would look like. If anybody wants to try arguing that
> case here, expect it to be a really hard sell.


Reply to: