Re: [tlug] JFS file system license

[Curt Sampson <cjs@example.com>]

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.

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. 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.

In fact, here's a really interesting example. NetBSD distributes gcc
(GPL) as part of the OS. It's thought that since gcc is an entirely
separate application, its GPL doesn't conflict with NetBSD's BSD libc
license (BSD license), and I can bundle these together and sell you a
binary copy of NetBSD with a modified libc for which I don't give you
source. Sounds reasonable so far, right?

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? 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.)

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. 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.

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.

So I'm a bit mystified here; it seems to me that either a lot people out
there are violating the GPL by distributing binaries that link GPL'd
code at runtime, or, in this age of dynamic linking, anybody can easily
get around the limitations authors try to impose by releasing a library
under the GPL.

Does the GPLv3 say anything about this?

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?"

> 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? If so, note that in most OSes these
days that your "process" would also include the entire kernel 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?

> 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.

> 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? What if the free one is buggy and the GPL'd one isn't? What if the
free one barely works at all, or even doesn't work?

What makes an API "standard"?

> *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.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com