On Mon, 2018-12-03 at 10:34 -0500, Michael Dolan wrote: > So if I can summarize my the situation we're discussing: > > 1) The additional permission is from one or more of many authors and > would only apply in a situation where that author(s)' code is being > enforced as part of a work.
Yes. As I said this is the reason I don't think we'd apply the tag unless it were reliable (i.e. all authors demonstrably agreed). However, there's no current kernel plan for this, it was just a speculative answer to a theoretical "how would we handle it if it arose" question. > 2) The license for the file, any resultant binary or the work would > not change. the KES is effectively a conditioned covenant not to sue, so it's very much like an additional right, like a patent grant. > 3) The KES was never drafted as a license exception that would apply > to a file or compiled work. Agreed. The KES kernel process is designed to work on the single statement file which authors and companies sign to cover their entire contributions. > I think my concerns can be summarized as: > > A) Has there ever been a SPDX license exception where the exception > only applied to only an individual's contributions of code in a file > or work? We often rely on license headers or statements in LICENSE or > COPYING files to identify a license exception. Here we would need to > go to the KES in the documentation file and then cross check that > against the git commit itself to identify the author. I'd strongly advise no to this. The SPDX tags are supposed to make reliable statements to downstream recipients about the licence of the file. Anything not all authors of the file agree to isn't a reliable statement ... and probably would cause all sorts of issues with the DCO on fairness grounds (if one author hasn't agreed, why do I have to?). Which would basically negate all the good SPDX and DCO work we've done. That's why I suggest we'd never apply the tag to a file we couldn't round up entire author agreement for ... and if there are legal questions like this around the tag I don't think we'd ever use it. > B) If the license for the file, compiled binary or overall work are > not modified under this situation, what role does SPDX play in a file > distributed between parties? What about in a SPDX license identifier? > > D) I'm concerned about the concept the DCO captures a KES on > contribution. Further how would that be tracked? At the moment there is no KES on file concept in the kernel. I merely theorised how it would work if someone one day submitted a file with one. If it's going to be legally problematic, we can just never allow it (although that decision would be for the kernel community to make not me). As for tracking: git ties the signoffs in commit messages to modified files, so that's about as strongly tracked as you can get. I can use git to go from any file to all the author signoff statements (well, at least as far back as signoff history goes). > D) If we accept A), how likely is it this will be misapplied? Should > we enable this at all? My answer is simple: don't accept A). Any SPDX tag and modifier must represent the reliable state of the licence which means it must have been agreed to by all authors of the file. James -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2460): https://lists.spdx.org/g/Spdx-legal/message/2460 Mute This Topic: https://lists.spdx.org/mt/28501931/21656 Group Owner: spdx-legal+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-legal/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
