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",
argv[1],
search_ascii_for_my_name_amongst_the_digits_of_pi(argv[1]));
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
transformation.
> 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.
--
HTH,
Massa
Reply to: