I’ve been using it in our Protex software post-bakeoff and it seems to be working fine in that context.
Would it make sense as part of this release to update the included (offline) license list to 2.1? From: Gary O'Neall Date: Tuesday, August 25, 2015 at 12:52 PM To: Yev Bronshteyn, "[email protected]<mailto:[email protected]>" Subject: RE: License List Version in SPDX Tools Hi Yev, Good thought. Let's push out a binary release first, then tackle the EOL issue. Let me know if you think the current version is stable, then I'll push it out to Maven and Git. Gary From: Yev Bronshteyn [mailto:[email protected]] Sent: Monday, August 24, 2015 3:56 PM To: Gary O'Neall Source Auditor; [email protected]<mailto:[email protected]> Subject: Re: License List Version in SPDX Tools Comitted the fix (BUG-1309). Also threw in addition of created date by default (when not in model), as that field is mandatory. A thought occurs, though: If nobody’s committing anything for a few days, maybe this is a good time to fix all the line-break issues and then hard-code eol=lf in .gitattributes? From: Gary O'Neall Date: Monday, August 24, 2015 at 3:06 PM To: Yev Bronshteyn, "[email protected]<mailto:[email protected]>" Subject: RE: License List Version in SPDX Tools Hi Yev, We should definitely fix the documentation - there are probably more errors like this in the JavaDocs since I changed the name of the class but may not have updated all the class name references. I like the idea of setting the license list version by default - that would be a good enhancement for usability of the library. We would just want the API's to be backwards compatible. If I remember correctly, the license version is getting pulled from the action SPDX Licenses website. We should also fix the code so valid versions are returned. I can think of a few solutions: A) Fix it at the source - change the version in the spreadsheet which is the input to the HTML files generated for the license pages which is parsed by SPDX Tools for the version B) Fix the tool which converts the spreadsheet to the website to form a valid version C) In the method that gets the version, parse it and turn it into something valid D) Hard-code the version and update the tools whenever the license list is updated I'm thinking C would be the most useful since there is already "bad data" out there in terms of the version. This would not only fix it for the current website but would also work if anyone is using old license list data (either cached or their own copy). We could also generate a warning in the tool that creates the web pages. Feel free to many any or all changes - I'm not actively updating the tools code for the next 2-3 days, so this is a good time to make changes (ie: no merge conflicts). Thanks, Gary From: Yev Bronshteyn [mailto:[email protected]] Sent: Monday, August 24, 2015 11:25 AM To: [email protected]<mailto:[email protected]> Cc: Gary O'Neall Source Auditor Subject: License List Version in SPDX Tools I noticed that calling ListedLicenses.getListedLicenses().getLIcenseListVersion() returns "2.1 Jun 30, 2015”, which is the version followed by a date. While informative, this “version” can’t be used to set the license list version of an SPDX document, as the spec requires the latter to be of the form “M.N”, where M is the major number and N is the minor. And here it gets interesting: * The javadoc for the method is "Version of the license list being used by the SPDXLicenseInfoFactory”. This not only does not describe what behavior to expect, but references a deprecated class. If the version followed by a date is the expected output of this method, we should document it, so that the consumer may know to parse out the date in setting the license list version property on an SPDX document. * It might be easier for SPDX tools just to set the license list version of the document by default, so that the API user doesn’t even have to worry about it. I’m happy to make the changes, just want to be sure I’m not missing anything. Thanks. Yev
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
