Campaign and token licensing

[VagruariesOfFate]

Is your feature request related to a problem? Please describe. When I use shared assets and attempt to respect the license and attribution requests of the contributors, I find it frustrating that there is no convenient and/or integrated way to include that information.

Describe the solution you'd like I would like to see an option for one or more licenses to be attached directly to a campaign file with the option to display license statements on campaign load. Additionally, the Basic Campaign Properties for tokens should include default fields for direct token licensing.

Describe alternatives you've considered A basic token license attachment field has been created by Full Bleed and Tal Maru. Melek has discussed an onCampaignLoad license lib but there has been no further discussion. Both approaches would need to be adopted by individual framework developers as opposed to being core options.

Additional context License concerns are a key factor in professional development of content for MT.

[Azhrei]

Additional context License concerns are a key factor in professional development of content for MT.

Then I suppose we need to know — what do the license holders want to see in terms of software support? While waiting for an answer, here are some thoughts to get the ball rolling...

Describe the solution you'd like I would like to see an option for one or more licenses to be attached directly to a campaign file with the option to display license statements on campaign load. Additionally, the Basic Campaign Properties for tokens should include default fields for direct token licensing.

It should be easy enough to attach one or more text files to the campaign and list them in the Campaign Properties. Each one could have a checkbox to determine whether it should be displayed at startup and it would default to being turned on. (It might be nice if there was a visible reference count, so a GM could quickly tell how many images use which license without needing a macro.) If any checkboxes are on when the campaign is loaded, a dialog is displayed which contains the list with Next and Prev buttons. (Similar to how many applications do their "tip of the day" dialogs at launch.)

