License Property
@ghost @flamewave000 @corporat @kakaroto
But if we do want to talk Manifest+, we should do that over here.
We can even thread it!
83 Replies
This was what I responded with regards to the facets/license proposal from @corporat 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"
yeah
I thought the facets idea was solving the complexity of it to some extent
@corporat
Unknown User•4y ago
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
Unknown User•4y ago
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 🤔
Unknown User•4y ago
Message 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
Unknown User•4y ago
Message 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
Unknown User•4y ago
Message 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
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 😶
I do not have strong preferences for fhub. The way I see it, there is no big value to be found in the way it is consumed as long as the information is accessible.
The number of people interested in this information is extremely limited, therefore I don't think there's much to do on this topic. The minimum viable would be links. If it's a link to .MD files, I'll do the same as I do right now to embed it
I believe
"license" is core (though it's unevenly documented)
it accepts a link. I don't think anything consumes it yet?It is, I already implement it
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)
(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:
licenses
This field would be an array of objects.
Spitballing:
I agree simple SPDX is not sufficient, though allowing it as well might be nice to have:
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.
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"
still spitballing
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
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
I would now revise this to:
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 suggested. We can add a facets field to his proposal to cover your use case with the authors though
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
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.
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?
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
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:
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.Yeah the last part is the most important question I think. The consumers will exists only to help whatever the answer to this last question is
Eh my discord didn't scroll to the bottom, I was answering to Calego
In the case of fhub, I have no intention to code a complex system with recursivity, badges, etc if it does not fill a need
What problem are we trying to solve that the manifest can solve?
If the need is clearly identified, then I'll be happy to code whatever is necessary
This was my thinking/assumption. It might be possible with some SPDX library or whatever, but is it worth the effort? And will authors even use it?
A simple string could solve this problem because it's trivial to display.
but why would a Foundry Hub or Forge user want that?
The primary issue is when portions of a module are under different licenses. There wouldn't be any kind of recursiveness to it. Just a flat list of licenses and which files/folders/facets those licenses apply to
So unless there is some other consumer we are considering (and not, the end-user doesn't ever look at the manifest) then a super complex system hurts more than it helps.
But that's still complicating things.
It's a whole UI loop that has to be designed, maintained, etc.
And there will be only a tiny fraction of devs using it.
And an even smaller fraction of users caring.
While a link to a file that contains all the license data you want in any format you want is also provided.
Yes, but the need is that licenses have to be presented with the product. Users browsing FHub and Forge are expected to be given access to the licenses for them, and this presents a way to clearly define things when multiple licenses are in effect
That's what the link does.
Is there any reason why you can't put an arbitrary string in the current "license" field?
It's intended to be a URL AFAIK
It's intended to be either a URL or a relative path to a license file within the package
In that case, I vote to remove the Core license field completely as that would avoid this whole issue and it's something that should be in the repo rather than the manifest.
The idea is to allow users to locate this without hunting.
Just as there is a field for "bugs"
And for the readme
So Licenses have to be sent within every package, and Foundry needs to be able to present that license to the user. The only way it can know how to do that is by having a license field
I see this question the same I feel about any automation. The cost needs to be less than the value. I may be wrong (and that's why I'm open to anything), but I feel like the only people who would ever care about this are less than 50, maybe even 25. And these 50 people would certainly like to be able to have a neat UI instead of a single link, sure, but that's it
So this discussion isn't just about ease of use, but also for CYA. We discussed the legal ramifications and how the current system does not work well with multiple license packages in other areas of this thread and <#873383994144727070> and <#874445116264312842>.
the value is to the people with the highest liability writing integrations for Foundry modules, businesses, Patreon creators etc
but good luck convincing them of the risk
Yeah I know, I'm talking on the subject of fhub
yup your liability is zero lol
I already show a link to the licence file and embed it in a tab if it's a markdown file
That requires the license(s) for each module to be easily findable within the module's github/whatever. I don't think that needs to be in the manifest unless something is going to consume that data, which isn't sounding all that likely?
Yup, and I think that's sounding like a better solution than any manifest alterations, IMO. (unless there's some standard for including REUSE data in a format which would be compatible with the manifest that I'm missing from my initial skim)
There's not really a way to use REUSE in conjunction with the manifest file, it also is not something that can be utilized by third party tools (FHub, Forge, Leo) for displaying licenses
I think that latter point is looking a lot less relevant, tbh - since a) those services are only providing the license as a convenience, and b) addressing any more complexity than "all content is under this single license" in those third party providers is unlikely to happen given the above discussion.