Vague license references

[evelikov]

Describe the bug

Multiple places through the code-base reference the existing dual licensing nature of the project.. Although the references are pretty vague - here is an example form the README:

Zstandard is dual-licensed under BSD and GPLv2.

and another ones from the source files

 * This source code is licensed under both the BSD-style license (found in the
 * LICENSE file in the root directory of this source tree) and the GPLv2 (found
 * in the COPYING file in the root directory of this source tree).
 * You may select, at your option, one of the above-listed licenses.

Why vague?
There are a wide range of "BSD" licenses (1, 2, 3, 4 clause and permutations), similarly for "GPLv2" it has an "only" and "or later" variant. Checking the COPYING and LICENSE files - seems like the project is using BSD-3-Clause and GPL-2.0+ "or-later" variant.

Note: GPL-2.0-or-later and GPL-2.0+ are different identifiers for the same license. The latter is the deprecated identifier, yet it is still widely used in the kernel et al.

I would encourage the team to double-check the above. As result one can remove the LICENSE and COPYING references and use something like the example below. Both of these should be particularly useful for @terrelln work - importing zstd 1.4.10 into the Linux kernel. The kernel uses the SPDX identifiers, additionally the kernel "COPYING" and "LICENSE" files differ from those in zstd.

Proposed license blurb for source/header files.

 * This source code is dual-licensed under the BSD-3-Clause license and
 * GPL-2.0-or-later.
 * You may select, at your option, one of the above-listed licenses.

@terrelln note that the v11 of the patches reference the wrong identifiers. Somewhat of a clear example that the current references are vague.
The v11 patches use SPDX-License-Identifier: GPL-2.0 vs actual license SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause

Last but not least, I am not a lawyer so please check this with your relevant department.

Hope it helps o/

[pombredanne]

I was about to file an issue because there are also inconsistencies between the SPDX declaration and the notices in the kernel code at

zstd/contrib/linux-kernel/zstd_compress_module.c

Line 123 in 12c045f

MODULE_LICENSE("Dual BSD/GPL");

and elsewhere:

1. SPDX-License-Identifier: GPL-2.0-only is clear but in conflict with both ..
2. the fuzzy reference

 * This source code is licensed under both the BSD-style license (found in the
 * LICENSE file in the root directory of this source tree) and the GPLv2 (found
 * in the COPYING file in the root directory of this source tree).
 * You may select, at your option, one of the above-listed licenses.

... and
3. the MODULE_LICENSE MODULE_LICENSE("Dual BSD/GPL"); (which is a mandated in LKMs)

I suggest this crisp and clear single top level declaration everywhere that would be this way:
SPDX-License-Identifier: BSD-3-Clause AND GPL-2.0-only
and nothing else.
Note also that there are a few other licenses that would be benefited of the same clarity.

Would you want a patch to fix these?

[evelikov]

3. the MODULE_LICENSE MODULE_LICENSE("Dual BSD/GPL"); (which is a mandated in LKMs)

Note that the "BSD/GPL" wording is ambiguous as outlined in the "SPDX IDs reduce license errors and risks" section in here.

I suggest this crisp and clear single top level declaration everywhere that would be this way:
SPDX-License-Identifier: BSD-3-Clause AND GPL-2.0-only

From the current license blub You may select, at your option, one of the above-listed licenses it should be OR instead of AND .. me thinks.

Would you want a patch to fix these?

I suspect that FB won't object to a PR as long as you've signed the CLA. I would be in favour of having this cleared-up, regardless of the licenses used.

[pombredanne]

@evelikov you wrote

1. the MODULE_LICENSE MODULE_LICENSE("Dual BSD/GPL"); (which is a mandated in LKMs)

Note that the "BSD/GPL" wording is ambiguous as outlined in the "SPDX IDs reduce license errors and risks" section in here.

You are entirely right, yet this has a long history and is well documented here https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/module.h#n193 . This is used by many LKMs is this is s standard that is unlikely to change.
(disclosures: I helped adopt SPDX ids in the kernel otherwise and I am an SPDX co-founder)

I suggest this crisp and clear single top level declaration everywhere that would be this way:
SPDX-License-Identifier: BSD-3-Clause AND GPL-2.0-only

From the current license blub You may select, at your option, one of the above-listed licenses it should be OR instead of AND .. me thinks.

Good catch! of course: stupid of me! Note that to be correct there are also several other licenses that could be listed. Some code is under a BSD-2-Clause and may be a few more.

Would you want a patch to fix these?

I suspect that FB won't object to a PR as long as you've signed the CLA. I would be in favour of having this cleared-up, regardless of the licenses used.

That should not be an issue.

[kappapiana]

Good catch! of course: stupid of me! Note that to be correct there are also several other licenses that could be listed. Some code is under a BSD-2-Clause and may be a few more.

I agree, this should be clarified and it should be OR. Even without reading the README section, it appears a dual licensing, and in the trade dual means "you can choose". In this case, if you don't create derivatives, or the derivatives are inbound/outbound compatible with both licenses, you can apply the same licensing scheme, methinks.

[terrelln]

Should be clarified now. Please re-open if you have further questions.

[evelikov]

@terrelln not quite. All the code I've looked in https://github.com/facebook/zstd/tree/dev/lib contains the original license blurb as reported initially. The comments just above somewhat clearly demonstrate that in itself is not clear enough.

I would suggest adding the SPDX-License-Identifier in addition (or instead of) them, especially since they became an ISO standard.