zstd
zstd copied to clipboard
Vague license references
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/
I was about to file an issue because there are also inconsistencies between the SPDX declaration and the notices in the kernel code at https://github.com/facebook/zstd/blob/12c045f74d922dc934c168f6e1581d72df983388/contrib/linux-kernel/zstd_compress_module.c#L123 and elsewhere:
SPDX-License-Identifier: GPL-2.0-onlyis clear but in conflict with both ..- 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?
- 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.
@evelikov you wrote
- 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-onlyFrom the current license blub
You may select, at your option, one of the above-listed licensesit should beORinstead ofAND.. 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.
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.
Should be clarified now. Please re-open if you have further questions.
@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.