Trevor, Maybe I have missed it in the thread, but what are the terms the "Verbatim" license would refer to?
Is it intended to refer to a specific set of licensing terms or just a category of possible explicit or implicit licensing statements? For example the licensing terms for redistributing the GPL as contained in the GPL: "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." (If we are moving past the licensing of a license and talking about other kind of content, then that is probably a bad example.) Nonetheless FSF use to recommend the following "Verbatim Copying and Distribution" licensing statement for use with works that express an opinion: "Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided this notice is preserved." [1] And that licensing statement was supplemented with commentary: “Our intention in using the phrase ‘verbatim copying in any medium’ is not to require retention of page headings and footers or other formatting features. Retention of weblinks in both hyperlinked and non-hyperlinked media (as notes or some other form of printed URL in non-HTML media) is required.” But now the FSF recommends the CC BY-ND 4.0 instead. If one were to tag the content on say the FSF website as "verbatim," does that help us understand what license the content is being offered under? Unless verbatim means something specific it appears its meaning could shift over time or from context to context. If we mark FSF content as "verbatim" I can see three different licensing terms to consider. Perhaps the differences in language don't matter in most cases, but I can't image that they would never matter. Having raised that question. I do think you are right that people should be mindful to not just focus on the license of the source code in the package. In my experience FOSS producers are frequently interested in licensing the content that accompanies the source code under different terms then the source code. I have found this to be especially true of web applications, where the producer wants to provide a working demo, is comfortable sharing the source code under a FOSS license, but for some reason does not want to give blanket permission to use or modify images. The license of a package is often more complicated than just the license of the source code, and if package contains other kinds of content such as documentation or default content that are distributed under different terms should be recorded (or split into a different package.) For example Facebook's React project provides the source code for the library under a BSD copyright license [2] but the example code under a non-FOSS license. [3] And the React documentation is under a CC license [4]. (I am intentionally ignoring the patent license and only referring to copyright licenses for sake of simplicity.) Tagging all of the source code in the React git repo as being under a permissive BSD copyright license since the examples are actually under a really restrictive license. As I said before though I continue to agree with other commenters that the license of the license seems to me to be outside of the scope of SPDX. -Marc [1] https://www.gnu.org/licenses/licenses.html#VerbatimCopying [2] https://github.com/facebook/react/blob/master/LICENSE [3] https://github.com/facebook/react/blob/master/LICENSE-examples [4] https://github.com/facebook/react/blob/master/LICENSE-docs On Tue, Sep 12, 2017 at 12:56 PM W. Trevor King <wk...@tremily.us> wrote: > On Tue, Sep 12, 2017 at 04:38:57PM +0000, Andrew Katz wrote: > > My recollection is that Apache 2.0 is under Apache 2.0, also. > > All explicitly-licensed licenses are going to eventually end up in > some sort of loop like this (although you could have an A → B → A… > cycle, etc.). Doesn't it seem like we'd want to record that > information? For licenses that are not explicitly licensed, the right > to distribute and/or modify them is going to be based on fair use, > estoppel, etc. I'm not sure we have a way to represent that in SPDX > license expressions. > > However, regardless of whether we decide to record the license for > each of our licenses, I think adding a Verbatim license to the license > list is a useful addition. That would allow other SPDX authors/tools > to record the license of Verbatim content if *they* wanted to give the > terms under which their Verbatim license content [1] or DCO copies > [2,3] were distributed. Then SPDX can, like other SPDX authors/tools, > decide where it wants to apply the Verbatim license without relying on > a LicenseRef. > > Cheers, > Trevor > > [1]: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING?h=v4.13#n17 > [2]: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v4.13#n429 > [3]: https://developercertificate.org/ > > -- > 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 > _______________________________________________ > Spdx-legal mailing list > Spdx-legal@lists.spdx.org > https://lists.spdx.org/mailman/listinfo/spdx-legal >
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal
