Suggestion to use SPDX identifiers in license.json in the future

[pixelzoom]

From https://groups.google.com/forum/#!topic/developing-interactive-simulations-in-html5/gqWoZ0JI9GQ ...

... Is the format of the license.json files a format Phet came up with or a standard I'm not aware of? Is there a reason you use the full license names as strings vs. the SPDX identifiers (https://spdx.org/licenses/)?

[pixelzoom]

This might also apply to sherpa.

[kreynen]

Sorry. I should have made this clear in the first exchange with Oliver, but I'm less interested in the PhET specific workflows or contributing sims than I am in PhET as an example of how a successful project handles code and asset licensing. I chair the Drupal project's Licensing Working Group. When faced with a similar need, we failed to find a standard so we came up with https://www.drupal.org/node/2529774 and had projects add the yml file to the root of their project directory like http://cgit.drupalcode.org/user_guide/tree/ASSETS.yml

After working with other manifest files with package managers like Composer for a few years now, we're rethinking everything about this format (yml vs. json, strings vs. SPDX values, the location of the file in repos, etc). Drupal follows a similar licensing model for code (GPL-2.0+ or lax license like MIT that essentially allows it to be re-licensed as GPL when distributed with GPL), but as different open licensing for non-code assets have gained popularity like SIL-OFL for fonts and CC-BY-SA, explaining which parts of a project than combines code and assets is becoming increasing difficult. If a developer includes SIL-OFL-1.0 in the composer.json license element because they've included an icon font with that license, a scan of all of the licenses in all the packages of a project would indicate that the project can no longer be distributed as GPL-2.0. Because while "GPL friendly", SIL-OFL isn't strictly GPL compatible.

I was really hoping that PhET or someone in the OER world had already solved this problem and we could just adopt this standard, but it sounds like you've taken a similar path to end up in a similar place.

[pixelzoom]

For the benefit of other PhET team members... @kreynen started the Google Group thread that motivated creation of this GitHub issue.

[zepumph]

It was mentioned in the first comment, but I just wanted to be explicit. Here is the list of SPDX identifiers, https://spdx.org/licenses/

[ariel-phet]

@samreid do you have thoughts here since you have mainly been the licensing person? It seems like this is potentially a simplification.

[pixelzoom]

Relative to everything else that's going on, this is probably super-low priority. In addition to the SPDX identifiers, it would be interesting to think about whether the problems/challenges encountered by Drupal apply to PhET.

[samreid]

I wrote privately to @kreynen

I'm not aware of any standards or tools for licensing non-code assets, but I would naively expect that many of the same strategies for managing code licenses would transfer to non-code assets licenses. We have developed something sufficient for our project and we will not be able to assist in creating a new standard, though I can see the value in it (especially if adopted by image/asset providers).

As far as I can tell, PhET doesn't stand to gain much by moving to SPDX, the list of licenses we currently use is posted at https://github.com/phetsims/sherpa/blob/master/third-party-licenses.md#third-party-code-license-summary

If one of our future clients wants to move to formal SPDX in the future, we could tackle it then but it hasn't been a problem yet. @ariel-phet what do you think?

[kreynen]

many of the same strategies for managing code licenses would transfer to non-code assets licenses

They do, but without a standard for the json or yml it is difficult to build tools to vet licensing of the non-code assets and develop best practices for developers to declare all of the licenses used in a project. While packaging managers like Composer and NPM were originally developed for specific languages/frameworks, they now contain many assets in addition to code.

When looking at something like https://packagist.org/packages/fortawesome/font-awesome, the developer has declared the project is licensed as MIT and OFL-SIL, but what does that really means? In this case, the code is licensed as MIT and the font as OFL-SIL. Other packages only declare the license of the code even when the package even when it includes images licensed as CC-BY-SA used in the UI. If a developer includes CC-BY-SA or SIL-OFL is the composer.json for the project, a scan for trying to determine strict license compatibility will flag those projects.

GitHub has gradually increased the visibility of licenses over the years from adding https://choosealicense.com/ for new projects to using code to scan for a License.txt and match that to a known license. That is great for projects that use a single license, but this gives a false sense of confidence to users of projects that have combined several licenses in the repo and intended the LICENSE.txt to apply only the original code.

Drupal has avoided much of this complexity and confusion for years by enforcing a strict EVERYTHING committed to the git repos that package the code downloaded from Drupal.org must be licensed as GPL-2.0+, but this policy has become increasingly detrimental to the project. It has always made it more difficult to collaborate on themes and documentation (we had to grant our documentation team an exception to the GPLv.20+ policy when they wanted to modernize their approach to technical documentation by leveraging version control), but as the communities of creators who share UI elements and documentation adopt licenses appropriate for their work and these assets get included with code in new and interesting ways, our current, code-centric systems start breaking down.

WordPress went a different direction focused more on protecting the 4 essential freedoms of the GPL and defining a list of allowed, GPL friendly licenses for assets like images and fonts.

So while Drupal has kept our repos "clean" of additional asset licenses, we don't have nearly as many interesting themes and often offer less than ideal user experiences that require users to manually add additional assets after installing the code. WordPress offers many more options and better user experiences, but the licensing of these projects is suspect. It doesn't take more than a few minutes to find a WordPress project that includes incompatible or even commercially licensed assets in projects distributed from WordPress.org.

For years, members of the Drupal community have "trolled" the internet trying to get projects to change their licenses. Drupal was the reason JQuery was dual-licensed as MIT and GPL for a few years. We were the reason Bootstrap switched from Apache-2.0 to MIT and FontAwesome now describes their project as GPL friendly vs. GPL compatible.

I understand that your current solution for license.json files meets your current needs and without infinite resources, properly prioritizing requests is essential to meeting your goals. If the license.json files no longer meet your needs at some point in the future, please ping me. Hopefully the Drupal project will relax our strict GPL compatibility policies and we'll make some progress on defining a standard for declaring non-code assets that works well with GitHub and current package managers.

[ariel-phet]

@kreynen first of all we certainly appreciate you reaching out to us and sorry we do not have a great standard to share. Also, thanks for the thorough and thoughtful explanation above.

As mentioned, we probably cannot take any action in the near future, but if license.json starts to become problematic in the future or we have encounter clients with needs for us to modify our approach we will most definitely be pinging you.

Unassigning for now, marking deferred.