Might change the license to GPLv2.

[DrewNaylor]

I really don't want to do this because I don't like the GPL as it's so restrictive and is involved with the same organization as RMS, but there's this .NET 5 library for getting PinePhone hardware stuff that would be really useful and it's GPLv2 licensed: https://github.com/Alumniminium/PinePhoneCore

As a result of changing this to the GPLv2 (would prefer v3+ as it allows Apache Licensed stuff, but the license isn't v2+ as far as I can tell), I'd have to change some of my other projects I'm planning on using to use the Expat License (some call it the "MIT License", but that's inaccurate).

Just trying to see if there's any feedback about this.

[DrewNaylor]

Actually, I may be able to keep the main part of the project under the Apache License 2.0 and just make a GPL'd CLI application that uses the PinePhone hardware library to send information back to the Standard Out. The benefit of this is that the GPL won't infect the main code for Retiled, and the CLI program can be easily replaced with something that's not under the GPL as long as the input and output stuff is compatible. It may even be possible to use something like Python instead just to be able to avoid using a GPL'd library in the first place.

[DrewNaylor]

Perhaps it would be a good idea to build an MEF plugin that uses the GPL'd PinePhoneCore library to make porting to other phones easier and allow people to delete or replace the plugin if they don't want GPL'd code to be used. I hope that's acceptable to the GPL, considering the plugin would be completely optional and easy to replace.

[DrewNaylor]

Actually, what I will probably do is build both a "Basic Hardware Support for PinePhone" plugin and an "Enhanced Hardware Support for PinePhone" plugin. The enhanced one will have to be downloaded and installed separately from Retiled because the plugin will call directly into PinePhoneCore's code, but the basic one can be included in the package because it'll be calling a CLI app that returns requested info via stdout. As a result, the basic plugin's main DLL can be under the Apache License 2.0, with its corresponding CLI app under the GPLv2. I'm pretty sure this is ok because the CLI app and PinePhoneCore run as their own process, separate from Retiled's processes that'll use it. I'm not distributing the enhanced plugin with Retiled, so the user will have to download and install it themselves, but there will be an install script (and uninstall script) to make it easy.

The benefit of the enhanced plugin over the basic one is that it doesn't have to run a separate program just to get info or do stuff like vibrate when pressing the navigation buttons. This may make things faster and reduce battery usage because it won't be constantly starting .NET to get the battery percentage, for example. One potential drawback of the basic plugin is that it won't be able to do things that require being used via events, as it wouldn't be aware of anything that happens beyond what the CLI app says when it runs it. Maybe pipes could alleviate some of that, but I don't think it would be allowed.

There would have to be a way to configure which hardware support plugin the user wants to use, so that the enhanced and basic plugins can be installed and uninstalled without affecting each other. This will be very important whenever hardware support plugins for other devices like the Librem 5 are developed, so the user can install the plugin they need without having to uninstall the basic PinePhone one first.

[DrewNaylor]

This discussion has been transferred to an issue so that it can be tracked more easily: #33.