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
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
