Yev Bronshteyn: > Your use case seems to be already covered by the current SPDX 2.1 spec. With > the new filesAnalyzed attribute on packages, we can now describe packages, > with all their optional metadata richness without going into their contents. > Here is an example of that use case: A package is being described that has a > static dependency on Apache Commons: > https://bitbucket.org/yevster/spdxtraxample/src/HEAD/sampleSpdx/1packageWithStaticLink.rdf
But I don't want to analyze *any* files, so for my use case a filesAnalyzed attribute is irrelevant (as I understand it). I have a different purpose. I want to express that "I, the human developing this software, release the software under license X". I don't want to report on a third-party analysis; I want to make a first-person assertion. But since both situations involve making license statements, we can all build on the common vocabulary of SPDX. By the way, that SPDX file is a good argument *against* the direct use of SPDX use by developers. It's excessively complex. I think you're thinking of the SPDX file as an output format for a tool. And that's great - it's clearly what the SPDX developers had in mind. Enjoy! Don't lose that capability! However, I want to also be able to use human-generated SPDX file as *input* to tools, *not* only as an output, as a way to express the license granted by the humans. Most developers just want to say "my license is <SPDX license expression>." One line would be enough. A few simple lines, at most. Anything longer than about 7 +/- 2 simple lines is too long - it needs to fit in your head, since this is *generated* by humans. For this use case many of the "mandated" terms should be optional, and I expect that XML would almost never be used. Different use case, different constraints, but I think we can *all* work within a single spec. --- David A. Wheeler _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
