"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

Reply via email to