On Mon, 21 Oct 2002, Soren Spies wrote:

> I plan to leverage some digest-auth work already done inside of Apple.
> This code is under the APSL (http://www.publicsource.apple.com/apsl/). I
> have checked with our lawyers and marketing folks and they assure me that
> curl can do whatever it wants with the APSL source as long as any
> modifications remain publicly available (preferrably with Apple alerted to
> changes).

This is true, but doesn't go with the general spirit of the curl licensing
because of these reasons:

1. It is deemed GPL-incompatible by the FSF. This means that the moment the
   APSL-licensed code goes in, we slap lots of GPL-licensed libcurl-using
   projects in their faces since they cannot any longer distribute binaries
   of their programs linked with libcurl, as that then violates the GPL.

        http://www.gnu.org/philosophy/apsl.html

   As the CONTRIBUTE documents explains, I cannot accept GPL incompatible
   licenses.

2. I've explicitly worked on getting the curl license worked out in a fashion
   to allow pure binary distributions, without any "copyleft" what so ever as
   I don't believe in that system. The APSL would introduce this in parts of
   the source code, and while perhaps not affecting any major parts of the
   code it would make it annoying and confusing to users.

> On the "contributions" page, I see that it is acceptable for portions
> (certain files) of the source base to be under a non-curl license. Is the
> APSL acceptable for these purposes? Obviously there would be separate
> source files for the APSL'd code.

I'm sorry, but I can't accept APSL'd code into the curl source base.

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en