Hi Kate,
Thanks for the information. I have some responses inline. To be clear I'm veering in to commentary on the format itself for a lot of this, rather than specific statements on whether I think Linaro should use it or not.
On Mon, 06 Jun 2011 18:05:54 -0500, Kate Stewart kate.stewart@canonical.com wrote:
If there are some pretty common trends, we can look at adding fields to support. Its in beta right now so this sort of feedback can be gathered after all ;)
That's good to know.
After every FileName: there should be a FileChecksum: field.
For each file listed in the package, the fields that are mandatory and should show up are:
- FileName:
- FileChecksum:
- LicenseConcluded:
- LicensesInfoInFile:
- CopyrightText:
The rest are optional, and can be included or not.
You say "for each file listed in the package," is it mandatory to list all files? It seems to me that it would be much better to allow for gradual implementation of what will be a large job for some projects, so I hope it is optional.
I guess it's intended for the format to always be output from some tool rather than hand-edited, unless it's possible to put glob patterns or similar in the FileName field?
LicenseConcluded: GPL-2.0
From the spec:
The licensing that the preparer of this SPDX document has concluded, based on the evidence, actual applies to the package.
I think this is where the lawyer would say, this is the license.
Yeah. Again my question is source or binary?
This is captured as an optional field (FileType:) at the file level.
Well, this applies to the whole package by my understanding, so the particular file types may not matter.
Take for instance a package which is dual licensed GPL-2 and something else at the source level. If you choose to build this package and link it against GPL-2 only code then some people's interpretation of the GPL would say that the binary is GPL-2 only, despite the source being dual licensed.
Perhaps that's a minority opinion, but I expect there are other cases where the source and binary licenses may not match, so I am wondering if the expectation that this defines the source or binary concluded license.
Perhaps what you are saying is that there will be different SPDX files for the source and binary, and the difference would be captured there?
My overally impression is that this is rather a large additional overhead to just be able to say
the kernel was built from 0A2E345 of git://git.linaro.org/jcrigby/linux-linaro-natty.git
which is the main thrust of kiko's request as I understand it.
If you just want to say the build origins, then yes its overkill for that. If you want to be able to pass on a package that has a set of patches off a known public kernel (with its own SPDX file ;) ) then it permits the licensing and copyrights to be clearly articulated.
Yeah. Is the kernel going to be released with an SPDX file that we can base our work on?
Debian package standard has no way to track the accuracy of the file level information, so it could change underneath without there being a way of detecting it - which causes problems. If you look at: http://dep.debian.net/deps/dep5/ (machine readable info), you'll see this aspect missing (the wildcards preclude it). The DEP5 proposal was analyzed extensively last year but commercial companies didn't feel they could rely on the accuracy information provided through it, but there is a lot of common ground on the fields provided, file paragraphs, separate licensing section, etc. We've had a team of volunteer corporate lawyers (Motorola, HP, etc. ) working on the SPDX for the last year and reviewing and modifying the proposed fields extensively.
Sure, I don't doubt that a lot of effort has been put in to SPDX, and I don't want to get in to a debate about whether it is a good idea to have wildcards or not. My point was more that I don't see it being worth Linaro engineering time to push for adoption of either format inside Debian packages at this time.
Thanks,
James