License compatibility and SPDX identifiers

[ivan-pi]

Given how easy it is to glue together several Fortran packages, I was wondering how do we want to approach licensing.

Say I want my code to be MIT licensed, but I find an awesome package with the GPL license (e.g. FFTW).

According to my current understanding, since fpm wilI download each package from it's original repository, licensing doesn't really matter as long as I only plan to run the executables on my own PC. Is this correct?

How about if I depend on package, which contains some custom clauses, like citing a published work? I don't think it makes sense for fpm to keep track of such things. But as a user, I also don't see myself inspecting an entire chain of packages to verify all the licenses.

I guess the same question applies to all other package managers (conda, pip, cargo...), but I never really thought about this until now. Do those projects have some guidelines on how to manage licensing information in an automatic way?

I noticed several projects of @awvwgk use SPDX identifiers, but haven't fully grasped how these are supposed to be used.

I look forward to any thoughts on this topic.

[awvwgk]

There are several aspects here. Licensing is quite a hole to go down.

First, personal usage is covered by the respective software license. Assuming all software in your dependencies are using free open source licenses you should be fine. The actual definition of free open software license might differ depending on who you are asking.

Second, custom clauses are usually interesting, because they are not always compatible with the open source license they are combined with. In most cases this means they make the license stricter if not created carefully, of course, those clauses can propagate and must be tracked.

Third, some licenses require preservation of copyright statements or inclusion of the license text. A package manager therefore must package the license and this is where it gets ugly, especially MIT and BSD-type licenses are difficult to package. For the fpm package on conda-forge I've collected and packaged the license files of all dependencies manually, in this case it are three versions of the MIT license and the Apache-2.0 license. Statically linking and redistribution usually require inclusion of the license.

It becomes more complicated for larger projects with more dependencies to collect the actual licensing conditions. Which is an actual issue in the Rust's cargo ecosystem, because everything gets linked statically. Figuring out the actual licensing term of the resulting binary distribution is always a lot of fun. SPDX identifiers and other license tool chains can simplify this task quite a bit.

Partly relevant: #169

[vmagnin]

In my opinion, if fpm is just downloading a package to use it, it's like using any library: if the library is free (or if you paid to download it) and if there is no special clause concerning the use of the software (see for example the Anti-capitalist License Software), it's OK.

But if there is special clauses like the one you cited:

How about if I depend on package, which contains some custom clauses, like citing a published work?

it's your responsibility as a developer to respect those clauses. And to inform the user of your project in the README.

If you respect those clauses, you can distribute your project as an fpm project (you distribute your project but not the dependencies).