Hi Jason, Thanks for the response and suggestions.
Currently, the plugin is only taking information from the POM and formatting it as an SPDX file. With the plugin, I am primarily targeting developers and organization which originate the code. In this case, the license information in the POM is (hopefully) accurate. This does depend on the developer or organization updating the license information in the POM file. From my experience, this is not always done - but in the case where the license information is included, the SPDX file would be generated saving the developer the effort of creating the SPDX file with an external tool (or worse - manually). I do have a TODO to scan the source files for specific SPDX license identifiers. There is an SPDX effort underway to standardize a format for license information which could be put in the comments within the source files. I agree with your issue that it could be misleading if we state licenses that are not validated. To address this, the default license is "NOASSERTION" if the license is used if the license is not not specifically stated in the POM file for the project or the files. If the POM file contains an actual license reference, that is used. There are configuration parameters to control this behavior, but the defaults are set conservatively to address this issue. I'm familiar with JNinka and it would be a good parser to use, but it has some licensing issues (licensed under AGPL which would make it incompatible with some of the Apache projects). Like all code scanners, it is not 100% accurate which could lead to some misleading results in some cases. I find that you always need a human to validate the results of the source code scanners. That being said, somehow integrating code scanning into the plugin would definitely save time for those cases where the POM file is not generated by the originator of the code. Perhaps there could be a JNinka maven plugin which creates some data that the SPDX plugin consumes to create the SPDX file. Something worth exploring. Let me know if you have any thoughts on how this may be structured in Maven. Gary > -----Original Message----- > From: Jason van Zyl [mailto:[email protected]] > Sent: Monday, January 27, 2014 11:06 AM > To: Maven Developers List > Subject: Re: SPDX Maven Plugin > > Gary, > > Does the plugin do any source level scanning to determine licenses, or > are you just taking the information from the POM? If you're using > something like JNinka[1] to figure out what licenses are actually > present then that's a first step. Actually determining if it's a valid > set of licenses is another step. But if it's just taking information > from the POM I'm not sure that's useful and may potentially be more > harmful as people might think "Oh, it has an SPDX descriptor so it must > legally accurate." > > [1]: https://github.com/whitesource/jninka > > On Jan 20, 2014, at 12:20 PM, Gary O'Neall <[email protected]> > wrote: > > > Greetings all, > > > > I am somewhat new to Maven plugin development and would like to ask > > the developer community for some feedback and help in developing a > > plugin to generate project license metadata compliant with the > > Software Product Data Exchange (SPDX) standard. > > > > The SPDX specification is a standard format for communicating the > > components, licenses and copyrights associated with a software > > package. We are on version 1.2 of the spec and is in use at several > > of the SPDX participating companies (see www.spdx.org for more info). > > > > The motivation for the plugin was the result of a discussion between > > Phil Odence and myself (from SPDX) and Jim Jagielski and Henri > Yandell > > (from > > Apache) on ideas for how Apache projects could produce or utilize > > SPDX. It was suggested that a maven plugin would substantially > reduce > > the effort for several Apache projects. > > > > Over the past couple weeks, I have studied the Maven Mojo and plugin > > API's and produced a prototype which will generate an SPDX file based > > on a POM file. You can find the code on Github at > > https://github.com/goneall/spdx-maven-plugin > > > > Here's my questions for the Maven Developers: > > - Is anyone on the list interested and have some time to collaborate > > on the plugin? I'm pretty comfortable on the Java and SPDX output > > coding, but I'm new to Maven and could use some experienced review of > > some of my choices regarding Maven parameters and implementation. A > > review of the code would be most appreciated. I could also post the > > more specific questions to this list if that is appropriate. > > > > - Are there any related efforts I should be aware of? (Note: I did > > find another spdx maven plugin on github. I reached out to the > author > > and have not heard back, so I'm not sure how active the project is). > > > > - Once the plugin is built and unit tested, what is the best way to > > make it more accessible to other developers? > > > > - A spreadsheet mapping the SPDX properties to either > > spdx-maven-prototype configuration parameters or existing Maven model > > properties can be downloaded at > > https://github.com/goneall/spdx-maven-plugin/blob/master/SPDX-fields- > m > > aven-m apping.xlsx. Feedback on the prototype choices are welcome. > > There is also a proposed longer term mapping, some of which extends > > the current Maven model. > > > > Thanks in advance, > > Gary > > > > > > ------------------------------------------------- > > Gary O'Neall > > Principal Consultant > > Source Auditor Inc. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] For > > additional commands, e-mail: [email protected] > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > To think is easy. To act is hard. But the hardest thing in the world is > to act in accordance with your thinking. > > -- Johann von Goethe > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