(Maybe the license info should be viewable by players as well? In which case, the campaign properties are the wrong place to display the info since players don't have access.)

The license field should be a read-only property that is assigned when the image is loaded, and macro functions should be able to read it but not change it. It would be cool to see Devin's name/license info come up in the stat sheet, although it should be something the GM can disable. (Maybe there should be a separate getLicense() function that takes a token ID and a boolean that determines whether the return value is just the license name or the entire text? This would let a macro perform license auditing, which might be useful for pop up games or for Cons.)

The getInfo() macro should have an option to obtain a list of licenses and which images use which license. Perhaps something like getInfo("licenses"). (A separate parameter because it's likely to be a long list.)

When images are saved as .rptok files, the text of the license will need to be saved with it so that it's still there when it's later imported. A hash of the license text can be used to determine if two images use the same one. Similar requirements exist when exporting/importing maps that contain licensed images.

This still leaves how a license is attached to an image in the first place. Is there a URL to the license embedded in the comment field of an image? If not, how does MT know which license to apply to which image? Is there already an industry standard that MT should use?

[VagruariesOfFate]

Then I suppose we need to know — what do the license holders want to see in terms of software support? While waiting for an answer, here are some thoughts to get the ball rolling...

The only concern was being able to attach a license. Most are publishing under OGL's so it's imperative for them to be able to include and provide licensing for assets in some way. There are always concerns about supporting more VTTs, but at least some have been open to having materials prepared by MT users on a professional basis. Very few had any interest at all in any kind of DRM and those who did were not concerned about anything more than data obscurity and some kind of validation on initial asset acquisition.

[VagruariesOfFate]

This still leaves how a license is attached to an image in the first place. Is there a URL to the license embedded in the comment field of an image? If not, how does MT know which license to apply to which image? Is there already an industry standard that MT should use?

This is the OGL statement which covers 5E and other SRDs:

Copy of this License: You MUST include a copy of this License with every copy of the Open Game Content You Distribute.

From reading interpretations on this, image files per se are not the issue for license attachment because they are not "the distribution". As long as the information is included in the .rptok file and the .cmpgn file and is easily accessible, then most use cases are covered.

For images, would it make sense to acquire the license from a license.txt in the resource library and/or have a "campaign default" license which would be attached to anything without a specific license?

I think the far trickier consideration is code attribution for the many contributors within the community. When you consider someone using Melek's 5E framework with Merudo's spells, the BOT and doors and other addons, the list of code attributions and/or share licensing could be quite complex as it would have to include SRD/OGL statements as well as those of the actual code creators.

[Azhrei]

TL;DR version: art work license tracking is probably easy; individual macros probably need licensing as well; and SRD data can be covered with a single disclaimer about OGL works. However, IANAL nor do I play one on tv.

For images, would it make sense to acquire the license from a license.txt in the resource library and/or have a "campaign default" license which would be attached to anything without a specific license?

So there is not a generally understood technique within the industry? Creators don't have a standard tag embedded inside the image itself?

Using a text file packaged with the artwork is how we do it now. Currently, the art packs that are freely downloadable from RPTools support a license.txt and many of the art packs also include info.jpg or screenshot.jpg, although those are not used by MapTool at all.

Here's the license text that comes with Steel General's art packs:

These token images were created by Steel General for release with the stable version of maptool 1.3. They are licensed for re-use and distribution under the Creative Commons share-alike, non-commercial, attribution license: http://creativecommons.org/licenses/by-nc-sa/3.0/

Please visit us at: www.cartographersguild.com

Notice how it's English text plus a reference to a standardized license text, ie. BY-NC-SA 3.0 license.

We would ideally want to be able to collect all assets that use that same license to refer to a single entry in the campaign file. That means somehow extracting the pertinent part. A simple solution may be to require the license field to be a URL. The creator can point to a well-known site like CreativeCommons.org or to their own site. We would download the text, normalize it, and then store the result.

I would think a minimum set of information would be the creator's name, email address, home page, license URL, and release date... and maybe a download date for art packs that we distribute through our site.

I think the far trickier consideration is code attribution for the many contributors within the community. When you consider someone using Melek's 5E framework with Merudo's spells, the BOT and doors and other addons, the list of code attributions and/or share licensing could be quite complex as it would have to include SRD/OGL statements as well as those of the actual code creators.

You're thinking a single distributable package might have some components covered by the OGL, while code written by a framework author could be under a different license? A token representing a monster could then be covered by 3 different licenses: one for the art work, one for the SRD data, and one for any on-token macros meant to manage that token. Ugh!

The art work license has been covered, above. The macros could be handled by adding a license URL to each macro (perhaps on the Details tab for the macro). The data from the SRD can be covered by a single OGL disclaimer.

Stat blocks are not copyrightable, nor are individual ability names or other components from the stat block (although see the linked article, below). It then appears that a single, overriding disclaimer that "some components are derived from OGL-covered works and are thus covered by the OGL", might be enough. More information on what can be or cannot be copyrighted is available here (note that the author writes in regard to US copyright law).

\

I've never been a fan of embedding SRD data into a token and distributing that token. A better approach IMO is to write a script that dynamically pulls the information from the web to create the token on the fly. The creator of the script isn't distributing potentially copyrightable information and the user simply runs the script as part of the install process. A nice side benefit is that the download size of the token shrinks. \

[bubblobill]

Smart door tokens each contain copyright permission information as token properties. Mostly because .png hold no metadata.

I think we would be better off having standard field/property names such as "copyright" and "license"

It might be nice to have a "Help" menu item to view licensing information that would allow users to view license details stored in the campaign.

[VagruariesOfFate]

Using a text file packaged with the artwork is how we do it now. Currently, the art packs that are freely downloadable from RPTools support a license.txt and many of the art packs also include info.jpg or screenshot.jpg, although those are not used by MapTool at all.

MT currently using that in the distributed art packs was what made me consider it as a standard way to access the information, because it seemed that as the resource was read, the license could be as well.

I would think a minimum set of information would be the creator's name, email address, home page, license URL, and release date... and maybe a download date for art packs that we distribute through our site.

Those would be more than sufficient for most purposes. In the case of unofficial works, there are often specific statements that must be included but that are not necessarily convenient to grab from a URL, so a freeform field would also be useful, at least one to go with any "main licensing".

Stat blocks are not copyrightable, nor are individual ability names or other components from the stat block (although see the linked article, below). It then appears that a single, overriding disclaimer that "some components are derived from OGL-covered works and are thus covered by the OGL", might be enough. More information on what can be or cannot be copyrighted is available here (note that the author writes in regard to US copyright law).

You need a copy of the OGL for each OGC source you are using, including your own if you're adding your own OGC. You then need to comply with "If you distribute Open Game Content You must clearly indicate which portions of the work that you are distributing are Open Game Content." In practice that generally means that in something like a monster listing, each entry would have to note if it was OGC, although it does not need to directly note which OGC source that particular instance is using.

You're thinking a single distributable package might have some components covered by the OGL, while code written by a framework author could be under a different license? A token representing a monster could then be covered by 3 different licenses: one for the art work, one for the SRD data, and one for any on-token macros meant to manage that token. Ugh!

Unfortunately it's worse than that. Consider a campaign using Melek's framework, bubblobills monsters, Illydths spell states, BoT, doors etc etc etc, the number of community licenses/attributions involved could be quite extensive. Even a single authors framework may incorporate code from dozens of contributors. Covering the formalized ones like OGL are relatively simple.

I've never been a fan of embedding SRD data into a token and distributing that token. A better approach IMO is to write a script that dynamically pulls the information from the web to create the token on the fly. The creator of the script isn't distributing potentially copyrightable information and the user simply runs the script as part of the install process. A nice side benefit is that the download size of the token shrinks.

I would agree with this and see no reason why it shouldn't apply to any easily accessible OGC source, like this one for Kobold Press OGC http://kpogl.wikidot.com/. This is more of a macro issue isn't it?