2008/2/12, Daniel Stenberg wrote:

> > 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.
>
> As long as the license is clear it doesn't matter if the file is changed or
> not since the license does allow us to change it and we do distribute the
> script that does the change.

It does matter it it is changed or not. If certdata.txt remains
unchanged we and anyone can clearly claim that it is the original
Mozilla certdata.txt. On the other hand if it is changed or modified
the project (libcurl) might not even be able to use the Mozilla(R)
name to reference it; see last paragraph of the "Mozilla CA
Certificate Policy (Version 1.2)" [1]

If lib/curl finally includes Mozilla's unmodified certdata.txt I think
it would be a good idea that the project (lib/curl) (you Daniel
Stenberg :-) would ask and obtain explicit written permission to
include and distribute the certdata file with lib/curl.

This would be required to protect the project of future unexpected
claims. The license Mozilla is now giving for unmodified source code
or binary versions clearly states that it applies to their whole
products/projects. And we are here speaking of only one file which
happens to belong to Mozilla's "Network Security Services (NSS)"
project, So distribution rules might be different than those that
apply to the whole project.

> As I just wrote in the bug report for this issue, I've come to think more
> about the license for this file and how it really should affect us nor users
> of libcurl very much. The triplet license (MPL, LGPL or GPL) affects only the
> cacert file and what expands or builds upon it etc, but in all practical
> purposes nothing is doing that. libcurl is simply loading that file into
> memory and uses it.

Right. And even projects built using libcurl might not use it or
choose not to distribute it. The one at most risk would be you if
certdata.txt was distributed without permission with lib/curl. Maybe a
minimal risk but it exists.

> I'm not a lawyer but I've read a few licenses, and when thinking about it I
> don't see how our usage of this file (with the triplet license) would make us
> have to adjust any license or how it would be a burdon to any particular user.

The copyleft imposed by MPL 1.1 to the original certdata.txt does not
seem to 'sting' the whole project (lib/curl) if Mozilla agrees that
lib/curl can distribute the certdata.txt file with the same triple
license as a whole Mozilla product/project.

> The only thing that users of this file need to remember is that it is licensed
> differently than libcurl so customers can in fact request it (the "source" of
> it at least) and if the file is changed the changes need to be offered as
> well. I don't think these are sacrifizes that are very painful for us nor to
> users of libcurl.

Yep.

And if lib/curl does not obtain permission to distribute Mozilla's
original certdata.txt, then Guen's mk-ca-bundle.pl rescues nearly
every lib/curl user.

And here comes another twist to all this stuff, it is the license
issue with ca-bundle.crt...

The easy way is to claim that a ca-bundle.crt file generated from the
data contained in the original Mozilla certdata.txt file must keep the
same license as the original file. This approach which is the most
restrictive, would still suffer from the need to ask distribution
rights for the data that is extracted and converted to a different
file format or representation.

The other approach would be to only recognize the copyright on
certdata.txt as it is, its layout, its data representation, and
origin, but deny Mozilla's copyright on what the certificates really
represent. And not distribute certdata.txt at all.

After all what prevents us from gathering the same certificates from
their original issuers and distributing them in our ca-bundle.crt ? I
guess that the fact that it would require us to obtain distribution
permission from each individual CA and a lot of additional work :-(
But it could be done if hte extreme need would arise.

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.

If I'm not wrong all this effort aims at making the situation more
clear, so whatever is done should at least result in a more clear
situation for lib/curl and copyright holder than it is right now.

[1] http://www.mozilla.org/projects/security/certs/policy/

-- 
-=[Yang]=-