Better support for multiple licenses

I'll look at this ASAP, and try to get something ready for review before the weekend.

I've started looking at this. Here are the relevant quote from the GitHub issue linked in the summary addressing the challenge of allowing multiple licenses to be specified:

From what I have found, it seems that the licenses in the pom.xml are actually an OR. The maven reference says:

"If multiple licenses are listed, it is assumed that the user can select any of them, not that they must accept all."

So, support for a conjunction of licenses seems to be missing; not sure how to proceed for the AND operator.

So they've standardized on the natural language interpretation of OR (a choice between alternatives). I think that is a good choice.

The semantics of AND is not specified, but by extention, I presume that the AND operator is means that the downstream user can't choose, but must continue to license derivatives under all listed licenses. Such an AND will not applicable to code in the Drupal.org, as would not be compatible with Drupal policy for code (GPLv2+), but AND may be used for non-code?

Drupal.org has also introduced its own expression GPLv2 AND LATER, abbreviated GPLv2+. We know the semantics of this: It means "GPLv2, but with an option for downstream recipients to choose a later version of the GPL".

I've also taken a look at the syntax used by SPDX expressions, and reproduced some examples:

• Dual licensing (user can select any of them): { "license" : "(ISC OR GPL-3.0)" }
• License lives in a specific file: { "license" : "SEE LICENSE IN <filename>" }

 
Here is another quote from the GitHub issue linked in the summary:

Wow. They sure love making the parsing of this metadata fun. I'm not sure we can express the differences between AND and OR in the pom.xml. I can't tell from the pom definition whether multiple licenses are an AND or an OR so I'm not quite sure what to do about this.

I am not convinced that moving away from the natural language single line format we currently use is a good idea. This is supposed to be human readable, and then natural language makes a good choice.

I've updated the issue summary with the tasks I think follows from this. Please add more tasks as you see fit.

Typo

I've looked at it and do not think we should move away from the single line format for licenses.

As for semantics it looks like “and” and “or” are both used to list multiple licenses. As far as I have been able to tell, they do not differ in semantivs: If multiple licenses are listed, it is always assumed that the user can select any of them, not that they must accept all.

I've added a note about this to the documentation, and believe that this resolves this issue.

Please review.

Unless there are any objections in the next two weeks, this will be closed as "won't fix" in about two weeks.

kreynen wrote:

So when dealing with an AND situation, the project maintain should add any assets where a parent asset uses a different [license] independently?

I am sorry, but I do not understand the question.

What is the semantics of an “AND situation”, ans how does it differ from an “OR situation”?

Could you link to some real life project where an “AND situation” exists?

OK, so the situation you're talking about is where a project includes several independent components, and these components are not all under the same license.

In that case, each component shall require an independent entry in the LWG_NOTICE.yml, with its own unique identifier (i.e. not all licenses in use in the repo listed on a single line with the conjuction "and").

This way of indicating different licenses for different components have always been supported by the suggested format, and will not require format redesign.