LICENSE file step
anthonyronda opened this issue · 9 comments
CLI wizard step with license choices based on the most popular licenses.
User may check more than one to AND them together.
Crucially, I'm trying to create buy-in for including the full OGL license text in repositories that include open game content. This means dual-licensing in almost every case (for example, the SPDX license expression for dnd5e would be something like OGL-1.0a AND GPL-3.0-only). There are other efforts parallel to this to add OGL to the SPDX license list
Recommendations for what the actual LICENSE file contains, and what other files are necessary, when more than one license is used:
https://softwareengineering.stackexchange.com/a/371456
@anthonyronda Could you explain in more detail how and where the licensing information would be stored? In particular, how are the licenses combined? The stackexchange link you gave also is not completely clear about this (it mentions 2 different possibilities of what to write into the LICENSE file).
Also this does not seem to cover cases where different parts of the software are licensed under different licenses—it puts everything under the same license (which potentially consists of several licenses).
To be completely honest, this seems to be a very complicated and personal matter that heavily depends on the the author and the kind of content they want to (re-)use. I’m not really sure if it makes sense for Foundry Factory to provide this kind of functionality because I fear that it will not do the right thing in a lot of cases anyways. Sure, simple cases (like selecting a single license from a given set of licenses) can easily be covered but as soon as it gets just a tiny bit more complex, the number of possibilities explode. If we support combining licenses with AND, should we also support OR? What about nesting those? What about the case where different parts of the software have different licenses? And to make things worse, all of this heavily depends on the concrete preset anyways, as presets control which files / folders are created.
Presets also can already implement this functionality directly by themselves, there is no strict need for a separate step (though it might help if presets commonly use this feature).
Personally, I think the best option is for presets to just provide a same default and make it obvious that licensing is something the author needs to get right himself (e.g. the preset could provide a corresponding section in the README).
If you still think it’s worth having this feature in some way in Foundry Factory, please provide a more detailed explanation of how you would want it to work exactly, if possible by providing clear acceptance criteria.
Thank you, I agree with the reasons for your trepidation. It is definitely complex and this road is potentially fraught with terror.
I definitely have a specific vision for how this would work. In my view the current standard for Foundry modules is not cutting it and there's lots of room for improvement.
Let's talk about what role we serve when making tools. If we change the League template's LICENSE file to contain the url for choosealicense.com, with the intent that we make sure the dev informs themself of their options and replaces it with a real license, the effect of that would be pretty predictable. We'd see a bunch of new modules that have a link to choose a license instead of an actual license.
As it is, opinionatedly putting the MIT license in the League template and calling it a day is pretty good. People who care will change it, people who don't will still be making open source software which is a win.
A change like the one I'm proposing is taking that default assumption and at the very least forcing devs to acknowledge the choice of open source or closed source. No openwashing, for example.
Further, I want them to acknowledge their obligation to publishers like Wizards of the Coast and Paizo, and all the people whose work they might be using. Right now, in practice, we could use a lot more improvement.
I can answer to some of the finer implementation details in a follow-up, but for now I would like to hear if any of your worries are related to personal liability for failing to meet a certain standard of compliance due to some kind of oversight. I don't think that should be a worry, but I'll put more research to that end. Ultimately, the consuming developer is still responsible for keeping their licensing data accurate and not misrepresenting their work.
No, I don't see any liability on my end in any case. I'm not the one who is publishing stuff, it's the module / system author. So I don't see any problem there.
The problem I see is the fact that any solution we implement here is bound to be incomplete (at least that's my impression). Sure a simple "pick a single license from this selection of licenses" dialog is simple enough but as you mentioned in your original description, that's not enough in a lot of cases, e.g. because of multi licensing. And as far as I know, even SPDX doesn't have a standardized way of licensing different parts of a software under different licenses.
For reference, I'm bringing that up again and again because it is what I am doing in my own system (https://git.f3l.de/dungeonslayers/ds4/#licensing). DND5e is also doing it. You might think it's just dual "AND" licensing but there's a subtle difference: If you reuse the whole thing, then sure, it's the same as if it was dual "AND" licensed, but as long as you only use the software component from e.g. DND5e, which is licensed under GPLv3, then you can also use it under then terms of only GPLv3 and don't need to adhere to OGL.
So my fear is that any solution we implement is either totally incomplete or opinionated (about something which is not standardized). I'm not sure if it is worth having the incomplete solution over just a sane default but there's an argument to make here of course.
Another thing to keep in mind: In the end, presets should have as much control over their desired directory layout. Some presets may not even want to create a LICENSE file, for some it will always use the same license, and others might want a complicated dialog to set up the licensing info in the Readme.md and in LICENSE. So if Foundry Factory implemented something like this, it would need to be something hat presets can optionally tap into, if they want to, while still keeping control over the directory layout. Maybe we can implement a "Choose License" dialog that Presets can use to determine an SPDX identifier. Then they could use that in any of the files they create.... Or something like this
So, what is your exact expectation of how this would look like / work?
Still working on that answer!
I'm very interested in making this happen and making sure to address your concerns seriously and through applying the proper research first. This is a hard, but not insurmountable, problem. Creative Commons has forged this path with their Attribution Share-Alike 4.0 license one-way compatibility with GPLv3, and I believe we can take the same steps.
To address your concern, I will have to determine if GPL and OGL are compatible at all. If not, that might require dnd5e to change to LGPL or something else entirely. I intend to request the official opinion of the Free Software Foundation for that, but not before lining up all the other plans, which include a public website with the OGL in plaintext, more tools to apply the OGL to code, incorporating Atropos's feedback, completing my SPDX draft proposal, and contacting someone at WotC who shares our sympathies.
I think the main point is that you do not have to put your whole project under one license. You can define individual licenses for individual files. Of course, if somebody then uses / redistributes the project as a whole, he has to comply with all the licenses for all the files. But if he only uses a specific subset of the files, he only has to comply with the licenses for those files. E.g., assuming that it is actually valid for the code of dnd5e to be published under the GPL (because the code itself is not related too close to the DND rule set, which is licensed under OGL), the just reusing parts of the code of the dnd5e system can be done under the terms of the GPL only, without considering the OGL.
There actually are a couple of projects trying to define a sort of standard for this:
- The SPDX specification itself defines a format to describe software packages. A package can be a whole lot of things, including single files, directories of files, etc., and it can also consist of several sub packages. And it allows you to specify the licenses that apply to specific packages and sub packages.
- REUSE builds on SPDX, in particular the license list, but defines a much more simple format to specify licenses for every single file individually. It additionally provides a command line tool that can lint projects for compliance with the REUSE spec and spit out an SPDX compatible bill of materials for your project
- There's probably more...
REUSE seems like a promising solution to me, but it's not very wide spread yet, from what I understand. It does have a few notable supporter's though, mostly from the European and in particular German Open Source communities, including the KDE project, parts of the Linux kernel, and more: https://reuse.software/supporters/. The whole thing is driven by the FSFE after all...
For testing purposes, I started to use REUSE in one of my smaller foundry modules (https://git.f3l.de/ghost/risk-dice-modifier), you can take a look at it to get an idea of how this looks like. I even added a badge, that REUSE provides for compliant projects and a dded a corresponding lint step in my CI: https://git.f3l.de/ghost/risk-dice-modifier/-/jobs/3936
I think the main point is that you do not have to put your whole project under one license. You can define individual licenses for individual files.
I'm hearing you! Until you said something, I didn't consider the possibility that licensing code GPL AND OGL would have problems downstream. I kind of assumed all forks would be OGL-dependent somehow.
More importantly, I assumed that "all you have to do is add AND OGL" was the easiest sell to the maintainer of dnd5e. And from there, we might start to see wider use.
I'm currently making my argument for a more sophisticated solution in a proposal. I haven't started, but I'm prepared to define which parts of dnd5e's code are OGL-dependent and which are not myself using an appropriate SBOM tool.
I'll give REUSE a look for that. I've delved far into the SPDX spec a few times and there's just no way I expect to get stakeholders for an SPDX SBOM.
You can close if you'd prefer, I think this will take a bit.
I think this is out of scope for now, so I'm closing this issue.