License

[endian-albin]

Could you please add a license to this project?

[Avamander]

@vilhelmgray

but GPLv3 severely limits hardware designs that would otherwise not be a problem;

I kind-of get what you mean. There are theoretical scenarios where anti-tivoization hinders but right now those are kind-of very niche e.g. those projects using ROM MCUs and I frankly really doubt it's worth losing the tivoization and patent protection for.

[endian-albin]

I can envision users in the future wanting to distribute Pinetime firmware loaded in a device with hardware security features; GPLv3 might cause a legal problem for those users

Not at all. It would simply guarantee that the owner/user receives the keys to the lock, or instructions on how to set it up, along with the full corresponding source code. Let's say for example that the owner is not an individual but a company, and the company owns a bunch of hardware devices running GPLv3-licensed code intended for use by its employees. Then the user (i.e. the company) has every right to restrict what software can be installed. The anti-tivoization clause simply prevents the legitimate user from being exploited by en entity that gives it source code which can only be modified by the developer, not the user.

[endian-albin]

It would be useful for a hardware designer making some sort of cheap device to use non-expensive ROM components to embed a pixel draw routine that uses this code (with of course different implementations of the called functions). [...]

With GPLv3, such a hardware design would not be allowed because those ROM components could not be changed. But using writable memory might drastically increase the cost of the device, or have other hardware implications.

@vilhelmgray, you should actually read the license instead of spreading FUD. I quote directly from the GPLv3 license, section 6:

Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

Once again, the GPL protects the user from being exploited in a situation where the developer can push updates to a device but the user cannot. Where none of them can perform updates, anti-tivoization does not apply.

[vilhelmgray]

I was mistaken, it looks like ROM is not affected by this clause then.

[endian-albin]

By the way, ATCWatch has now finally been released as Free Software, under the GNU GPLv3 or any later version. Another good reason to choose this license.

[Avamander]

But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

Huh, don't know how I've missed that. Thanks for informing me/us.

[JF002]

Thanks for all these details! So, we are still good to go with the GPLv3?

[vilhelmgray]

Yes, as endian-albin pointed out: GPLv3 is the only GPL that enables us to incorporate Apache 2.0-licensed works; that means GPLv2 is not an option.

[endian-albin]

Yes, but I see two related issues that should also be resolved:

1) GPLv3-or-later or GPLv3-only? This should be specified in each source file. 2) A policy regarding binary blobs?

My own answers to these questions:

1. GPLv3 or any later version, because it's the variant recommended by the FSF and chosen by ATCWatch. Wasp-os also has the or-later suffix (although it's LGPL).
2. I believe including a blob such as the accelerometer "config" directly would be possible only with exception language added to the GPL. Exceptions are not very nice I think, and they can be removed by a subsequent redistributor. It would also be a great stance to keep blobs out from a philosophical point of view. It might encourage reverse-engineering work and other innovative efforts working around them. Finally, if you really want to ship blobs you can always put them in ROM ;)

[vilhelmgray]

Keep in mind that there are developers that avoid projects with the "or later" language -- in some cases specifically because of how spiritually different GPLv3 was from GPLv2. The "or later" language is there to ensure compatibility with future GPL releases, which has been a problem in the past when trying to incorporate older code with newly licensed code.

Compatibility with a future GPL is a concern, so I recommend an alternative that should appease both developers opposed to the "or later" wording as well as developers that want to ensure compatibility with future GPL releases: create a Contributor License Agreement.

A contributor license agreement would be prudent regardless to resolve any future licensing issues. It's difficult to track down every single contributor -- and then on top of that have every single one of them agree to a change -- so a contributor license agreement would ensure that at least a change can be made with a reasonable majority of contributors agreeing to it. This should ensure that the code can be compatible with not only future GPL releases, but also any other license that might be desired.

[Avamander]

@vilhelmgray

Keep in mind that there are developers that avoid projects with the "or later" language -- in some cases specifically because of how spiritually different GPLv3 was from GPLv2. The "or later" language is there to ensure compatibility with future GPL releases, which has been a problem in the past when trying to incorporate older code with newly licensed code.

I concur. It's very hard to predict what GPLv4 might end up like. I however don't think CLAs are worth the burden, GPLv3 will probably be good for a good few decades, very likely far beyond what the project actually sees.

@endian-albin

A policy regarding binary blobs?

If the blob doesn't allow the project there's nothing that would allow the project to use the blob. Providing a way to OTA-push such blobs is very likely the only safe method of having compatibility. Same goes with alternative BT stacks, proprietary watchapps and so on.

[endian-albin]

@vilhelmgray, @Avamander

@vilhelmgray

Keep in mind that there are developers that avoid projects with the "or later" language -- in some cases specifically because of how spiritually different GPLv3 was from GPLv2. The "or later" language is there to ensure compatibility with future GPL releases, which has been a problem in the past when trying to incorporate older code with newly licensed code.

I concur. It's very hard to predict what GPLv4 might end up like. I however don't think CLAs are worth the burden, GPLv3 will probably be good for a good few decades, very likely far beyond what the project actually sees.

