On 12/28/11 14:02, Benson Margulies wrote: > On Wed, Dec 28, 2011 at 8:42 AM, Robert Burrell Donkin > <robertburrelldon...@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
