Whoops, accidentally prematurely sent my reply. The goal that I’m hoping to realistically attain is to have tooling automatically generate these files, thus alleviating a lot of scut work done by podlings and mentors. Maybe not a realistic goal but a pretty good dream. :)
On to the details: On Feb 8, 2014, at 7:42 PM, sebb <seb...@gmail.com> wrote: > On 8 February 2014 16:49, Alan Cabrera <l...@toolazydogs.com> wrote: >> Do you think it would be helpful if we had a tool that generated these >> files? It could work like a command line wizard that prompts the person for >> licensing information and then generates a valid disclaimer, notice, etc. >> files. > > AIUI the disclaimer file is the same for every project - only the > project name changes. > Seems unnecessary to automate this, though it should be trivial to implement. Agreed, though it would be handy for podlings that are starting out, imo. > The NOTICE file is much harder to automate, as it depends on knowing > what is actually going to be shipped and reading and interpreting all > the relevant licenses. > However it might be possible to create a sort of expert system that > asked the right questions and guided the user to create the NOTICE > file. That’s my thinking. The tool would ask various questions about their project. Maybe even introspect maven POMs, gradle files, etc. to collect information. Then generate appropriate NOTICE files. I think that the real work would be creating and maintaining a database of licenses for 3rd party products. This could be incrementally created by the above tool. >> If this is a good idea, what files should we generate? Currently, all I can >> think of is disclaimer and notice. >> >> Maybe it could add the info into the project's DOAP file. If we worked out >> the kinks then we could create sbt/gradle/mvn plugins to read the DOAP file >> and insert these files into the correct places in the distributions. Apache >> RAT could also use this info as well. > > The DOAP could certainly be used to create the DISCLAIMER. > > It seems wrong to include any dependency information in the DOAP. > > Dependencies must be present somewhere in the build scripts, however > even in Maven (which has very structured info) it's not at all easy to > determine which dependencies are actually included in the release > artifacts (and remember that source and binary artifacts may need > different NOTICE files) All the more reason to having tooling take care of this. > Note also that some source files may require attribution in the NOTICE file. > These won't be documented in any build system; the info has to be > added to the NOTICE file manually when the code is added to SCM. > >> WDYT? > > Non-trivial; maintaining the meta-data needed to accurately generate > the NOTICE file is likely to require more effort than writing the > NOTICE file itself Yeah but that effort is amortized over many projects and release reviewers. Regards, Alan
