Yev, Can you please send around the tag-value equivalent of https://bitbucket.org/yevster/spdxtraxample/src/HEAD/sampleSpdx/1packageWithStaticLink.rdf
? It should be more pleasing to the eye /human-readable & editable... Bill Schineller VP Engineering - KnowledgeBase Black Duck Software 781-425-4405 508-308-5921 (cell) [email protected] On 4/13/16, 11:23 AM, "Yev Bronshteyn" <[email protected]> wrote: >"But I don't want to analyze *any* files, so for my use case a filesAnalyzed >attribute is irrelevant (as I understand it).” > >This is exactly the point of the filesAnalyzed attribute. Before 2.1, SPDX >required that you analyze files. Now, you can set that attribute to “false”, >and no more files analysis. The no more checksums, no more package contents. >You can just use SPDX to express information about and relationships among >high-level packages (see the example in my link). > > > >On 4/13/16, 11:20 AM, "Wheeler, David A" <[email protected]> wrote: > >>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
