search

spdx / tools

SPDX Tools
Apache License 2.0
126 stars 69 forks source link

Remove LICENSE.Spdx file from source tree #195

Closed goneall closed 4 years ago

goneall commented 5 years ago

As mentioned by @vlsi in issue #193 , the LICENSE.spdx file is create a lot of history since it is completely regenerated on each release.

This is produced from the SPDX Maven Plugin. Since it is in RDF format and the Jena libraries do not preserve any order, it gets completely regenerated. I'm thinking it should be removed from the source directory entirely and only store in the release artifacts including Maven Central, Bintray and the Github release artifacts rather than keeping it in a directory under source control.

goneall commented 4 years ago

File has been removed from the tree and is already in the .gitignore file. Note: I will not remove this from history since this is a public repo referenced by other projects.

vlsi commented 4 years ago

Just wondering: do you expect everyone else should keep .spdx files under source control? It looks like a major issue for SPDX adoption.

goneall commented 4 years ago

Just wondering: do you expect everyone else should keep .spdx files under source control?

Really good question. I have changed my opinion on this based on my experience producing SPDX documents over the years.

Current opinion: The SPDX document should be maintained where the output of the build is maintained (e.g. alongside the binary download, source archives, etc.). In this case, we use Maven and store the binaries in bintray as well as Maven Central. You'll find the SPDX documents there. The metadata used to build the SPDX document is maintained in the POM file. The POM file is under source control.

Storing the SPDX documents in the source repo seemed to make sense at the time, but it changes far to frequently. At one point, I wrote an eclipse plugin to maintain the SPDX document on every source file change. I've since abandoned this approach as the constantly changing SPDX document was just too much of a bother.

Note that this wouldn't be a problem if the SPDX filesAnalyzed was set to false and the file checksums and the package verification code was not included. Maintaining something like the proposed SPDX Lite format in source control shouldn't be a problem.

Perhaps a good workflow would be to maintain an SPDX lite version in the source repo and store the generated full SPDX doc in the build output location.