-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
License statement best practices #124
Comments
And as I'm reading through your list, a third best practice comes to my mind when choosing a license for new works: 3. Use SPDX identifiers to identify licenses and state "only" or "later"With the SPDX License Identifier there exists a standard for referring to licenses, such as the GPLv3, that can be easily recognized by computers. If you browse through the SPDX license list you will notice that many versioned licenses have multiple identifiers. E.g. for the GPL:
It is best practice to clearly state if only a specific version or also any later version of a license applies. More details here. While H5P users don't need to know about SPDX, they should be presented with SPDX conformant choices (and you can use it internally to refer to the user's choice). Also note that RightsStatements.org don't have SPDX license identifiers, because they aren't licenses, but only statements about the copyright status (see spdx/license-list-XML#989). The "only" vs. "later" choice is currently made not so much for CC licenses, although CC writes that it is possible. As a sidenote, the SPDX specification is part of the larger REUSE Specification, that "defines a standardized method for declaring copyright and licensing for software projects". |
The second point ("Canonical license URIs often start with http, not https") is less of an issue anymore, see cc-archive/cc.licenserdf#7 (comment), which changes the situation for the CC licenses (but not the other licenses):
|
Cross posted at h5p.org's Developers forum.
I just saw at HFP-3047 that you are collecting links to license statements. There are already some "best practices" that I want to make you aware of, two in particular that both stem from the IIIF Presentation API 3.0, specifically its
rights
definition.1. Proper URIs for works in copyright
I saw that you currently don't have a good link for content in copyright; you just link to a Wikipedia page. This is actually what RightsStatements.org is for, it provides a vocabulary to mark the copyright status of works in a machine readable way. While they have a plethora of statements, I specifically suggest the use of In Copyright:
http://rightsstatements.org/vocab/InC/1.0/
Note that they write "it is not a License, and should not be used to license your Work." In Copyright is a legal conclusion; it's not possible to choose it as license, but it is the result of not choosing a license.
For this reason I am also not sure if your differentiation between Public Domain Mark 1.0 and Public domain is meaningful, because the public domain is not a license and the Public Domain Mark is only a statement to mark works that somehow are in the public domain. Maybe drop the entry Public domain? Also, the public domain does not exist in many countries (Germany, for example), so I'd be very careful with allowing users to place their work in the public domain – it might not be possible after all. Better only allow CC0 1.0, which puts a work in the public domain where it is possible and has a fallback license for the other cases.
2. Canonical license URIs often start with
http
, nothttps
All CC licenses have a canonical URI that starts with
http://
. It is used when describing the license status of works in a machine readable way and the scheme is part of it. This can be verified when looking at the RDF index of CC licenses that contains all canonical URIs. See creativecommons/cc-legal-tools-app#361 and cc-archive/cc.licenserdf#7 for the relevant discussion at CC.This is the same for the GNU licenses, which also have the
http
scheme as part of their canonical URI, see gpl-3.0.rdf.And it's also the same for the RightsStatements.org URIs, except (a) they display their canonical URIs more prominently in the first place and (b) the use of
http
is described in more detail in the EDM Mapping Guidelines, section 4.2 + 4.3.Also, see IIIF/api#1874 if you are unsure about this, because the IIIF (Image Interoperability Framework) already had a discussion on this topic.
The text was updated successfully, but these errors were encountered: