Which license is libtasn1-config?
simon at josefsson.org
Wed Oct 8 14:44:59 CEST 2008
Jeff Cai <Jeff.Cai at Sun.COM> writes:
> Sun couldn't ship those files under GPLv3, so if we can't make sure
> whether it is under GPLv3, maybe we have to change the package on
> But since all files under libtasn1/lib are under LGPLv2, can I assume
> it is under LGPLv2 also?
I don't think anyone will sue you over making that assumption.
> Since version 1.0, some source code has been changed to GPLv3. As the
> current maintainer, could you also give me an answer about its
Right now the file doesn't seem to have a clear license. The
_intention_ was most likely LGPLv2.1+, but it was never encoded
> And if you can't give me an confirmed answer, do you know who changed
> the license to GPLv3 and Can I contact him directly?
I changed the license from GPLv2+ to GPLv3+ on those parts that used
According to the vc logs, Nikos added libtasn1-config back in 2004. You
could ask him for the license. However, I suspect the files were
derived from somewhere else (GnuTLS? Which in turn may have derived
them from libgcrypt?) so that may require chasing the authors further.
I believe the simplest solution is to remove these files.
> Simon Josefsson wrote:
>> Jeff Cai <Jeff.Cai at Sun.COM> writes:
>>> Hi, Simon
>>> I'm confused that though libtasn1 is licensed under LGPLv2, then does
>>> it mean libtasn1-config also is licensed under LGPLv2?
>>> If not, then what is its license? GPLv3 or LGPLv2?
>> Hi. Actually, I cannot find a license header in libtasn1-config.in, so
>> I'm equally confused.
>> Normally build infrastructure stuff is GPLv3, so using that would be
>> close at hand. Alternatively, the all-permissive license used for other
>> autoconf-related files may be used. I noticed that libgcrypt uses it.
>> However, I would prefer to get rid of the *-config scripts. The idea
>> behind *-config scripts is against the normal autoconf-approach to test
>> for features, and works poorly in corner cases. Even if some users
>> prefers that model rather than the normal autoconf-approach, libtasn1
>> supports pkg-config. Pkg-config is at least widely used, and the M4
>> code for it is likely more correct than libtasn1.m4. People have
>> probably adapted pkg-config for some corner cases before us.
>> So let me propose that we remove libtasn1-config and libtasn1.m4 from
>> libtasn1. Instead, we recommend developers to use the normal
>> autoconf-machinery to test for libraries, or if they don't like that,
>> that they use pkg-config.
>> Gnutls-devel mailing list
>> Gnutls-devel at gnu.org
More information about the Gnutls-devel