Topics

League of Extraordinary FoundryVTT Developers•3y ago

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

zeel•3y ago

👋 https://discord.com/channels/732325252788387980/755620260895391754/822538365030760549

KaKaRoTo 🍉•3y 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"

zeel•3y ago

I think one original fear was "OMG this data structure is going to be super over-complicated"

KaKaRoTo 🍉•3y 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

zeel•3y ago

@corporat

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

corporat•3y 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

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

KaKaRoTo 🍉•3y ago

does reuse not have scripts to generate a license file/summary out of all that ? I thought that was the point 🤔

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

flamewave000•3y 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

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

KaKaRoTo 🍉•3y 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? 😛 )

corporat•3y ago

the problem with declared metadata: it's not maintained. It's always garbage

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

flamewave000•3y 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

KaKaRoTo 🍉•3y ago

if devs were lawyers.... they might care

corporat•3y 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 😶

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

corporat•3y ago

I believe "license" is core (though it's unevenly documented) it accepts a link. I don't think anything consumes it yet?

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

corporat•3y 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

BadIdeasBureau•3y 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)

corporat•3y 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"

BadIdeasBureau•3y 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).

corporat•3y 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

Calego•3y ago

Oh really? I had no idea this existed

corporat•3y ago

I was also recently told of this 😐

Calego•3y ago

I reckon that's new, it is on the docs though

Calego•3y ago

No description

Calego•3y ago

4 months 'new'

flamewave000•3y ago

The license field has been there since I started developing mods last summer

Calego•3y ago

mindblown

flamewave000•3y ago

It also is expected to be either a relative path to a file within the package, or a url

Calego•3y 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"
}

flamewave000•3y 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

Calego•3y 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?

flamewave000•3y 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

Calego•3y 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"
  }
]

flamewave000•3y ago

Ok, I honestly think they're kind of equal either way. Subjectively, the second option sounds better to my ear lol

BadIdeasBureau•3y 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.

flamewave000•3y ago

This looks good 👍🏼

BadIdeasBureau•3y 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).

corporat•3y 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"

flamewave000•3y ago

I would add a verbose string example as well though. "All Items of Type" or something

corporat•3y ago

maybe just mine. I'm keying off of a conversation about copyright notices and declaring/disclaiming authorship of various components

flamewave000•3y 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

corporat•3y 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

flamewave000•3y ago

Right, and that's where paths and verbose strings come in handy

BadIdeasBureau•3y 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.

corporat•3y 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

BadIdeasBureau•3y 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).

corporat•3y ago

there are lots of problems needing solving, proper attribution of all persons is my foremost concern in terms of Foundry modules

flamewave000•3y 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"
  }
]

Calego•3y 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

corporat•3y ago

we already got pushback from JDW for anything other than what exists already

zeel•3y 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.

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

zeel•3y ago

What problem are we trying to solve that the manifest can solve?

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

zeel•3y 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.

corporat•3y ago

but why would a Foundry Hub or Forge user want that?

flamewave000•3y 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

zeel•3y 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.

flamewave000•3y 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

zeel•3y ago

That's what the link does.

Daniel Thorp•3y ago

Is there any reason why you can't put an arbitrary string in the current "license" field?

zeel•3y ago

It's intended to be a URL AFAIK

flamewave000•3y ago

It's intended to be either a URL or a relative path to a license file within the package

Daniel Thorp•3y 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.

zeel•3y ago

The idea is to allow users to locate this without hunting. Just as there is a field for "bugs" And for the readme

flamewave000•3y 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

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

flamewave000•3y 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>.

corporat•3y 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

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

corporat•3y ago

yup your liability is zero lol

Unknown User•3y ago

Message Not Public

Sign In & Join Server To View

BadIdeasBureau•3y 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?

corporat•3y ago

https://discord.com/channels/732325252788387980/874463376162574437/874466002325356574 🙂

BadIdeasBureau•3y 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)

flamewave000•3y 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

BadIdeasBureau•3y 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.

League of Extraordinary FoundryVTT Developers Join

4KMembers

View on Discord

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 datab Login Via POSTlook at your network tab when you click the join button, you'll see the POST with the data it sends,Actor Updatingquestion for ya'll, simple update issue i'm seeing that i'm sure someone understands. with my conven 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`Colour stuffhere let's make a thread Random Numbersyeah that was basically exactly what I would suggest. Here's rough code, untested. ```js const x = .Dors projectTo be clear, I'm very open to the feedback that I'm doing something stupid here, hah. This is my fir AC MigrationsAs of 1.4.1 there are two migration scripts for AC related changes: 1. The standard Migration Scrip