RE: Roaring Penguin's view

Patrik Stridvall <[email protected]> wrote:
> However note that regardless of what the
> GPL say copyright law is unlikely to let the GPL push the
> issue too far. Even the FSF recognize this.

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

> Lets say that a GPL:ed Wordprocessor or whatever have a lot of
> import/export filters. Now in order to bring order to chaos an
> import/export filter API is defined with some dynamic loadning
> mechnism in order to facillitate debugging or whatever.
> 
> 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?

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


Martin Wilck <[email protected]> wrote:
> Am Mit, 2002-06-12 um 15.53 schrieb Deven T. Corzine:
> > Today, that's true.  What if future versions of glibc are under the GPL?
> 
> According to Stallman's own reasoning
> (http://www.gnu.org/philosophy/why-not-lgpl.html), this will only come
> to pass if there will be no substantial competitors for glibc.

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

> Even if that should come true, it is far from certain that he license change
> would happen. In any case, this is the far future, and none of us has
> the slightest idea how the IT world will look like even 5 years from
> now. The whole question may be totally irrelevant by then.

I think the point is that the odds are not zero, nor are the odds insignificant.

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

> I see no reason why this should change, especially in a situation where
> even the LGPL seems to offend so many people.

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.


Martin Wilck <[email protected]> wrote:
> Am Mit, 2002-06-12 um 16.11 schrieb Patrik Stridvall:
> > Ah, now we get to one of the core problems with the GPL.
> > The difference between "derive a product from" and
> > "develop a product for" is not defined by the GPL
> > quite the opposite. However note that regardless of what the
> > GPL say copyright law is unlikely to let the GPL push the
> > issue too far. Even the FSF recognize this.
> 
> The FSF if pretty clear about its viewpoint: Linking (static or shared)
> forms a derived product, communication through IPC mechanisms doesn't.
> The FSF itself states that that's eventually up to a judge to decide.

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.  
 
> In this respect, the GPL is indeed more restrictive than some commercial
> licenses (Microsoft grants you to link with their core DLLs - is that
> true for _all_ DLLs?)
> 
> Thus, if glibc became LGPL,

I presume you meant GPL, as it already is LGPL.

> you could still develop a GPL'd wrapper app
> that would communicate with your non-free program through e.g. a socket,
> transferring the library calls to glibc, just like wineserver is
> currently doing it for wine (though not for licensing reasons).
> Actually, I am pretty certain that such a wrapper would be among the
> first things created if glibc became GPL, probably by community members
> who'd disagree with that move.

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

-r