On Tue Jun 12 16:20:35 2012, Kevin P. Fleming wrote:
On 06/12/2012 03:06 PM, Peter Williams wrote:
So the questions is: Is it better to have SPDX files which contain a
large amount of truly useful information but that are incomplete or
should we hide all that information because we are missing one tiny
little piece?
I would question whether this is one 'tiny little piece' or not. In my
role as a consumer of such incoming license information, I would be
unwilling to accept SPDX data describing a package unless I could
conclusively confirm that the package supplied matched the data in the
SPDX file.
Fair enough. For you that might qualify as a large piece of information. You might choose not to accept SPDX files missing this information. Obviously any file not containing the information needed to accomplish your goals is useless. I, however, might find it perfectly acceptable. The strict approach results in us both being deprived of the information.
Is it worse to receive a data set that is too incomplete to use for your purpose, or not receive any data at all? It seems to me that to two situations are practically the same, in either case you have no new information. On the other hand, if you can accomplish your goal with the incomplete data set, then receiving it improves your situation substantially. Let's err on the side of helping as many people as possible.
Even if you choose not to accept an incomplete file verbatim, having it might still be advantageous. If nothing else it gives you a place to start your investigation. For example, if i receive an SPDX file w/o a packageVerificationCode, i might decide i need to do my own analysis of the package i am using because i cannot verify that is exactly the one described by the SPDX file. Fortunately, the licensing of software packages rarely change dramatically between versions so i could use the untrusted SPDX data as a starting point. Such a head start would be likely to save a great deal of time and effort. This would be about the same process needed if i received an SPDX file with a packageVerificationCode that did not match my package.
Peter
PS: This is obviously a forward looking discussion. These fields are mandatory in 1.0, and will be in 1.1, so they need to be in SPDX files produced under those version. However, for 2.0 i think we could greatly encourage adoption by relaxing some of these constraints from "must have" to "should have". And we would get that benefit with no practical downside at all.