[whisker] Integrating Generation Into Maven Application Assembly

[Robert Burrell Donkin <ro...@blueyonder.co.uk>]

(Whisker wrangles licensing materials for applications assembled from
numerous components)

The plugin for Maven now generates LICENSE and NOTICE documents from a
descriptor. The next step is working out the best integration approach.

The primary use case is easing licensing maintenance for applications
assembled by Maven from large numbers of components (like Apache James
email server). I suppose that these documents could just be copied over
during assembly but is this the best approach?

Would deeper integration bring any benefit?

Opinions? Ideas? Objections?

Robert

Re: [whisker] Integrating Generation Into Maven Application Assembly

[Robert Burrell Donkin <ro...@blueyonder.co.uk>]

On 12/28/11 14:02, Benson Margulies wrote:
> On Wed, Dec 28, 2011 at 8:42 AM, Robert Burrell Donkin
> <ro...@blueyonder.co.uk> wrote:
>> (Whisker wrangles licensing materials for applications assembled from
>> numerous components)
>>
>> The plugin for Maven now generates LICENSE and NOTICE documents from a
>> descriptor. The next step is working out the best integration approach.
>>
>> The primary use case is easing licensing maintenance for applications
>> assembled by Maven from large numbers of components (like Apache James
>> email server). I suppose that these documents could just be copied over
>> during assembly but is this the best approach?
> 
> Wandering in at this point, so please excuse redundancy:
> 
> It seems to me that the Maven data model is sadly weak here. Maven
> components can have a license, but no machine-readable specification
> of NOTICE requirements. I am thus thinking that a plugin can assist in
> maintaining a file that keeps track of the information that must be
> sorted out by people.

+1

This model turns out to be quite complicated, and I expect will need to
be expanded over time. So, perhaps not a good match for inclusion within
the core Maven data model.

For example, many open source 'licenses' (from a Maven perspective) are
actually parameterised families with similar legal qualities but
difference text.

> Essentially, it's a table: DEPENDENCY, LICENSE, NOTICE

Whisker is aimed at assembled applications (so some people might slice
definitions about 'DEPENDENCY') but essential yes.

The licensing materials you need to safely ship a component (as part of
an assembled application) sometimes differ from those you need just to
depend on one.

For example, some weak copyleft licenses require that a link to the
source is included in a NOTICE when you distribute the binary.

> where NOTICE could be 'none', or an indication to pull the contents of
> some file in the dependency's jar file, or some text to include in the
> NOTICE file.

This was the original idea, but it turns out not to be feasible. At the
moment, all this information has to be included in the descriptor.
(Maybe one day we could figure out some way to maintain reliable
meta-data centrally.)

For example, some jars in the Maven repository have been extracted from
their distributed context and lack licensing materials. In this case,
manual work is needed.

> Plugin goals would create this file, add or subtract from it based on
> current state of the dependency graph, and ultimately generate the
> desired NOTICE file for the whole business.

Not just NOTICE but LICENSE and CRYPTO documents as well

> It also strikes me that there's an aggregation question: when a
> project makes an aggregated source release in addition to some
> collection of binary things, all of this has to be summed across the
> individual components.

The rules adopted by licenses for shipping source are sometimes quite
different to shipping binary artefacts, but I expect that it should be
possible for source.

Robert

Re: [whisker] Integrating Generation Into Maven Application Assembly

[Benson Margulies <bi...@gmail.com>]

On Wed, Dec 28, 2011 at 8:42 AM, Robert Burrell Donkin
<ro...@blueyonder.co.uk> wrote:
> (Whisker wrangles licensing materials for applications assembled from
> numerous components)
>
> The plugin for Maven now generates LICENSE and NOTICE documents from a
> descriptor. The next step is working out the best integration approach.
>
> The primary use case is easing licensing maintenance for applications
> assembled by Maven from large numbers of components (like Apache James
> email server). I suppose that these documents could just be copied over
> during assembly but is this the best approach?

Wandering in at this point, so please excuse redundancy:

It seems to me that the Maven data model is sadly weak here. Maven
components can have a license, but no machine-readable specification
of NOTICE requirements. I am thus thinking that a plugin can assist in
maintaining a file that keeps track of the information that must be
sorted out by people.

Essentially, it's a table: DEPENDENCY, LICENSE, NOTICE

where NOTICE could be 'none', or an indication to pull the contents of
some file in the dependency's jar file, or some text to include in the
NOTICE file.

Plugin goals would create this file, add or subtract from it based on
current state of the dependency graph, and ultimately generate the
desired NOTICE file for the whole business.

It also strikes me that there's an aggregation question: when a
project makes an aggregated source release in addition to some
collection of binary things, all of this has to be summed across the
individual components.



>
> Would deeper integration bring any benefit?
>
> Opinions? Ideas? Objections?
>
> Robert