On Tue, Sep 07, 2004 at 07:57:06PM +0100, Andrew Suffield wrote:
> On Tue, Sep 07, 2004 at 05:34:29PM +0000, Joel Baker wrote:
> > On Sun, Sep 05, 2004 at 01:05:27PM +0100, Andrew Suffield wrote:
> > > On Sat, Sep 04, 2004 at 10:03:31PM -0700, Ken Arromdee wrote:
> > >
> > > > and of course that any document
> > > > written in Microsoft Word is derived from Word.
> > >
> > > I can use a word document without a copy of word, these days. There
> > > are at least half a dozen other things that can work with them.
> >
> > Perhaps I am misunderstanding, but by this argument, wouldn't the fact that
> > "can link against libcurl with GNU TLS, libcurl with OpenSSL, or libcurl
> > with no SSL at all" qualify it as mere aggregation - if the dividing point
> > is that multiple implementations, at least some of which are Free, can be
> > used with it?
>
> Maybe. You have implicitly introduced the notion that these three
> variations on libcurl are distinct, and I'm just not sure about
> that. This transitive option stuff is murky.
Perhaps; IMO, a transitive API (that is, an API which provides a thin
veneer over other APIs, such as Curl's SSL API) falls under one of two
cases:
1) It is, itself, an API barrier beyond which the program cannot "see",
and which means the license of the transitive API governs whether it
can be used with GPL code.
or
2) It "passes through" to the API which *it* calls, and the licensing of
any / all implementations of that API distributed come into play.
There are some "smell of the wind" tests one could propose to decide
between case 1 and case 2, the foremost I can think of having to do with
how similar the APIs are (that is, how "thick" the veneer is - panelling,
or a two foot wall?), but for the specific instance at hand, it isn't
actually necessary to decide, AFAICT. Specifically:
In case 1, Curl's license governs, and as far as I understand, this
isn't a problem at all (or the issue wouldn't be so murky).
In case 2, we degenerate into a situation identical to the readline library
situation - multiple implementations of the API exist which can fufill the
API requirements for dynamic linking. A quick review of the topic from
past d-l posts, courtesy of Google, makes my head hurt a lot more than it
did before I began, but the best summary I can find is that "derived work"
status may be invalidated if programming to a (non-copyrightable) API,
rather than to a specific implementation (modulo Debian packaging choices
such as whether it Depends, Recommends, or Suggests packages with various
licenses).
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU/kNetBSD(i386) porter : :' :
`. `'
http://nienna.lightbearer.com/ `-
Attachment:
signature.asc
Description: Digital signature