On Fri, Sep 08, 2017 at 09:28:02AM +0000, Marc Jones wrote: > It is not clear to me that it makes sense to say a code base is both > GPLv2 and verbatim, simply because the text of the license is > copyrighted and you do not have permission to modify the license > text.
So let's replace “license” with “documentation”. You generally get both alongside the source code in a package tarball. And many programs compile to executables or libraries that include neither the license nor documentation content. Are you suggesting that the license of the documentation (which may differ from the source, e.g. GFDL docs with GPL source) does not impact the concluded package license? > I don't actually think it is much different from the 3-Clause BSD > license regardless of if the 3-clause BSD license is in the public > domain. It seems to me that even if the 3-Clause license is in the > public domain, you still do not have permission to modify it in a code > base licensed under the 3-clause BSD license. But you *would* have permission to copy/paste just the BSD-3-Clause wording, make your own edits, and distribute the result. The SPDX way of representing a file containing different sections under different licenses is via snippets [1], although by the time you're marking out BSD-3-Clause blurbs as Verbatim snippets (or whatever), I think you're past the point of diminishing returns. But for licenses that usually live in a separate file (like the GPL), having a Verbatim license seems like a useful addition. > > For license where we do not feel comfortable concluding a license, > > we probably want to stop distributing local copies until we figure > > out what license applies to them (or whether we think they are not > > copyrighted, or if our complete copy of their text falls under > > fair use, or whatever). > > The problem with not including local copies of licenses is that > including a local copy of licenses is actually a condition of a lot > of licenses. So essentially one would have to say that unless the > copyright status of the license text is clear, we can not use SPDX > with that license. Right. But if you're comfortable saying “we're at least allowed to distribute verbatim copies of these because… estoppel… mumble mumble”, then you can go ahead distributing them even without an explicit license. That's not as nice as having an explicit license, clear copyright status, etc., but it's probably good enough. > What value is added if we simply end up tacking onto every SPDX > license code "+Verbatim." You get a more accurate view of the licenses covering the included content. Maybe the Verbatim part ends up being a part that you care about, and maybe it doesn't. Like all composites, it will depend on which content you're interested in. If we are sure that nobody will ever be interested in the license of a license, then we should call that out in the spec (and there's already an ‘excludes’ bit in the spec for when you want to do this sort of thing with file granularity). But I'm not sure that's the case. And I'm really not sure that nobody ever cares about the license that the documentation comes under. And sometimes distinguishing between “code” and “documenation” is tricky (although I expect it's easier to distinguish “license text” from the other two). On Fri, Sep 08, 2017 at 03:44:52PM +0000, Wheeler, David A wrote: > I think the point of SPDX is to enable people to understand the > licenses of the software being used (or under consideration). Do you place documentation inside or outside your “software” box? What about code snippets in that documentation? What about comments in code (which are in the source files, but don't end up in the compiled executable for compiled languages)? I'd rather dodge all of that and give users the tools they need to express the license of all of their content. Then the individual SPDX authors and tools can decide how detailed they want to be. On Fri, Sep 08, 2017 at 11:54:52AM -0400, Brad Edmondson wrote: > It's my understanding that there are varying opinions on the > question of the copyrightability of a license text (or any legal > contract). I tend to think no license text is protectable under > copyright… I expect the FSF folks disagree with you, or they wouldn't have a copyright claim and Verbatim license inlined in their licenses. Is the official SPDX position going to be that licenses aren't copyrightable? Or will we have a Verbatim license so folks who want can use it, and folks who don't feel like licenses are copyrightable can conclude ‘NONE’ (or whatever you're supposed to use for “not copyrightable” for the license file [3] or snippet [4]. I'd rather punt that call to individual SPDX authors and tools. > … but even assuming *arguendo* that it is protectable, recall that > copyright protection is "thin" (as opposed to "thick" protection in > patent or, less so, trade secret) and doesn't bar *all* > copying/distributing/etc. This is melting my brain a bit. Are you suggesting that, say, the FSF could have patents that read on the GPL, so despite the fact that they've explcitly licensed the GPL to us under Verbatim terms, we may still be vulnerable to their patent claims? I have difficulty imaging license-related patents, but I don't see any reason to special-case licenses. These sorts of copyright vs. patent, etc. issues exist on all content that is copyrightable, patentable, etc. Expressing licenses using SPDX identifiers is how we deal with those issues for code and documentation; I don't see why we shouldn't use the same tools to deal with them for licenses. Cheers, Trevor [1]: https://spdx.org/spdx-specification-21-web-version#h.lo3v4sra8jlj [2]: https://spdx.org/spdx-specification-21-web-version#h.2p2csry [3]: https://spdx.org/spdx-specification-21-web-version#h.2lwamvv [4]: https://spdx.org/spdx-specification-21-web-version#h.4e2e263bk6wh -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
