On Tue, Feb 12, 2008 at 06:15:29PM +0100, Yang Tse wrote:
> I think that lib/curl has only two safe and crystal clear approaches left.
>
> 1) Obtain explicit permission from Mozilla or Mozilla's Network
> Security Services (NSS) project to distribute their original
> certdata.txt file. And also convert that data into ca-bundle.crt with
> the same license.
>
> 2) Do not distribute certdata.txt nor ca-bundle.crt, not even the old
> one. And pass the problem down to lib/curl's users providing
> mk-ca-bundle.pl so that they can fetch certdata.txt and build for
> themselves ca-bundle.crt if they need to.

Just who is the audience for a certificate bundle included with curl? Is
it distribution package maintainers? No, they maintain their own bundles
separately and won't bother with a curl bundle. Is it users? No, not most
of them because their OS distribution already includes an up-to-date bundle.

So for whom is it, exactly, we would be doing this? In all cases,
it's users who are building from source (because binary packages will
include a bundle or point to one already on the system). I suspect most
of these users either don't know that a bundle already exists on their
system, have specialized requirements (e.g. embedded applications where
no bundle exists on their target), or use an OS that doesn't already
provide a bundle (Windows?).

I'd be happy to simply not include a bundle at all and let these few
users use Günter's script to download their own, dealing with the potential
licensing implications at that time.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved