Dear Gary,
In message <001f01cec2e5$9f1d9b20$dd58d160$@com> you wrote:
>
> The "AND" situation would occur if you have a file which contains code from
> two or more different sources using two or more different licenses. In that
> case, I believe you would need to satisfy the obligations of all licenses
> (note: I'm not a lawyer so I am not proposing or providing a legal
> interpretation). Hopefully there is no conflict between the license
> obligations.
I don't think this could work.
We encountered such cases when we analyzed the U-Boot code while
introducing license tags. There were some files that came with a the
full GPL-2.0+ license header, but further down in the code that had a
short comment that some parts (a few functions) have been copied from
the Linux kernel. The analysis shows that the original Linux kernel
files were covered by GPL-2.0 only.
If I follow your argument, this code would now be covered by a
"GPL-2.0+ AND GPL-2.0" license construct. This is obviously absurd: I
cannot both include and exclude the "or later" option simultaneously.
Our understanding of the legal situation left two solutions: either
we remove the GPL-2.0 code (and replace it by a clean-room
implementation of similar functionality), or we change the file's
license terms to GPL-2.0. We did the latter: the files are now
licensed under GPL-2.0, i. e. the "or later" option had to be dropped
for the file as a whole, because it was not available for the parts
imported from Linux.
There was no way to "AND" both licenses here.
> ---
> For a license set, when there is a choice between licenses ("disjunctive
> license"), they should be separated with "or" and enclosed in parentheses.
> When multiple licenses apply ("conjunctive license"), they should be
> separated with an "and" and enclosed in parentheses. Example: (LGPL-2.1 or
> MPL-1.1).
> ---
Do you have an example, where such a "conjunctive license" construct
actually works?
> We were also concerned about the difficulty in parsing the strings. We came
> up with enclosing them in parenthesis to aid in accurate and unambiguous
> parsing. For example, (LGPL-2.1 and (MPL-1.1 or BSD-3-Clause)) would
> describe the licensing for a file which contains code from an LGPL 2.1
> package and code from a package licensed under a choice of MPL-1.1 or
> BSD-3-Clause.
Understood. However, I think these are only very few pathological
cases, and it would be nice to keep the syntax simple for the
overwhelming majority of practical use cases. My vote goes for a
simple white speace separated list of license IDs which should be
interpreted as "OR". Do you think it would be possible to extend the
spec to allow for the (much easier to parse)
<lic1> <lic2> [...]
as synonym for
(<lic1> OR <lic2> [OR ...])
?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected]
Steal five dollars and you were a petty thief. Steal thousands of
dollars and you are either a government or a hero.
- Terry Pratchett, _Going_Postal_
_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech
