RE: Roaring Penguin's view

On Thu, 13 Jun 2002, Roger Fujii wrote:

> This is the annoying thing.  Even though they know this, they use FUD to 
> accomplish their aims.

Like Microsoft, they'll use any tactic that works.  FUD, coercion, embrace 
and extend, whatever.  Stallman will use any means necessary to achieve his 
ends.  I don't think he stands on any higher moral ground than Bill Gates, 
ultimately...  (The BSD people sure do, though!)

> > If I develop import/export filter using the API (or ABI),
> > am I "deriving a product from" the GPL:ed work or am I
> > "developing a product for" the GPL:ed work?

Definitely a gray area.  I suspect it would depend on the particular facts.

> Well according to FSF, you would be "deriving from", as they *claim* that
> you cannot write a GPLed plugin for a propriatary program (if it's not
> fork/execed).
>     http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
> 
> This is not to say I think this has any legal merit - just that FSF
> does make this claim.

They can believe whatever they want to believe about what constitutes a 
"single program".  That's not the legal standard.  The legal standard is 
"derived work", which probably has all sorts of legal precedents already.

In particular, the UDI example I gave included some situations where I'm 
sure a court would find the UDI driver NOT to be a GPL-derived work, even 
if it can be dynamically loaded into a GPL'd operating system such that the 
FSF would "believe" it's a single program.  And if the court says it's not 
a derived work, then the FSF's belief that the GPL applies is moot.

> > Regardless of the case above:
> > Can you give any resonable definition of "derive a product from"
> > and "develop a product for" have clear and unambiguous meaning in the
> > general case.
> 
> you could probably come up with a "fair" definition, like MPL, but you
> would have to use a word like "substantial" somewhere.  Of course, you
> can always say that "develop a product for" means it did not use any 
> non-header source files.  In any case, such a definition would be pretty 
> much non-viral.

Well, technically, the definition might as well match what is and isn't 
legally a derived work.

> oh? there's a competitor to glibc for linux?

Believe it or not, YES.  (http://www.dietlibc.org/)  However, while this 
might let you avoid linking against glibc, it's not as complete or powerful 
as glibc, so it's not really a full replacement.

Moreover, it's under the full GPL, not the LGPL, so it's not useful for 
everyone, unfortunately.

> > Moreover, despite RMS's attempt to make more libraries GPL'd, most
> > library authors seem to prefer LGPL.
> 
> That's because (according to FSF) no non-GPLed programs could use such
> a library.  Most library writes do like to have their code called.

There's a tension here, between library authors who want their code to be 
as broadly useful as possible, and RMS who wants to leverage their efforts 
to force the GPL on as many applications as possible.

> This can happen if any or the core libraries (most obvious one is glibc) 
> convert as most libraries end up calling something in glibc somewhere.

If it's not statically linked, how could the FSF prove that you derived 
your application from the GPL'd version of glibc, not the LGPL'd one?

> Actually, they are *not* clear - what they *are* clear about is the ONE
> case where it is NOT applicable (fork/exec).  If you had an IPC mechanism
> like doors on solaris, it isn't clear if that would qualify as a "valid"
> separation.  

Ultimately, their belief only matters to the extent that it controls 
whether or not they'll harass and threaten you.  But if their belief is 
wrong, the courts will say so, eventually.

> I'll agree with Deven on this.  I this this is unlikely and a fork would
> be more likely the result.  Would be a really bloody scene though - will 
> make the wine LGPL conversion look mild by comparison....

Maintaining a fork to keep an LGPL version takes little effort, since it 
works well enough already that it doesn't really need a lot of new work.  
Writing some sort of wrapper, on the other hand, would take more effort, 
slow down applications trememdously, and beg the FSF to sue you...

Deven