LOEFD
Join ServerLeague of Extraordinary FoundryVTT Developers
manifest-plus
License Property
@ghost @flamewave000 @corporat he/him @KaKaRoTo
But if we do want to talk Manifest+, we should do that over here.
We can even thread it!
But if we do want to talk Manifest+, we should do that over here.
We can even thread it!
👋
This was what I responded with regards to the facets/license proposal from @corporat he/him https://discord.com/channels/732325252788387980/755620260895391754/824818361824968755
I remember one thing being discussed which was "is this supposed to indicate the license of the content, or under which license you are using it"
I think one original fear was "OMG this data structure is going to be super over-complicated"
i.e: "I wrote this" vs "I have authorization from the content creator to use it in commercial products"
vs "MIT license" vs "Commercial license X"
vs "MIT license" vs "Commercial license X"
yeah
I thought the facets idea was solving the complexity of it to some extent
@corporat he/him
Message Not Public
Sign In & Join Server To View
I apparently suggested this in March, but now that I'm aware of existing standards like REUSE https://reuse.software/, I think we can suggest using REUSE instead
Message Not Public
Sign In & Join Server To View
does reuse not have scripts to generate a license file/summary out of all that ?
I thought that was the point 🤔
2 Messages Not Public
Sign In & Join Server To View
Yeah, I'm just looking at it now. It's definitely a nice system, but not really conducive to being used on services like FHub. It also appears to require quite a lot of effort from the dev to setup properly
3 Messages Not Public
Sign In & Join Server To View
oh, I like it, but I fully expect 95% of devs to ignore it
we still get a ton of module devs that don't include a license at all, and don't understand the very concept of it
(I mean, who does anyway? 😛 )
the problem with declared metadata: it's not maintained. It's always garbage
2 Messages Not Public
Sign In & Join Server To View
yeah not really
honestly, before today's discussions, I never really thought about it much myself since I rarely ever make publicly available software. My professional side rarely uses open source anything, we make most everything in-house
if devs were lawyers.... they might care
ON TOPIC: What would a Manifest Plus license property look like/contain? How would a manifest+ license property be consumed by Forge and FoundryHub (cc @JDW)?
OFF TOPIC: Any discussion not related to Manifest Plus
OFF TOPIC: Any discussion not related to Manifest Plus
Just to keep this orderly, I'm going to pick out some comments from here and put them in #874445116264312842 (ping to get added to that)
Edit: I think I was the only off-topic poster 😶
Edit: I think I was the only off-topic poster 😶
Message Not Public
Sign In & Join Server To View
I believe
"license" is core (though it's unevenly documented)it accepts a link. I don't think anything consumes it yet?
Message Not Public
Sign In & Join Server To View
my original hope was for you to be able to mark packages as containing OGL or Creative Commons content, for those who care
FHub doesn't need to care about code licenses though
A license property which is "pick a license name from the list" only works for licenses with a canonical version (i.e. GPL, but not MIT). I would suggest that an M+ license property have at least the ability to point to a file (or files) in the distributed module and/or on the module repo, rather than just relying on name. (as the core "license" property does, with a link)
So my preference would be the current license property, but as an object that can specify different licenses for different parts.
(REUSE and SPDX are partial solutions to this, but not complete - e.g. SPDX indicates optional and replaceable parts of various licenses, but you can change the meaning significantly with those replacements and still be within spec)
So my preference would be the current license property, but as an object that can specify different licenses for different parts.
(REUSE and SPDX are partial solutions to this, but not complete - e.g. SPDX indicates optional and replaceable parts of various licenses, but you can change the meaning significantly with those replacements and still be within spec)
(also documentation to make clear that it's "what license is the end user granted for this" rather than "what license is the developer using it under")
There's at least one! (though I barely care and don't have to do much of this in my day job and have others in the firm I can throw the problem at)
my own feelings about this come from a similar place. I don't want people to use an SPDX tag declaratively, as has happened so many times, so as to say "it's MIT licensed because I wrote MIT in the text box"
"point to a file in the zip" is less useful for external consumers, now that I think about it - but will make people bundle their licensing with their distribution, which is probably a plus (and required for a bunch of things).
I don't agree with your points about SPDX text replacements, but moreso because I trust the RedHat lawyers who volunteer their professional expertise to SPDX. Edit: whoops offtopic
Oh really? I had no idea this existed
I was also recently told of this 😐
I reckon that's new, it is on the docs though
4 months 'new'
The license field has been there since I started developing mods last summer
It also is expected to be either a relative path to a file within the package, or a url
So what we're considering then is a new field:
This field would be an array of objects.
Spitballing:
licensesThis field would be an array of objects.
Spitballing:
"licenses": [
{
"directory": "some/directory/or/file",
"license": "url/to/license/file"
}
]I agree simple SPDX is not sufficient, though allowing it as well might be nice to have:
{
"directory": "some/directory/or/file",
"license": "url/to/license/file",
"spdx": "MIT"
}Is the directory meant to be the target of the license? If so it should also accept an array. I also would maybe call it target instead of directory
That way it can be a file/folder or verbose statement
My mental model has "directory"/"target" as the first class citizen, with a license attached to it.
So multiple directories would require multiple entries in the array.
So multiple directories would require multiple entries in the array.
That's probably inverted from ideal though, thinking about it
Instead, first class should be the license, then directories/files it applies to are attached to that?
What exactly do you mean by first class? Just the ordering of the fields? If they're both in the same object, their basically equal
first class from a conceptual standpoint
"I have a list of directories and the licenses those apply to"
vs
"I have a list of licenses and they apply to directories"
vs
"I have a list of licenses and they apply to directories"
still spitballing
"licenses": [
{
"license": "url/to/license/file",
"targets": ["some/directory/or/file", "some/other/directory/or/file],
"spdx": "MIT"
}
]Ok, I honestly think they're kind of equal either way.
Subjectively, the second option sounds better to my ear lol
Yes, I would expect to say "here is all the files/directories licensed under MIT", and I think that's going to get less messy in edge cases.
This looks good 👍🏼
(plus that then gives a canonical list of things referenced under each license, which might be possible to refer to within each license as appropriate, if it has replaceable text for the covered stuff).
looking back on my original proposal, my main concern here (maybe BIB's too) is for the authors to also have "targets"/"paths"/"facets"
I would add a verbose string example as well though.
"All Items of Type" or somethingmaybe just mine. I'm keying off of a conversation about copyright notices and declaring/disclaiming authorship of various components
So target's can just be a list of paths/urls/verbose strings, there could also be an optional field for facets since that's a thing
Edit: mobile typing hard
Edit: mobile typing hard
like, the whole point of multiple licenses is that you don't own the art you used but there's a free license to use it
someone's going to see Creative Commons icons in your module and take them from there
it's going to happen
so now we have to make sure they attribute the actual author, not you
how do we introduce a system that accounts for all the ways people will reuse the code, or the art, etc. because that's the point of these licenses in the first place
Right, and that's where paths and verbose strings come in handy
Possibly an "author" field within each license object? Maybe optional with the assumption being that the main module author is the author of each file unless specified.
let me copy my original proposal to the thread
{
//....
"licenses": {
"core": "GPL-3.0",
"docs": "CC-BY-4.0",
"compendium": "OGL-1.0a"
},
//...
"authors" : [
{
"name" : "John Doe",
//....
"facets" : ["core", "docs"]
},
{
"name" : "Wizards of the Coast",
//...
"facets" : ["compendium"]
}
]
//...
}I would now revise this to:
{
//....
"licenses": {
"core": "/path/to/file/LICENSE",
"docs": "https://creativecommons.org/licenses/by/3.0/",
"compendium": "/path/to/file/OGL.txt"
},
//...
"authors" : [
{
"name" : "John Doe",
//....
"facets" : ["core", "docs"]
},
{
"name" : "Wizards of the Coast",
//...
"facets" : ["compendium"]
}
]
//...
}now elsewhere in the manifest, core manifest properties, we might find a
"facets" sub-property attached to scripts or something... looking at that attribution of WoTC as the authors of the compendium, I'm actually kinda skeptical that such an attribution exercise can work in this kind of standardised and machine readable form. The compendium is a combination of works of Foundry (for the base software structure), WotC (for the text content), and potentially the compendium creator (where there are implementation decisions which rise to the level of being creative, eg embedded macros in DAE SRD).
there are lots of problems needing solving, proper attribution of all persons is my foremost concern in terms of Foundry modules
I don't like making facets the primary field in there. It makes more sense the way @Calego (ElfFriend) suggested. We can add a facets field to his proposal to cover your use case with the authors though
"licenses": [
{
"facets" : ["core"],
"license": "url/to/license/file",
"targets": ["some/directory/or/file", "some/other/directory/or/file"],
"spdx": "MIT"
}
]My thinking is that ultimately this needs to point at something more official. It can't be a substitute to actually properly noting your license in-repo/files
The URL/path to a file is the ultimate
The URL/path to a file is the ultimate
Authors can be noted more accurately there.
I can't see (nor would I want) any consumer of this field doing some sort of reverse engineering to build a table of licenses or whatever.
I can't see (nor would I want) any consumer of this field doing some sort of reverse engineering to build a table of licenses or whatever.
This would be useful as a "licenses: MIT, CC, +1 more" label on the listing, which links to the appropriate license file
Which, if I'm honest, doesn't really make this feel very useful.
We need to answer these questions:
What will consume this manifest property and how?
What problem are we trying to solve that the manifest can solve?
We need to answer these questions:
What will consume this manifest property and how?
What problem are we trying to solve that the manifest can solve?
The problem of a codebase that includes icons under a different license isn't something I see a manifest as being a solution to
we already got pushback from JDW
for anything other than what exists already
FHub, The Forge, and to a lesser extent Leo are the only proper M+ consumers IIRC.
I can tell you that Leo has precious little space for displaying metadata, so anything beyond "MIT" or "GPLv3" is not likely to be shown visually.
If
Etc.
license is a valid manifest field already, the only think I really feel is missing is some sort of "licenseLabel" string so that consumers don't need to do any parsing to display some sort of label. If it's just a string, the author can say anything they want:"licenseLabel": "MIT (code), CC-BY-4.0 (Icons)""licenseLabel": "GPLv3 (all your base)"Etc.
This would be useful to consumers, but not overly complicated. Yes, it means the formatting can be all over the place.
But it allows someone to "cover" their bases however they feel is nessesary.
2 Messages Not Public
Sign In & Join Server To View