It's not certain that GPLv4 will be the next version, but GPLv3.1 that patches a loophole within some jurisdiction. Even constitutions for countries intended to stay invariant do receive changes over time. Choosing "GPLv3-only" means that you are betting that a license published in 2007 will be 100 % water proof in 200+ countries forever. I sure hope it will, and I personally don't want to see another version of the GPL if it's not necessary. If, however, the license is somehow, somewhere, deemed invalid or incompatible in some important way by a court, then it's pretty bad for every project that contains "-only" code, e.g. a successor project to this one.

Another thing to keep in mind: if a new version of the GPL is being drafted and some of the core contributors disagree with the proposed changes, then they can begin releasing their contributions under "GPLv3-only" and thus close the door to a potential license update. Doing it the other way around is far more difficult, i.e. to ask every single contributor to relicense their changes (adding -or-later).

The GPLv2-only and GPLv3-only are, as far as I know, unique in containing the risk of being frozen in time. Most other licenses are more permissive and can thus be incorporated in many different projects anyway (e.g. Apache 2.0 or BSD 3-Clause). The other major non-GNU copyleft licenses have "-or-later" built-in, namely: CC BY-SA, Eclipse Public License and the Mozilla Public License.

@endian-albin

A policy regarding binary blobs?

If the blob doesn't allow the project there's nothing that would allow the project to use the blob. Providing a way to OTA-push such blobs is very likely the only safe method of having compatibility. Same goes with alternative BT stacks, proprietary watchapps and so on.

Okay, that could be a way to do it. So it would be up to the user to fetch such blobs after receiving the device, like it's done in the Debian project. The blobs would then need to be placed in some other location and also not be derivative products of the GPL'd firmware (which is true for the HR sensor and the accelerometer blob). I believe this would be a sensible compromise. The inconvenience of having to fetch blobs yourself would encourage finding ways not to be dependent on them, but those who really want to can still get them.

[Avamander]

Choosing "GPLv3-only" means that you are betting that a license published in 2007 will be 100 % water proof in 200+ countries forever

Nah, not really forever and that's really not needed either.

but GPLv3.1 that patches a loophole within some jurisdiction.

One literally can't know. Plus, that loophole can also be fixed by licensing all new files under the improved version (if the patch isn't too massive), and also relicense as many other files as possible. I really really doubt it will become a problem during the lifetime of the project or even twice that.

The GPLv2-only and GPLv3-only are, as far as I know, unique in containing the risk of being frozen in time.

Nothing has really happened to GPLv2 either during all this time. Copyright law is rather "frozen" in time as well. I can't really see it as a bigger risk than an unknown future license could be.

[endian-albin]

One literally can't know. Plus, that loophole can also be fixed by licensing all new files under the improved version (if the patch isn't too massive), and also relicense as many other files as possible. I really really doubt it will become a problem during the lifetime of the project or even twice that.

Nobody knows -- there are some risks both ways. Personally, I think there are greater risks in making it hard to bump the license version than not, maybe especially for other projects that copy code from this.

I really really doubt it will become a problem during the lifetime of the project or even twice that.

But do you really fear then, within the lifetime of the project, the risk of a horrible new version of the GPL being published by the FSF rather than no new version or an improved one?

Nothing has really happened to GPLv2 either during all this time.

Yes, it has though, although nothing absolutely critical. If you've ever torrented a GNU/Linux image containing just the binaries (say DVD1 of Debian), then you've most likely violated the GNU GPLv2 (only), since you haven't also provided corresponding sources or a promise to give them, and thus lost the right to use all the software under GPLv2-only. You would now need to ask every single contributor of Linux to get back your rights to use, modify and copy Linux ever again. The GPLv3 has language to fix this issue, to explicitly allow for this type of redistribution and a more forgiving language with regard to violating the license, but for example the Linux kernel will never be able to integrate these improvements. Another related issue: the recipient of GPLv2 binaries can always request to receive the complete corresponding source code on a physical medium and you will be forced to give them like this. GPLv3 allows you to provide the sources over the Internet only. Other similar issues may show up for GPL version 3.0.

Instead of a CLA, there is the possibility of making use of a certain "proxy" feature of the license:

If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.

Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.

I still think the standard "or, at your option, any later version" is the way to go though.

[JF002]

GPLv3-or-later or GPLv3-only? This should be specified in each source file.

I prefer the GPLv3-or-later, as it is the variant recommended by the FSF, and because I think there are greater chances that no new version or an improved version of the license will be released than a bad one.

A policy regarding binary blobs?

As far as I know, we don't know the license of these blob and should not use them. I think many people will want the step counting, motion activation, HR measurements,... and we'll have to find a workaround (re-implement/retro-engineer the algo in soft, ask politely to the manufacturer to open their blobs,...).

So, are we OK with GPLv3+?

[JF002]

Thanks a lot to every one who helped me in this very difficult choice! This discussion was very interesting and I learnt a lot about open-source licences.

I can now finally close this issue after more than 4 months of debate :)