License changes

[Univa]

Early on in the history of this repo, I threw on the MIT license. Looking back in retrospect, and looking forward about the potential directions of this project, I realize that MIT may not be the most appropriate choice for all parts of this repository.

I plan on changing parts of this repository (if not all) over to GPLv3 for two main reasons:

• I want to respect the licensing of any referenced code from other GPL projects
• I want to use crates that are licensed under GPL (which would enable us to support some GPL-licensed drivers)

That being said, I'm opening this issue for discussion on potential ways forward, as well as getting the appropriate permissions from other developers to handle code that might be affected by these changes. I will also be trying to get in contact with people I believe to be copyright holders for some relevant code.

Some possible solutions I thought of:

• Changing the license for the entire repo to be GPLv3
• Moving certain parts of the codebase into their own separately GPL-licensed crates (like Via/Vial, Lighting, and the drivers), while keeping the core rumcake crate under MIT
  • I foresee this introducing some technical challenges, and may have effects on usability.

Other potential concerns:

• Licensing of older commits in git history

[Univa]

@zUnixorn @kuolemax since both of you are contributors, I'd like to get your permissions for (potentially) re-licensing parts of the repository that you have contributed to. Any input on possible solutions would be appreciated too.

[kuolemax]

I would prefer to change the license of the whole repository to GPL, separating the create would complicate the maintenance of the project, whatever, I support your choice.

[Univa]

Thanks for the input. @zUnixorn any input?

[zUnixorn]

Sorry, just saw this now. First of all I have no problem with a license change.

But I think using GPL'd libraries is already possible with the MIT license, since its GPL compatible.

Changing to the GPL could also cause incompatibility with some libraries, afaik QMK didn't really support Bluetooth among other things, because of licensing issues.
Would splitting the project in differently licensed part solve such issue?

Otherwise I think changing the whole project would be much simpler, rather then splitting.

In either case, it would be sensible to check if all of the currently used libraries are compatible with the GPL. For example nrf-softdevice is closed-source, so I am not sure if it could be used in an GPL licensed project.

[Univa]

But I think using GPL'd libraries is already possible with the MIT license, since its GPL compatible.

My understanding of this is that by introducing GPL code, the combination would need to be released under the GPL. Based on that, I believe the rumcake crate would also need to be under GPL if we introduce any GPL dependencies. Regardless of dependencies, I have made it no secret that some of the rumcake code itself borrows from other GPL projects. Like I said in the original post, I'd like to respect that licensing, whether that means removal of that code or making the repo GPL.

Changing to the GPL could also cause incompatibility with some libraries, afaik QMK didn't really support Bluetooth among other things, because of licensing issues.
Would splitting the project in differently licensed part solve such issue?

In either case, it would be sensible to check if all of the currently used libraries are compatible with the GPL. For example nrf-softdevice is closed-source, so I am not sure if it could be used in an GPL licensed project.

All of the libraries used in rumcake/Cargo.toml are MIT-licensed (or MIT+Apache dual-license), so they should be fine to use. It looks like the nrf-softdevice crate by itself is MIT+Apache, but it depends on generated bindings, which are subject to the Nordic license, which I believe would be incompatible with the GPL (I believe this license is the same reason that QMK couldn't add it). With that in mind it seems like we have to decide between GPL or bluetooth 😅. Maybe it'll be possible to have both if trouble gets a GATT client? Edit: nvm, looks like nrf-sdc has submodules which also use a Nordic license

[Univa]

Just wanted to leave an update, since I've been doing some work behind the scenes on this:

My understanding of this is that by introducing GPL code, the combination would need to be released under the GPL. Based on that, I believe the rumcake crate would also need to be under GPL if we introduce any GPL dependencies.

After doing a little more research and thinking, my understanding has since changed. The resulting binary compiled by rumcake crate users would need to be GPL. But I'm not so sure about the licensing of the rumcake crate by itself. I've seen some discussion saying that it's okay if you have an GPL dependency in an MIT licensed crate 1 2, but it's unclear to me if simply using a GPL library in the crate's source makes it a derived work which needs to be licensed under GPL. So in terms of supporting GPL-licensed drivers, maybe it's best to be on the safe side, and either re-package certain driver implementations in a GPL crate, or just not support GPL drivers.

As for an update on what I've been working on: I got in touch with @tzarc, and he has given me some helpful pointers on how to handle the GPL parts of the code. The problem with sticking with nrf-softdevice is that it makes it impossible to distribute rumcake binaries with bluetooth support if it also includes GPL parts. That being said, I saw three ways forward for the bluetooth situation:

• Replace nrf-softdevice with a different bluetooth stack with GPL-compatible licensing
• Remove QMK-referenced parts from this repo
• Remove bluetooth support

Obviously, the latter two solutions would mean removing features that I find useful, so I've been working on bindings for the NimBLE project for a bit, to hopefully replace the usage of nrf-softdevice in this repo. After that's done, there will be a little more flexibility in deciding how to handle the rest of the GPL stuff.