Re: Linux and GPLv2
Matthew Palmer wrote:
On Wed, Mar 23, 2005 at 10:22:12AM -0300, Humberto Massa wrote:
> Matthew Palmer wrote:
>
>>> That said, it looks questionable whether the FTP plugin should
>>> reallybe considered a derivative of the plugin loader. If the
>>> latter has a documented API and the former only communicates
>>> with it through that API, I'd probably say no. Even more so if
>>> that plugin could conceivably work with another, non-GPL'd
>>> plugin loader.
>>
>> It's a tricky issue. Even if the plugin does only communicate
>> via the published interface, it is entirely possible that the
>> plugin includes copyrighted elements from the plugin loader code
>> itself. It'd have to be decided on a case-by-case basis.
>
> Basically, ".h" bits are *not* copyrightable.
Under what theory do you come to that conclusion? Note that a .h
file can contain more than function prototypes, and function
prototypes don't have to be in a .h file.
Whoa, slow down, cowboy! Re-read what I have written up there: <<".h"
_bits_ are not copyrightable>>. Now take a deep breath. The thing is: it
is considered by USofA and other countries case law that the bits that
are at compile/link time from a .h file (as you mentioned down here, as
macros and inline functions) are not really being "included" in the
work, but are in reality being "referenced" on it. I will try to
ilustrate it (any coincidence on names of real people is what it seems
to be):
// errno.h:
// (C) LT, 1991
#define ENOENT 23
extern int errno;
/* implementation detail: never use this array; its name can change at
any time */
extern char **__err_msgs;
#define perror(s) (fprintf(stderr,"%d:%s:%s\n",errno,__err_msgs[errno]))
// myfile.c:
// (C) Massa, 2005
if( !(f = fopen("arqname.txt", "r")) )
perror("The file arqname.txt must exist!");
Is "myfile.c" a derivative work on "errno.h"? The answer is NO. In the
Abstraction, Filtration, Comparison process, bits that come from a ".h"
by way of its interface (as opposed to "by way of its implementation")
are filtered OUT in the filtration phase. This basically translates as
following: to the extent that you don't mess with the inner workings of
a ".h" file (eg, in the above example the __err_msgs array),
independently if it has macros/inline functions in it, "myfile.c" (that
is, in the ultimate analisys, the copyrighted work) does not include,
properly, "errno.h", merely reference it.
IOW: myfile.c is not a derivative work on errno.h. Now, look:
// myerrno.h:
// (C) LT, 1991
// (C) modifications Massa, 2005
#define ENOENT 24 /* the stupid other guy used the wrong number */
extern int errno;
extern int perror(const char *s); /* let's move this to the lib */
THAT is Obviously a derivative work of errno.h. Got the difference? This
example have something that is a *transformation* -- novel,
intellectually-worked -- on the original work. When you abstract out
what errno.h does, filter the non-copyrightable parts (if any) and
compare, myerrno.h is clearly a derivative work.
Even if kernel developers did not know it at the time, this is the real
power behind EXPORT_SYMBOL_GPL vs EXPORT_SYMBOL: the latter mark things
in the kernel as being part of the API/ABI and the former, as being part
of the implementation, *effectively* regulating what is messing with the
kernel inner workings enough to be considered a derivative work (and
hence, to be mandatorily GPL-compatible-licensed).
> Which other elements of the plugin loader may be _included_ in the
> plugin?
Macros and inline functions spring immediately to mind, although I
don't think inlines normally cross library boundaries. My linker fu
is rusty.
Any others?
- Matt
Massa
Reply to: