LOE
League of Extraordinary FoundryVTT Developerszeel

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!
Z
zeel•1,011d ago
K
KaKaRoTo•1,011d ago
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"
Z
zeel•1,011d ago
I think one original fear was "OMG this data structure is going to be super over-complicated"
K
KaKaRoTo•1,011d ago
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
Z
zeel•1,011d ago
@corporat
UU
Unknown User•1,011d ago
C
corporat•1,011d ago
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
UU
Unknown User•1,011d ago
K
KaKaRoTo•1,011d ago
does reuse not have scripts to generate a license file/summary out of all that ? I thought that was the point 🤔
UU
Unknown User•1,011d ago
F
flamewave000•1,011d ago
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
UU
Unknown User•1,011d ago
K
KaKaRoTo•1,011d ago
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? 😛 )
C
corporat•1,011d ago
the problem with declared metadata: it's not maintained. It's always garbage
UU
Unknown User•1,011d ago
F
flamewave000•1,011d ago
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
K
KaKaRoTo•1,011d ago
if devs were lawyers.... they might care
C
corporat•1,010d ago
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 😶
UU
Unknown User•1,010d ago
C
corporat•1,010d ago
I believe "license" is core (though it's unevenly documented) it accepts a link. I don't think anything consumes it yet?
UU
Unknown User•1,010d ago
C
corporat•1,010d ago
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
B
BadIdeasBureau•1,010d ago
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)
C
corporat•1,010d ago
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"
B
BadIdeasBureau•1,010d ago
"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).
C
corporat•1,010d ago
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
C
Calego•1,010d ago
Oh really? I had no idea this existed
C
corporat•1,010d ago
I was also recently told of this 😐
C
Calego•1,010d ago
I reckon that's new, it is on the docs though
C
Calego•1,010d ago
No description
C
Calego•1,010d ago
4 months 'new'
F
flamewave000•1,010d ago
The license field has been there since I started developing mods last summer
C
Calego•1,010d ago
mindblown
F
flamewave000•1,010d ago
It also is expected to be either a relative path to a file within the package, or a url
C
Calego•1,010d ago
So what we're considering then is a new field: licenses This field would be an array of objects. Spitballing: 
"licenses": [
  {
    "directory": "some/directory/or/file",
    "license": "url/to/license/file"
  }
]
"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"
}
{
    "directory": "some/directory/or/file",
    "license": "url/to/license/file",
    "spdx": "MIT"
}
F
flamewave000•1,010d ago
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
C
Calego•1,010d ago
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?
F
flamewave000•1,010d ago
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
C
Calego•1,010d ago
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 
"licenses": [
  {
    "license": "url/to/license/file",
    "targets": ["some/directory/or/file", "some/other/directory/or/file],
    "spdx": "MIT"
  }
]
"licenses": [
  {
    "license": "url/to/license/file",
    "targets": ["some/directory/or/file", "some/other/directory/or/file],
    "spdx": "MIT"
  }
]
F
flamewave000•1,010d ago
Ok, I honestly think they're kind of equal either way. Subjectively, the second option sounds better to my ear lol
B
BadIdeasBureau•1,010d ago
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.
F
flamewave000•1,010d ago
This looks good 👍🏼
B
BadIdeasBureau•1,010d ago
(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).
C
corporat•1,010d ago
looking back on my original proposal, my main concern here (maybe BIB's too) is for the authors to also have "targets"/"paths"/"facets"
F
flamewave000•1,010d ago
I would add a verbose string example as well though. "All Items of Type" or something
C
corporat•1,010d ago
maybe just mine. I'm keying off of a conversation about copyright notices and declaring/disclaiming authorship of various components
F
flamewave000•1,010d ago
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
C
corporat•1,010d ago
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
F
flamewave000•1,010d ago
Right, and that's where paths and verbose strings come in handy
B
BadIdeasBureau•1,010d ago
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.
C
corporat•1,010d ago
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"]
        }
    ]
//...
}
{
//....
    "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"]
        }
    ]
//...
}
{
//....
    "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
B
BadIdeasBureau•1,010d ago
... 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).
C
corporat•1,010d ago
there are lots of problems needing solving, proper attribution of all persons is my foremost concern in terms of Foundry modules
F
flamewave000•1,010d ago
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 
"licenses": [
  {
    "facets" : ["core"],
    "license": "url/to/license/file",
    "targets": ["some/directory/or/file", "some/other/directory/or/file"],
    "spdx": "MIT"
  }
]
"licenses": [
  {
    "facets" : ["core"],
    "license": "url/to/license/file",
    "targets": ["some/directory/or/file", "some/other/directory/or/file"],
    "spdx": "MIT"
  }
]
C
Calego•1,010d ago
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
C
corporat•1,010d ago
we already got pushback from JDW for anything other than what exists already
Z
zeel•1,010d ago
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: 
"licenseLabel": "MIT (code), CC-BY-4.0 (Icons)"
"licenseLabel": "MIT (code), CC-BY-4.0 (Icons)"
"licenseLabel": "GPLv3 (all your base)"
"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.
UU
Unknown User•1,010d ago
Z
zeel•1,010d ago
What problem are we trying to solve that the manifest can solve?
UU
Unknown User•1,010d ago
Z
zeel•1,010d ago
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.
C
corporat•1,010d ago
but why would a Foundry Hub or Forge user want that?
F
flamewave000•1,010d ago
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
Z
zeel•1,010d ago
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.
F
flamewave000•1,010d ago
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
Z
zeel•1,010d ago
That's what the link does.
DT
Daniel Thorp•1,010d ago
Is there any reason why you can't put an arbitrary string in the current "license" field?
Z
zeel•1,010d ago
It's intended to be a URL AFAIK
F
flamewave000•1,010d ago
It's intended to be either a URL or a relative path to a license file within the package
DT
Daniel Thorp•1,010d ago
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.
Z
zeel•1,010d ago
The idea is to allow users to locate this without hunting. Just as there is a field for "bugs" And for the readme
F
flamewave000•1,010d ago
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
UU
Unknown User•1,010d ago
F
flamewave000•1,010d ago
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>.
C
corporat•1,010d ago
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
UU
Unknown User•1,010d ago
C
corporat•1,010d ago
yup your liability is zero lol
UU
Unknown User•1,010d ago
B
BadIdeasBureau•1,010d ago
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?
C
corporat•1,010d ago
B
BadIdeasBureau•1,010d ago
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)
F
flamewave000•1,010d ago
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
B
BadIdeasBureau•1,010d ago
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.
Want results from more Discord servers?
Add your server
More Posts
Temporary DocumentsIs there a built-in way to create temporary entities? Like entities wich are not stored in the databLogin Via POSTlook at your network tab when you click the join button, you'll see the POST with the data it sends,Crit confirm change targetLooks like Fury merged the thing already, so whatever you do would no longer be relevant for the MR.Actor Sheet ChangesActor Sheet changes: -**NPC, Character**: `systems/dnd5e/templates/actors/parts/actor-warnings.html`Dors projectTo be clear, I'm very open to the feedback that I'm doing something stupid here, hah. This is my firAC MigrationsAs of 1.4.1 there are two migration scripts for AC related changes: 1. The standard Migration Scrip