specification
specification copied to clipboard
solid
Add license document
Resolves https://github.com/solid/specification/issues/411 .
This PR proposes to publish mit-license so that TRs can refer to this license document that's explicit about the copyright year and rights holder (and possibly other information, TBD as part of review/discussion here or elsewhere).
I believe mit-license would be preferable to http://purl.org/NET/rdflicense/MIT1.0 (only the MIT license template) and https://raw.githubusercontent.com/solid/specification/main/LICENSE.md (no ties to GitHub or another authority besides the W3C Solid CG or the Solid Project).
Questions:
- What should be the license document's URL be, e.g.,
https://solidproject.org/TR/mit-license? - Should the document be versioned?
- Should the copyright year be "2018" (when the CG was formed) or "2022" (this year) or "2018-2022" or something else?
- What other information should be included in the license document, e.g.,
odrl:Policydetails?
I don't have firm answers for the other bullets, but for this one —
- Should the copyright year be "2018" (when the CG was formed) or "2022" (this year) or "2018-2022" or something else?
— the answer is "each year that the content was created or modified", so if there was a version of the document in 2018, and there were updates each year since, it should be Copyright 2018–2022 {creating entity of record}. If, for instance, there were no changes in 2020, it should be Copyright 2018, 2019, 2021, 2022 {creating entity of record} or Copyright 2018–2019, 2021–2022 {creating entity of record}.
Copyright may be changed to © or Copyright ©.
IANAL. The intention with this license document (mit-license) is so that there is a human/machine-readable version that can potentially be reused/attached to TRs.
The copyright year makes things a bit tricky. When I was preparing the issue/PR, I looked at the following:
https://opensource.stackexchange.com/questions/1522/what-should-be-written-in-mit-license-year-full-name , https://softwareengineering.stackexchange.com/questions/210472/is-renewal-of-mit-license-needed-on-github-at-the-beginning-of-each-year , https://opensource.stackexchange.com/questions/5778/why-do-licenses-such-as-the-mit-license-specify-a-single-year suggest when the copyright was applied (and that they can be at every time there is a change put in place). There is some guidance on copyright year at http://www.gnu.org/licenses/gpl-howto.html where it suggests both individual years as well as a range as a possibility.
I'm not sure if it is correct or meaningful for any document to refer to a license document where its copyright year is earlier than the publication (or creation/issued..) year of a TR. The idea with using range 2018-{current year} was that we'd update the license document once a year. Interestingly, LICENSE.md (starts with 2019) on this repository is intended to cover all documents in this repository; past years as well as the present. So, would it be okay to have any TR link to this mit-license in the same way?
The MIT license templates that I've looked at either didn't use "©" or used "Copyright (c)", e.g., https://opensource.org/licenses/MIT , https://choosealicense.com/licenses/mit/ , https://spdx.org/licenses/MIT.html . One of the comments in the above exchange links mentions https://www.law.cornell.edu/uscode/text/17/401 re U.S. Code, and what's proposed in this PR appears to compatible with that - there is "Copyright". It also mentions that the year of the first publication may be sufficient. The FSF/GNU guide also mentions that "©" and "(C)" are optional.
One other alternative is to have each TR embed their own text for the rights (some already do this in addition to including schema:license <http://purl.org/NET/rdflicense/MIT1.0> but I'm thinking that's not great since it is only a template), e.g., "MIT License. Copyright © 2019–2022 W3C Solid Community Group." That text could be the value of dcterms:rights. That is however human-readable only (and not machine-readable/structured content using a vocab.) We don't include the full MIT license text as that's a bit cumbersome. Again, part of the reason why having one mit-license would be great.
IANAL either. However, I've dealt with these matters in various situations.
To be meaningful and effective, the (actually optional, but helpful for enforcement litigation, if/when needed) copyright statement MUST include one or more years of creation (upon which common-law copyright takes effect, without any requirement of declaration) and/or publication (upon which many incorrectly believe copyright takes effect), and an identifier for the creator (which has historically been a human readable identifier, such as the full name or alias of a human, or a reference to a group, but future evolution could easily include or even be reduced to a URI such as a WebID, NetID, or DID).
As for a machine-readable rendition of the Copyright Statement, I would suggest echoing (not replacing) the standard human-readable rendition, and using RDFa or a Turtle or JSON-LD data island and the Copyright Ontology.
Note that the copyright information applies to the creative work to which it is attached; it does not apply to nor care about the usage of that creative work, which is governed by the license(s) granted by the copyright holder, which here appears to be the (unversioned and hence immutable) MIT License, which is actually quite short (compare to, for instance, either version of the GPL) and should be included on the creative work to which it is being applied.
Good discussion.
We can introduce CG's WebID once it exists. Possibly a new group under https://solidproject.solidcommunity.net/Solid%20Project%20Contacts/Group/ or somewhere else (more?) persistent. At the moment, we have this URL: https://www.w3.org/groups/cg/solid - it is not a WebID (or can't be used as one AFAIK) but it may be sufficient for the copyright line next to the group name. What do you think?
The PR'd document is already in HTML+RDFa. Using dcterms for starters.
$ curl "http://rdf.greggkellogg.net/distiller?command=serialize&format=rdfa&output_format=turtle&url=https:%2F%2Fraw.githubusercontent.com%2Fsolid%2Fspecification%2Fadad4ea576f795356538c503d85afb109daf307b%2Fmit-license.html&raw"
I've seen licenses described in ODRL so thought that may be something we can easily introduce. The Copyright Ontology is interesting (and somewhat complicated?) - Is that taken up in standards building circles?
Are there any (legal) issues with respect to the mutability of the attached license document? Yes, the license will remain the same (hence, the reserving the name mit-license). However, the copyright years will be updated in the future. Although unlikely, the rights holder could change - but as I understand it, new holders starting at different years could be introduces in separate lines.
When attaching this license document to new works, it seems appropriate to have a copyright year. For works that haven't changed, the newly added years may not be useful but doesn't take away anything either.
We can introduce CG's WebID once it exists. Possibly a new group under https://solidproject.solidcommunity.net/Solid%20Project%20Contacts/Group/ or somewhere else (more?) persistent. At the moment, we have this URL: https://www.w3.org/groups/cg/solid - it is not a WebID (or can't be used as one AFAIK) but it may be sufficient for the copyright line next to the group name. What do you think?
For these purposes, I think that either URI would work. Both are more persistent and resolvable than the plain-english name (which offers only web search engines as paths to resolution). Membership changes over time, and the list that applies to 2019 doesn't apply to 2022, but the CG agreement serves to render the specific membership list immaterial.
The PR'd document is already in HTML+RDFa. Using dcterms for starters.
👍
I've seen licenses described in ODRL so thought that may be something we can easily introduce. The Copyright Ontology is interesting (and somewhat complicated?) - Is that taken up in standards building circles?
I discovered the Copyright Ontology just before making my previous comment. ODRL appears to offer related but not quite replacement terms. I don't feel strongly (today; I reserve the right to develop such feelings) about which terms or vocab to use.
Are there any (legal) issues with respect to the mutability of the attached license document? Yes, the license will remain the same (hence, the reserving the name
mit-license). However, the copyright years will be updated in the future. Although unlikely, the rights holder could change - but as I understand it, new holders starting at different years could be introduces in separate lines.
Incorporating a license by reference, where dereferencing it may bring different license terms over time, may lead to confusion and drawn out litigation, if/when such is needed. Incorporating the full license terms (with or without reference to its origin/web-page) removes most potential confusion and makes litigation a relatively simpler matter.
Copyright holders may indeed change over time, especially for such derivative works as are permitted by the license, and yes, this can generally be handled as simply as by adding a new line to the declaration.
When attaching this license document to new works, it seems appropriate to have a copyright year. For works that haven't changed, the newly added years may not be useful but doesn't take away anything either.
It is officially inappropriate to add new years to copyright declarations on unchanged works, but this does not stop anyone from doing so (and certainly, many do). I don't know of any actual problems this may cause, if the Solid Community Group does so.
IANAL either. I think my main concern is along the same lines as what's been raised by @TallTed - in that I wonder about the effectiveness of a blanket license by reference - vs. providing a template that is explicitly copied and included for a given work. Assuming the former is OK, I'm totally fine with the content of this PR, but I'm not sure I'm qualified to say that the latter isn't the right option.
Note that "license" is distinct from "copyright", and the latter was most of the focus in this thread, though it was opened about licensure.
The holder(s) of copyright are the one(s) who are able to license a thing for use by others, including changing the terms of such licensure.
@csarven, I might have been too eager here; my apologies. The intention of the PR, and the questions you raised in it, are indeed still valid. Only the concrete changes are outdated by the charter.
Can we transfer them to an issue, aimed at all spec repos? We could also reopen this PR, but then it needs a big update re the charter, of course.
OK, reopening to keep it in our radar. Might as well update here as we still have the context.