Open ghost opened 1 year ago
I think nostr doc should have something like this: "by submitting an event to any relay, the author authorizes anyone to copy, repost, share, comment, summarize or rephrase its content inside or outside nostr (e.g. on a thirdy-party blog) for any purpose".
Free human knowledge to everyone! (atleast kind 1 and 30023 xD)
Why not using SPDX license syntax: https://spdx.github.io/spdx-spec/v2-draft/SPDX-license-expressions/
@arthurfranca, @yuhr What do you think of this idea of extending NIP 39, and inserting a meta tag: "nostr-license"?
we can have a custom metadata as "nostr-license" according to the NIP-39 - External Identities in Profiles proposal for this. the "nostr-license" metadata has a public key related to the user or the repository. This ensures certain control of the relay publicly, temporary, anonymous or privately.
{
"id": <id>,
"pubkey": <pubkey>,
...
"tags": [
["i", "nostr-license:1087295469", "npub1fakeurl2"],
["i", "nostr-license:1087295469", "pubkey"]
]
}
@raiseprogrammer I can't figure out how your idea is meant to work. Where to store a license notice in your example?
Hi yuhr.
Please, see this: UI: Add license to NostrGit
I've read a bit about NostrGit's vision:
Repos should have keys like normal nostr users. This makes it easy for a repo to have nip5, description, and a profile photo.
Now that I understand why you go for extending NIP-39 which is all about profiles rather than notes, but that is only a specific situation of NostrGit. The purpose of this issue is to achieve a consensus to have a machine-readable form of license notices attached within notes, not profiles.
I'd say you should open a new issue for that.
I think this information could be included in NIP-11. With a "copyright" or "license" field or a tags field where the relay informs the licenses through tags and SPDX license syntax. By default, people can or cannot include license information in notes or events. As well, relay servers can have information or not related to the license too.
example 1 Here we have "tags" related to the license/copyright of the note or event.
{
...
language_tags: [ 'en', 'en-419' ],
tags: [ 'sfw-only', 'bitcoin-only', 'anime' , 'mit', 'copyright', 'licensed', 'LGPL-2.1-only', 'commercial use', 'distribution modification', 'patent use', 'private use'],
posting_policy: 'https://example.com/posting-policy.html',
...
}
example 2 Here we have "tags: license/copyright" related to the license/copyright of the note or event.
{
...
language_tags: [ 'en', 'en-419' ],
tags: [ 'sfw-only', 'bitcoin-only', 'anime' ],
license/copyright: ['mit', 'LGPL-2.1-only', 'commercial use', 'distribution modification', 'patent use', 'private use'],
posting_policy: 'https://example.com/posting-policy.html',
...
}
example 3 Here we have "string: license/copyright" related to the license/copyright of the note or event. This string may or may not have SPDX syntax. Here is an example without SPDX syntax.
{
...
language_tags: [ 'en', 'en-419' ],
tags: [ 'sfw-only', 'bitcoin-only', 'anime' ],
license/copyright: 'mit',
posting_policy: 'https://example.com/posting-policy.html',
...
}
example 4 Here we have "string: license/copyright" related to the license/copyright of the note or event. This string may or may not have SPDX syntax. Here is an example with the SPDX syntax.
{
...
language_tags: [ 'en', 'en-419' ],
tags: [ 'sfw-only', 'bitcoin-only', 'anime' ],
license/copyright: 'LGPL-2.1-only ',
posting_policy: 'https://example.com/posting-policy.html',
...
}
example 5 It is very common to use arrays in nostr notes or events. Here is an example of a key and value array related to copyright/license. In this example, a note or event is made by a legal entity, a company, NGO, government or community.
{
...
language_tags: [ 'en', 'en-419' ],
tags: [ 'sfw-only', 'bitcoin-only', 'anime' ],
"license/copyright": ["Remy Sharp", "Richie Bendall"],
posting_policy: 'https://example.com/posting-policy.html',
...
}
example 6 It is very common to use arrays in nostr notes or events. Here is an example of a key and value array related to copyright/license. We can use in this special use case SPDX inside a key and value array.
{
...
language_tags: [ 'en', 'en-419' ],
tags: [ 'sfw-only', 'bitcoin-only', 'anime' ],
"license/copyright": ["LGPL-2.1-only", "https://example.com/posting-license.html"],
posting_policy: 'https://example.com/posting-policy.html',
...
}
example 7 It is very common to use arrays in nostr notes or events. Here is an example of a key and value array related to copyright/license. In this example, a note or event is made by a legal entity, a company, NGO, government or community. By default, you add the name of the license and the location where that license can be read or found.
{
...
language_tags: [ 'en', 'en-419' ],
tags: [ 'sfw-only', 'bitcoin-only', 'anime' ],
"license/copyright": ["gpl", "https://cdn.gpl.com/gpl/gpl.txt"],
posting_policy: 'https://example.com/posting-policy.html',
...
}
example 8 Here we have by default only the location or link where the license can be found.
{
...
language_tags: [ 'en', 'en-419' ],
tags: [ 'sfw-only', 'bitcoin-only', 'anime' ],
"license/copyright": "https://cdn.gpl.com/gpl/gpl.txt",
posting_policy: 'https://example.com/posting-policy.html',
...
}
example 9 A relay information structure with the license information could look something like this:
{
"name": <string identifying relay>,
"description": <string with detailed information>,
"pubkey": <administrative contact pubkey>,
"contact": <administrative alternate contact>,
"supported_nips": <a list of NIP numbers supported by the relay>,
"software": <string identifying relay software URL>,
"version": <string version identifier>,
"license/copyright": <string SPDX license syntax identifier> or <a list of license supported by the relay> or <string with detailed information>,
}
example 10: Nip11+NIP 65+GitHubChooseLicense v1 A special case would be to inform what are the permissions that the user can do based on: github/choosealicense
{
"kind": 10002,
"tags": [
["l", "wss://alicerelay-license.example.com"],
["l", "wss://brando-relay-license.com"],
["l", "wss://expensive-relay-license.example2.com", "commercial use"],
["l", "wss://nostr-relay-license.example.com", "distribution"],
["l", "wss://nostr-relay-license.example.com", "modification"],
...
],
"content": "",
...other fields
example 11: Nip11+NIP 65+GitHubChooseLicense v2 A special case would be to inform what are the permissions that the user can do based on: github/choosealicense
{
...
language_tags: [ 'en', 'en-419' ],
license_permissions/license/copyright: [ 'commercial use', 'distribution modification', 'patent use', 'private use'],
posting_policy: 'https://example.com/posting-policy.html',
...
}
example 12: Nip11+NIP 65+GitHubChooseLicense v2 Another interesting use case is using public keys for some kind of license. In theory anyone could have a public key for any license, this makes nostr content indexing easier. As we can see in this example, we have an array of public keys that identify parts of a license. The identification of these public keys as permission with the license type could be done publicly. For example, there may be public listings that spell out the meaning of these license keys.
{
...
language_tags: [ 'en', 'en-419' ],
license_permissions/license/copyright: ['AIBVPNQcbwM5PU', 'AskjdsdVvmi', 'Askjdskkjsdjksd', 'skkjsdjk'],
posting_policy: 'https://example.com/posting-policy.html',
...
}
AIBVPNQcbwM5PU: commercial use
, AskjdsdVvmi: distribution modification
, Askjdskkjsdjksd: patent use
, skkjsdjk: private use
example 13: NIP 58+Nip11 Sometimes the user may have a badge related link with the license. We may consider a "license" tag in specification 65 in the future or not.
{
"pubkey": "alice",
"kind": 30009,
"tags": [
["d", "bravery"],
["name", "Medal of Bravery"],
["license", "GPL"],
["description", "Awarded to users demonstrating bravery"],
["image", "https://nostr.academy/awards/bravery.png", "1024x1024"],
["thumb", "https://nostr.academy/awards/bravery_256x256.png", "256x256"],
],
...
}
Intro: When publishing an event you can add a content-licensed to help clients organize your note, this allows for greater transparency in which content I should share between relays or not. This proposal is similar to proposal: NIP IDEA: New note tag "channel" (or label), the difference is that the idea of content-licensed is metadata for note.
There are other interesting proposals that were inspired by: NIP-58 - Badges, NIP-65 - Relay List Metadata. This proposal is an initial draft.
Serious problem:
The solution of these general problems:
workflow: Clients MAY ignore content-licensed, organize notes into "content-licensed" by tags, use naive byes to help train using content-licensed, block content-licensed, and "disagree" with a content-licensed(drag/move a note to another channel). Clients SHOULD have a mode or tab or switch where content-licensed are ignored.
If a user disagrees with a content-licensed, clients MAY remember the pubkey origin and ignore content-licensed from that user in the future.
use case: There are 5 ways to have licensed content. Below I talk about these 5 ways and the use case.
content-licensed as metadata 1:
content-licensed as metadata 2:
content-licensed as metadata 3:
content-licensed as array 1:
content-licensed as array 2: Here we have a public key reference to the content:
["gpl", "3da4984c423c255f03c7904b1ae77f206"]
,["mit", "bf23769e9031fa48e74553dde5526bce"]
Syntax:
"content-licensed"
:"gpl"
or"mit"
or"copyright"
or"unlicensed"
... or"content-licensed": [..., ["gpl", "mit", "copyright"]]