Re: [tlug] JFS file system license

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:
 > On 2008-10-27 11:04 +0000 (Mon), Godwin Stewart wrote:
 > 
 > > Dr. T. was far more accurate in saying that you don't have to do so
 > > if your application doesn't *contain* GPL'ed code. Just because you
 > > invoke fopen(), i.e. your application is linked to libc, doesn't mean
 > > you incorporated that part of libc in your application.
 > 
 > Assuming you're dynamically linked, ld.so (the runtime linker) certainly
 > *did* incorporate that part of libc into your application when it was
 > loaded and run, and at the explicit instruction of your program binary.

As far as I know, copyright does not restrict this because of the
implicit permission to copy for the purpose of execution.  The GPL
explicitly says it doesn't restrict running the program (which of
course may be a library).  Any EULA that was extorted from you at the
time you obtained a copy may make such restrictions, though.

 > I've just run into this issue recently with a Ruby library. If I require
 > it, there's no question that I'm "incorporating it into my application,"
 > though only at runtime.

Actually, from the point of view of copyright, that is not clear.  RMS
says "yes" (and claims that this interpretation is the foundation of
the wealth of Bill Gates!).  Larry Rosen says "no".

 > Is it considered "incorporated" if I include the file in the set of
 > files with which I distribute the application, even if I don't ever
 > require it? Presumably not.

The "set of files" is a collective work.  It is incorporated in that
work, and you must comply with all licenses for each of the files.
This is why the GPL has an explicit exception for "mere aggregation".

 > But wait! gcc, as distributed with NetBSD, links (dynamically) to
 > libc, and worse yet, even the gcc binary has bits of BSD-licensed code
 > statically linked into it. (These are the stubs that help bring in and
 > start ld.so, the runtime linker.) So does gcc infect these stubs?

Yes, if they are distributed as part of GCC.  No, if they are
distributed as part of the OS.  Yes, that matters in copyright law.

 > Does it infect libc? I think all but the most radical GPL advocates
 > would say no. (And I note that even Stallman doesn't appear to
 > object to this.)

Again, there is an explicit exception in the GPL to cover this: the
GPL infestation is powerless to invade the OS and those libraries that
are distributed with the OS.  What would be interesting here is not a
court test of whether NetBSD must relicense everything as GPL; that
would fail on the terms of the GPL itself.  What would be interesting
is if everything distributed on the NetBSD DVD thereby becomes exempt
from the GPL because it is part of the OS distribution!

 > But what about the readline library? The readline library is very
 > clearly licensed under the GPL, instead of the LGPL, in order not to let
 > you use it in non-GPL'd programs. But presumably I can distribute this
 > as a shared lib with NetBSD without it affecting anything else, since
 > I'm distributing the compiled code itself as a separate "readline.so"
 > file.

Assuming "everything else" means "everything else not derived from
readline", you'd be right.

 > What if other things link to it? Well, I should not let non-GPL'd
 > programs link to it, if I'm going to keep the spirit of the license.

And RMS will come after you for it if you don't.  Specifically, he
extorted an agreement from Aladdin that they would remove a Makefile
stanza that allowed you to link readline yo Ghostscript via a 3rd
party stub (not distributed by Aladdin, directly, but available in
contrib on all mirrors).

I say "extort" because (as I said above) some authorities don't
believe that use of an API constitutes derivation.  Of course you
can't distribute a linked binary, because that clearly involves a copy
of the covered work.  But use of an API is not incorporation of
copyrighted material because there's only one way to do it, so it is
not an expressive work.  It never went to court because RMS has free
legal terror at his disposal, while Aladdin is a business with no
business interest in a readline-enabled Ghostscript, and a copyright
infringement case that went to court would likely have put a
multi-$100K dent in Peter's retirement account.

 > Yet having the dynamic linker at runtime combine in memory the GPL'd
 > readline library and a non-GPL'd program is no different than having it
 > combine the GPL'd gcc and a non-GPL'd libary.

It's very different.  The non-GPL'd library is part of the OS, which
is explicitly exempted from the requirements of the GPL.

Before you ask: AFAICT RMS believes he defines "part of the OS".
Thus, he claimed that on Solaris, Motif was part of the OS (so GPL
programs could link to it without having to distribute it under GPL),
but that Qt was not part of any GNU/Linux system.  I think that is
self-serving bullshit, but the FSF has a great protection racket going
(cf the Ghostscript case).

 > Does the GPLv3 say anything about this?

I haven't studied GPLv3 very closely from this point of view, but my
impression is that it corrects the error of GPLv1 and GPLv2 of using
implicit license to run (and of patents) by having an explicit license
to run, but is otherwise the same as GPLv2 regarding what needs to be
distributed under GPL.

 > On 2008-10-28 11:12 +0900 (Tue), Stephen J. Turnbull wrote:
 > 
 > >  > And what happens if my Hello World program calls fopen()?
 > > 
 > > First, fopen() is part of libc, in a GNU system that's GNU libc.  GNU
 > > libc is under the LGPL, so linkage to it can't matter ever.
 > 
 > I think that he was trying to say something more along the lines of,
 > "what if it invokes the open() syscall directly, without calling the
 > libc code that does this?"

