Clarify <project_license> for documentation

[pwithnall]

We’ve come across an issue recently where a project gave its license as

<project_license>GPL-2.0+ and CC-BY-SA-3.0</project_license>

I assume (but am waiting to confirm) that this is intended to convey that the code is under GPL-2.0+ and the documentation is under CC-BY-SA-3.0. However, in SPDX, and means the terms of both licenses must be complied with, which means that the code must also be licensed under CC-BY-SA-3.0 and the documentation must also be licensed under GPL-2.0+.

CC-BY-SA-3.0 is not FSF or OSI approved so this has the end result of as_license_is_free_license() saying that this project is proprietary.

I think the fix here is for the project to simply use:

<project_license>GPL-2.0+</project_license>

since that’s the license for the project as a whole, and CC-BY-SA-3.0 is only used for a portion of it.

That leads to the question of how to avoid this situation in future. My suggestion would be the following, but I’m sure many other solutions are possible and might be better:

• Clarify in the spec that project_license is for the top-level license of the project (typically the one applied to the code, for a software project)
• Potentially add a new <documentation_license> element for exposing the license of the project’s documentation independently of <project_license>

[ximion]

Interesting! I agree with your issue description and solution suggestion - project_license is a SPDX license expression for the project-as-a-whole / the actual code, so AND is definitely not correct in this case.
That clarification should be added.
I am a bit wary about adding something like documentation_license, unless there's a clear use for it - for Debian, the debian/copyright file for a software package usually contains a full breakdown down to individual file level as to which license they are subjected to. I fear that we'd be replicating something like this eventually once we allow documentation_license, as more projects will then want to further clarify their licenses by adding more subcomponent-licenses to their metainfo files.
The other side of the argument is of course that documentation is usually the thing with a separate license from the actual code, so having that tag would cover most "different license exists" cases, while also being a bit more complete and honest.
Then the question remains whether a project with a non-free documentation license is also "non-free" or not...
Also, should that extra license be shown to the user? If so, how? What's the value for an end-user for having this? A machine can't use it to accurately determine license-compliance, as the accuracy of the three license_* tags would still be too coarse, and a more fine-grained breakdown like a d/copyright file would likely be needed to have the data needed for any legal case.

I think clarifying project_license is a good first step.
I also think that it may make sense to add a helper function to appstreamcli for projects to easily check whether a license(-expression) is considered to be non-free or not, rather than being surprised.

I'm also actually surprised that CC-BY-SA-3.0 is neither OSI nor FSF-approved - that license has been around for a while!

[pwithnall]

I think clarifying project_license is a good first step.

⇒ #313

[pwithnall]

Do we want to do anything else here? Reading through this all again, it feels to me like making further changes (like adding a <documentation_license> element) would be premature, given there’s currently no use case for them. I can’t see us showing the documentation license for apps in gnome-software.

Perhaps this can be closed and revisited if a use case arises for exposing additional high-level license data?

[ximion]

Agreed, I think with clarifying the intent of project_license in the specification, we addressed the issue for now. If it turns out we need more, and more advanced license notations for some reason in the future, we can always revisit this and make further changes :-)