Good points.
On #1, if I publish the web pages to spdx.org/licenses/preview a manual review of the license text could be performed - a bit labor intensive, but possible. I like the idea of #2 - It would require maintaining the original text files along with the XML for test purposes. We could put those in a folder "license-texts" named by license ID (e.g. Apache-1.0.txt). This could be easily populated from the text files in the current repository. The code used to build the website files already does quite a few integrity checks for the license metadata. It would be an easy addition to verify the text matches for the produced license templates. In terms of automating the process, we could use Travis-ci to automate the build/test. I need to research how to accomplish this since this isn't your standard Java or Python project. If there are any travis-ci or Maven experts on the distribution list, any help on this would be appreciated. Gary From: Brad Edmondson [mailto:brad.edmond...@gmail.com] Sent: Monday, May 16, 2016 5:21 PM To: Kris.re Cc: Gary O'Neall; J Lovejoy; SPDX-legal Subject: Re: Starting to work on tools for the new XML license Would this also be an opportune time to think about/discuss (1) a one-time check that our manual modifications haven't borked the text? and (2) some type of continuous integration or unit testing to make sure our changes don't screw up matching against texts we believe should always match? -- Brad Edmondson, Esq. 512-673-8782 | brad.edmond...@gmail.com On Mon, May 16, 2016 at 10:13 AM, Kris.re <kris...@bbhmedia.com> wrote: I do think we’ll want some sort of XML manifest; we need at least somewhere to define the synonyms, among other bits. From: Gary O'Neall [mailto:g...@sourceauditor.com] Sent: Sunday, May 15, 2016 14:26 To: Kris.re <kris...@bbhmedia.com>; 'J Lovejoy' <opensou...@jilayne.com>; 'SPDX-legal' <spdx-legal@lists.spdx.org> Subject: Starting to work on tools for the new XML license Hi Kris, Jilayne and legal team, I'm seeing a lot of activity on the XML licenses, so I started looking into expanding the tools that generate the website to support the new XML format. Here's what I'm currently thinking: - write a new command line tool which takes three parameters, a tag name for the Git repo, a release date and the output directory. The tag name must also be the version name used on the website. The default for the tag is just the latest from master and the default for release date would be today's date. - The application would fetch the XML files from git and translate them into the different file formats including the files used to push to the website. A few questions: Would it make sense to have an XML file that describes the release date and version name in the repo? This would eliminate the second parameter to the application and provide better control over the release name. Another alternative would be to pull this info out of the git commit (use the date of the commit itself for the release date). Once I get this up and running, do you want me to post the results to spdx.org/licenses/preview? Also - Anything else you want me to fix while I'm in there (like the OSI text in the individual license pages)? Let me know your thoughts. Thanks, Gary ------------------------------------------------- Gary O'Neall Principal Consultant Source Auditor Inc. Mobile: 408.805.0586 Email: g...@sourceauditor.com _______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
