On Mon, Oct 2, 2017 at 12:50 PM, J Lovejoy <opensource@...> wrote:

I’m not sure if it needs to be added alone or if the combination with the
class path exception is such that they are used together and so we ought to
treat it as one exception. but that is another consideration (which someone
else already noticed)

Jilayne:

Here are my 2 cents:

- the text of the “assembly exception” is specific to the OpenJDK and
derivatives: this code is used widely but there are very few projects
that can use this licensing because of its specificity.

- the “assembly exception” text and the designated modules list refers
to the classpath exception and I do not know of any case of "assembly
exception" texts and designated modules list used without a reference
to the classpath exception so far.

- Wayne suggested to introduce a new "with assembly with classpath"
expression syntax to deal with the “assembly exception” and "classpath
exception" cases.

Instead, the way I am handling this for now to detect licensing
properly in ScanCode is with a new "openjdk-exception" key that has
the combined text of the classpath-exception-2.0 and the "assembly
exception"

The benefits are that there is no need to deal with any new "with
with" expression syntax and I think it captures well the cases where
the classpath exception is used alone or used with the assembly
exception (e.g. as "openjdk-exception") and this avoids to create a
special case for this.

--
Cordially
Philippe Ombredanne