Covered by the OS exemption, which works both ways.

 > > For a GPLed library, RMS (and his legal beagle) claim that the
 > > "derived work" described in copyright law includes everything in the
 > > same process.

 > Interesting. What is a "process," and what does it mean to be "in" or
 > "outside" of it? Would that be a virtual address space, and "in" it mean
 > any data mapped into that space?

It's a virtual address space, and it means program code and program-
provided data.  I/O is not part of the work covered by the program's
copyright, although of course it may have its own copyright and
attendant licensing.

 > If so, note that in most OSes these days that your "process" would
 > also include the entire kernel

(a) I don't think that is true; your program does not have read or
    write access to the kernel in any OS I've worked with since
    MS-DOS.  (Well, there are ways to fool Windows, at least up to NT
    3.5, into giving you access to the whole process space, but that's
    not the way it's supposed to work. ;-)

(b) The OS is exempt from the GPL.

 > and any data in the block I/O (disk) buffer cache, such as files
 > you've opened and read. Could opening and reading a file containing
 > a compiled GPL program infect your non-GPL'd program?

No.  

In general, I don't think that data read into a running program is
part of the work, not even a derived work, but IANAL.  You'd have to
ask one about that.  However, it's absolutely certain that as soon as
the program exits, the evidence is gone. :-)  And the GPL does not
restrict running the program, only its distribution, so the GPL for
sure can have no such effect.

 > > Larry Rosen seems to believe otherwise (and therefore the GPL == LGPL,
 > > pretty much, the remaining issue being whether a user has the right to
 > > copy a GPLed work, ie, from disk into the same process memory space as
 > > a non-GPL work---the "GPL doesn't cover running the program" phrasing
 > > would seem to say not but this is tricky).
 > 
 > Well, note that some people don't appear to place a lot of confidence
 > in this, in particular the BSD OS folks, since otherwise they would not
 > have rewritten the GPL'd readline library.

Nobody with free legal services wants to fight this.  The FSF would go
up in a puff of smoke if there were no strong copyleft.  IBM?  Who are
you kidding?  GPL is a great way for them to get the good press from
open sourcing without much risk of having somebody come back at them
with a much improved version of their own code.  Larry Rosen would
love to try the case, I think, but even he can't afford to do it on
his own hook -- he has told me he would like to do it if paid. :-)

But really, think about it.  In 25 years of the GNU Project, they've
managed to come up with only *one* service that is so compelling that
there is a big stink that it is GPL. ;-)  Why bother?

 > > Second, the fopen() API is standardized. There are multiple
 > > implementations, so as long as you don't distribute a 3rd party GPLed
 > > libc as part of your Hello World program, you're OK.
 > 
 > Hm. So I can't distribute my program binary without source and a
 > companion libsomething.so binary with source together if there's only
 > a GPL'd implementation of libsomething available, but as soon as a
 > free libsomething becomes available, such that I could substitute the
 > compiled free libsomething.so instead of the GPL'd libsomething.so, I'm
 > ok?

Exactly.  This is what happened with readline, and with Lesstif.

 > What if the free one is buggy and the GPL'd one isn't?

Then you'd better not depend on any of the buggy facilities, or you
are writing a derivative of the GPL version.  Whether there is a
sufficient dependence would be decided in court on a case by case
basis.

 > What if the free one barely works at all, or even doesn't work?

Then the whole GPL library is a GNU extension :-) to the permissively
licensed one, and you'd better be distributing under the GPL.

 > What makes an API "standard"?

Publishing it in source form for others to write programs to link to,
basically.  If you provide a header

----------------------------------------------------------------
/* hello.h */

#ifndef HELLO_H
#define HELLO_H
void say_hello (int ignored);
#endif  /* HELLO_H */
----------------------------------------------------------------

then I can provide a header

----------------------------------------------------------------
/* hello.h */

#ifndef __included_HELLO_H
#define __included_HELLO_H
void say_hello (int);
#endif  /* __included_HELLO_H */
----------------------------------------------------------------

The main point is that (1) the rest of my code should have an
identifying header comment and the multiple-include-prevention
rigamarole, (2) all of the other words are required exactly as they
are, or the program won't link.

ISTR that there are problems with macros; you have to avoid those
unless standardized.  (I last paid attention to this aspect of
copyright law before I started using Linux, so that would be about
1992!)

 > > *sigh*-is-it-time-for-yet-another-licensing-talk-ly y'rs,
 > 
 > It's a tricky problem. I'm of the opinion that we need a good lawsuit to
 > solve this.

I don't think it will ever be solved.  The FSF's interpretation will
rule, because they are willing to go to court and nobody else is.
It's just too easy to code around the problem; why make some lawyers
rich?