Nothing that can convert to tag-value supports this yet. :D
On 4/13/16, 11:30 AM, "Bill Schineller" <[email protected]> wrote: >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
