Make LICENSE more apparent#477
Conversation
gregsdennis
left a comment
gregsdennis
left a comment
There was a problem hiding this comment.
I'm pretty sure the existing license is intentional.
|
You think so? 'All rights reserved'? Could it be possible to modify it so that GitHub repository page can also show it as something it recognizes? |
|
Ideally, the shape of the repository would be as described in RFC 8875; see https://www.rfc-editor.org/rfc/rfc8875.html#section-3.1 for one of the places this is discussed there. |
This is a standard phrase in a copyright statement that is needed to make the copyright statement valid in certain jurisdictions. Copyright is generally hard, because it needs to work in all jurisdictions, so I'd rather stick with what is normal here. |
| extracted from this document must include Simplified BSD License text | ||
| as described in Section 4.e of the Trust Legal Provisions and are | ||
| provided without warranty as described in the Simplified BSD License. | ||
| BSD 2-Clause License |
There was a problem hiding this comment.
The BSD license is only applicable to code components and not to specs. See https://trustee.ietf.org/
license-info.
There was a problem hiding this comment.
I was hoping someone would notice this. Does it become too complicated if we restructure the code components to their own sub-directory and specs to their own so that we could get two LICENSE files pointing which materials have their corresponding licenses: https://softwareengineering.stackexchange.com/questions/304874/declaring-multiple-licences-in-a-github-project#answer-304895 ?
There was a problem hiding this comment.
Does it become too complicated
I would probably answer this affirmatively.
Right now, we don't identify anything in the draft explicitly as a "code component".
The directory scripts could of course have its own license file -- none of this goes into the document, so it is useful to be explicit about the license (ignoring whether the "threshold of originality" is even reached).
The other potential code component is the ABNF, for which the scripts directory provides ways to extract it from the document, but the repo doesn't actually store the (computed) result. So there is no directory a license could be attached to.
There was a problem hiding this comment.
Good reasoning. However isn't the license currently too vague and interpretable?
|
Surely there must be a consensus-based approach that has been applied to
recent RFC-backing repos, of which there are many? Do we need to invent
anything here?
…On Jun 9, 2023 at 4:35:22 AM, Akira Taguchi ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In LICENSE
<#477 (comment)>
:
> @@ -1,11 +1,25 @@
-Copyright (c) 2020 IETF Trust and the persons identified as the
-document authors. All rights reserved.
-
-This document is subject to BCP 78 and the IETF Trust's Legal
-Provisions Relating to IETF Documents (https://trustee.ietf.org/
-license-info) in effect on the date of publication of this document.
-Please review these documents carefully, as they describe your rights
-and restrictions with respect to this document. Code Components
-extracted from this document must include Simplified BSD License text
-as described in Section 4.e of the Trust Legal Provisions and are
-provided without warranty as described in the Simplified BSD License.
+BSD 2-Clause License
Good reasoning. However isn't the license currently too vague and
interpretable?
—
Reply to this email directly, view it on GitHub
<#477 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAEJE6ANMZHX4UH44WSC6LXKMC7VANCNFSM6AAAAAAZAIROSE>
.
You are receiving this because you were mentioned.Message ID:
<ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/477/review/1471775620@
github.com>
|
|
On 9. Jun 2023, at 17:31, Tim Bray ***@***.***> wrote:
Surely there must be a consensus-based approach that has been applied to
recent RFC-backing repos, of which there are many? Do we need to invent
anything here?
I don’t think we want to doctor with the licenses that the TLP provides. We just should make sure that these are clearly announced with the repo. I think we set up the repo slightly before RFC 8875 was available to provide the guidance for that, so we should re-check.
We could also make sure that elements of the repo that are not directly becoming part of the document governed by the TLP (i.e., scripts directory) are also clearly licensed.
Grüße, Carsten
|
6 participants
Remove LICENSE.md as well due to it only referring to CONTRIBUTION. Do comment here if the license used here is wrong. I merely inferred it from the previous license text.