Question regarding the "Modular platform"

[Simon Ritter]

Mark,
thanks for the answers you've provided.  I have some follow-on and 
related questions.

In Java SE 8 and in all prior Java SE releases, there is a clear "all or 
nothing" treatment of what a spec-compliant implementation is: a 
compliant implementation is an implementation that has passed the TCKs. 
Taking such a compliant implementation and distributing only a portion 
of it (e.g. "choosing only the classes you need") is clearly 
distributing something that is not a compliant implementation, and is 
not entitled to the same IP rights that compliant implementations do 
(i.e. is not eligible for the same guaranteed patent licenses provided 
by the JSPA).

Java SE 9, through modules and the jlink capability, creates a new 
(potentially commonly used) mechanism for taking a compliant 
implementation and repackaging some arbitrary subset of that 
implementation's materials for redistribution. This raises various 
IP-rights related questions:

1. Is distribution of the output from jlink packaging for a specific 
application considered distribution of a spec-compliant implementation?

2. Does such a distribution carry IP rights (including patent right) 
that a compliant implementation does via the JSPA?

3. If the answer to the previous question is yes, how does one 
demonstrate that a distribution of a jlink output is compliant with the 
spec?

3.1 How do you run the TCK on this jlink output?

3.2 Who has the rights to run the TCK on such jlink output?

3.3. If no TCK is run on the jlink output, is it compliant?

A possible interpretation of the JSPA IP flow rules is this: under the 
TCK mechanisms that we've seen in the past (we have not yet seen what 
TCKs for Java SE 9 will look like, so maybe something is addressing it 
that we don't yet know about), the answers to the above would be 
straightforward: jlink output created by someone who does not have a TCK 
license cannot be tested with the TCK, cannot therefore (by definition) 
be determined to be a compliant implementation of the spec., and does 
not (by definition) inherit the IP rights that the compliant 
distribution it was built from carried.

Assuming this straightforward possible interpretation is correct, it 
would mean that jlink output artifacts are not practically 
redistributable (or even practically useable) without significant IP 
exposure risk. Using such an artifact would (almost by definition) 
entail making use of known necessary patents without a license allowing 
that use.

This would rather seem to defeat the purpose of jlink.

Regards,

Simon.

On 08/03/2017 17:49, mark.reinhold at oracle.com wrote:
> Volker originally sent this to the java-se-9-spec-comments list, but now
> that he's on the EG I figured I'd just reply here.
>
> 2017/2/22 10:04:26 -0800, volker.simonis at gmail.com:
>> referring to the "Java SE 9 (JSR 379) Early Draft Review
>> Specification" I'd like to get some clarifications regarding the
>> definition of the "Modular platform" and its implications on
>> implementors of Java SE 9.
>>
>> Section "7 Modular platform" of the specification starts with the
>> statement that it "..uses the Java Platform Module System, specified
>> by JSR 376, to modularize the Java SE Platform". One of the goals is
>> to "Divide the Java SE Platform into a set of modules that can be
>> combined at compile time, build time, or run time into a variety of
>> configurations including, but not limited to..Custom configurations
>> which contain only a specified set of modules and the modules
>> transitively required by those modules."
>>
>> What is "compile time, build time, or run time" referring to? Is it
>> the "compile time / build time" of the platform itself?
> No, it's referring to those phases in the development of a library or
> application that runs on top of Java SE 9.
>
>>                                                          I.e. should it
>> be possible for an implementor to only build and assemble a subset of
>> the standard modules into his "Java SE Platform"?
> That's a different question, and the answer is "yes".
>
>>                                                    And will this still
>> be called "Java SE 9"?
> Yes, that's the intent.
>
>> Later on, in the "Conformance" section, the specifications mentions
>> that "Every Implementor of this Specification must implement the
>> java.base module. Every Implementor may, further, implement a set of
>> one or more additional standard SE modules so long as that set is
>> closed, i.e., contains every standard module required by any member of
>> the set.".
>>
>>>  From this and the previous statement I would expect that an
>> independent implementor as well as an OpenJDK distributor could build
>> a "Platform implementation'" which only contains the java.base module,
>> certify that with the Java SE 9 TCK (because "The Technology
>> Compatibility Kit (TCK) for this Specification will be structured to
>> allow testing of arbitrary configurations of SE modules present in a
>> Platform Implementation.") and provide that to its customers. Is that
>> correct?
> Yes, that's the intent.
>
>> And if it is correct, how could a user of such a "Platform
>> implementation" distinguish two different implementations which
>> provide a different subset of standard modules? Currently, as far as I
>> can see in the RI, running "java -v" always identifies itself as
>> "Java(TM) SE Runtime Environment (build 9-ea+xxx)", no difference
>> which modules it contains. The user would have to run  "jimage list"
>> on the modules file to find out which modules are included (not to
>> mention that "jimage" isn't a standard tool anyway).
> The Java SE Platform Specification has never specified command-line
> tools, so there's no such thing as a "standard" tool.
>
>  From a pure SE perspective, you can distinguish implementations that
> contain different sets of modules by examining the set of modules in
> the boot layer via the API:
>
>      java.lang.reflect.Layer.boot().modules().forEach(System.out::println);
>
>  From the command line, the RI supports a `--list-modules` option that
> does much the same thing.
>
>> That said, the "Goals" section also mentions that "standard modules
>> that are part of the Java SE Platform Specification, and thereby
>> mandatory in every Platform Implementation" which seems to contradict
>> with the above points which explicitly allow sub-setting (as long as
>> that set is closed).
> That text is incorrect -- the "mandatory" clause should be removed.
> Thanks for catching this inconsistency.
>
>> Finally, it would be good to have a new version of the "OpenJDK
>> Community TCK License Agreement" (OCTLA) available BEFORE the final
>> vote on JSR 379. I understand that standardization and licensing are
>> two different things. But first, JSR 379 explicitly references the TCK
>> and second voting on a new standard which technically allows
>> sub-setting and modularization is pointless if these new possibilities
>> would be prohibited by licensing. At least the current OCTLA [1]
>> explicitely states that a "Compatible Licensee Implementation" has to
>> "..fully implements the Java Specification, including all its required
>> interfaces and functionality..".
> Work on an updated OCTLA is in progress.
>
> - Mark