Clarify license - which GPL version?

[jas4711]

The LICENSE file makes a reference to GPL, but doesn't say which version or if any later versions can be used. What is the intent? Is this part still necessary? As far as I know, including BSD code in GPL projects is fine, but I didn't fine-read the exact wordings in case this is a non-standard BSD license.

[ldv-alt]

It seems to me that the text you're talking about was inherited from the Linux-PAM project, see e.g. COPYING or modules/pam_unix/support.c, where it was added about 28 years ago. I'm not sure whether this wording is necessary, but Debian's pam package reproduces it in its debian/copyright file.

[solardiz]

My understanding is that the FSF, etc. claim (and have for decades) that yes, "including BSD code in GPL projects is fine", however per my own reading of the licenses I do see how BSD (and several other permissive licenses, which are also considered GPL-compatible) appears to require things beyond the GPL (retaining entire permission notice and list of conditions). I never quite understood this discrepancy. I wish I did. I am not a lawyer.

Apparently, the dual-licensing of Linux-PAM as BSD and GPL in 1990s was done to address such license compatibility concerns ("necessary due to potential bad interaction between the GPL and the restrictions contained in a BSD-style copyright"). I don't recall whether there were already statements about license compatibility from the FSF at the time or not yet... although I think there were.

I agree it's weird to dual-license this code under the GPL without specifying which version(s). We could maybe clarify/restrict this to "version 2 or later", or we could drop this dual-licensing assuming it's generally agreed that a BSD license is compatible with the GPL.

The exact BSD license wording we have here is somewhat weird. We have:

1. Redistributions of source code must retain the above copyright
   notices, and the entire permission notice in its entirety,
   including the disclaimer of warranties.
2. Redistributions in binary form must reproduce the above copyright
   notices, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.
3. The names of the authors may not be used to endorse or promote
   products derived from this software without specific prior
   written permission.

https://opensource.org/license/BSD-3-clause gives:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

I wonder what other projects, if any, use the wording that we have here?

If the Linux-PAM project still has all these same issues/concerns, then perhaps they should first be addressed there, and then we follow here.

[jas4711]

Thanks for review and discussion. Given that the same problem exists in Linux-PAM, and you probably borrowed some code from Linux-PAM (or?), I suspect the simplest solution is to just acknowledge that the license is a bit sub-optimal. If people are okay with using Linux-PAM they should be okay with using this too. I suppose we could report this to the Linux-PAM folks (or search for existing discussions about it) but I wonder if changing their license at this point is feasible.

If you didn't re-use code from Linux-PAM, then I would say that re-licensing to single-license BSD-3-Clause, MIT, GPLv2+ or GPLv3+ would be an improvement from the current somewhat unclear license statement.

[jas4711]

Btw, I've modified the Debian tcb copyright file to mention that this license is the same as Linux-PAM which I confirm look identical in Debian too. I was worried that tcb could not be part of Debian due to unclear license terms, but if Linux-PAM can be included, I don't see how tcb could get rejected (on licensing grounds) as long as the licensing information is complete and correct.

[solardiz]

Yes, we did borrow code from Linux-PAM, which is why this license. Maybe we could review and rewrite the remaining pieces of borrowed code, but even then Linux-PAM should be properly licensed as it's to be used on the same systems with tcb.

You kind of already reported this to the Linux-PAM folks - @ldv-alt is also Linux-PAM maintainer for some years now.

[solardiz]

I just noticed that libpwquality used the same or similar dual-license, but clarified it to be GPLv2+:

$ git log COPYING 
commit 70ef5a4310268c1264f116efdc70a60c0a0dbb4d
Author: Tomas Mraz <tmraz@redhat.com>
Date:   Tue Aug 7 12:23:17 2012 +0200

    Clarified alternative licensing to GPLv2+.

commit e745294c1839de3b0886c6cbe5d8601c56dd3dcf
Author: Tomas Mraz <tmraz@redhat.com>
Date:   Fri Sep 16 19:02:43 2011 +0200

    Initial import into the repository.

[solardiz]

I just noticed that libpwquality used the same or similar dual-license, but clarified it to be GPLv2+

... and two of their source files include copyright statements from and mention libpam. So we have precedent of a distro-accepted project making such clarification of Linux-PAM derived code licensing.

[solardiz]

we could drop this dual-licensing assuming it's generally agreed that a BSD license is compatible with the GPL.

BTW, this has good answers on how BSD license (2- or 3-clause) is compatible with GPL (which puzzled me before): https://opensource.stackexchange.com/questions/6319/how-is-the-bsd-gpl-compatible
Still, without explicit dual-licensing it seems that having BSD-licensed code in a GPL project would impose the extra requirement (apparently non-conflicting with the GPL) to also carry BSD license along with GPL into derivative works, builds, etc.