> I think I'm slowly leaning towards providing an updated ca bundle, simply
> based on all the facts above. The license situation shouldn't be much
> different than with the current bundle we provide, and given that mozilla
> knows about this practise and it is done by other parties as well, we won't
> introduce something not seen before. The fact that the file is also loaded by
> libcurl (not linked into it), should also be "safe" from the view of the
> license not really "tainting" libcurl, just that it is a bit dubious on what
> the situation is for projects that don't use a license compatible with the
> triplet used by Mozilla for certdata.

My 2 cents...

If _any_ data, complete, massaged, modified or in any form from the
current Mozilla certdata is going to be included or distributed with
libcurl I would favour the following approach.

Check into lib/curl's CVS and track the original and unmodified
certdata.txt file
http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1

In that way there would be absolutely no doubt that the license that
applies to that file is the Mozilla triple license, and that lib/curl
simply passes/distributes it along with absolutely no change at all.

From this point now there are several posibilities...

1) Extract data from certdata.txt file converting to PEM format out to
ca-bundle.crt and also track ca-bundle.crt in CVS updating it when
certdata.txt is updated.

2) Delay 'generation' of ca-bundle.crt until the library is compiled.
This would even allow the distribution of the old ca-bundle.crt

In both cases the question which arises is...

Would the generated ca-bundle.crt still be subject to the Mozilla
triple license or could it just be lib/curl licensed ? I could argue
both ways, I have no clear answer.

-- 
-=[Yang]=-