License

[endian-albin]

Could you please add a license to this project?

[JF002]

Do you have any to recommand?

[poVoq]

You could keep it MIT licensed like LittleVGL?

But personally I would just GPL it. Version 3 or later.

[schilpr]

MIT or Apache are the most flexible,

[bergzand]

See also https://choosealicense.com/, the appendix has a comparison: https://choosealicense.com/appendix/

[endian-albin]

How about Mozilla Public License 2.0? It's a weak copyleft license compatible with both Apache 2.0 and the GPL. It requires the recipient to provide source code to the files under this license but allows linking with code under other licenses so it's really flexible. Our new project PineTime Hypnos will switch to Mozilla Public License 2.0.

[Avamander]

MIT or Apache are the most flexible

@schilpr only for other developers wanting to incorporate this code into their own projects. It also doesn't obligate them to helping this project out.

[endian-albin]

@Avamander: the GPL doesn't force you to help out an upstream project, just look at all the various Android kernel forks. It does, however, require the offer of the complete source code to the recipient of the software.

Fruitful co-operation between developers doesn't follow automatically from the choice of license, although it's not unimportant.

[Avamander]

the GPL doesn't force you to help out an upstream project, just look at all the various Android kernel forks. It does, however, require the offer of the complete source code to the recipient of the software.

@endian-albin I consider just having the code out in the open helping, and it allows things like custom ROMs to be made.

[JF002]

I had an interesting discussion on the chat about licenses the other day. I'm still wondering if I should choose GPLv3 or LGPLv3...

[endian-albin]

If you want to let other projects to use some component without re-licensing their applications to the GPL, then choose LGPL. If you want to ensure that your work can never be linked with proprietary or GPL-incompatible code then choose the GPL. You could also license certain components as LGPL, e.g. the drivers, and put the firmware as a whole as GPLv3 (or any later version).

[incyi]

Still not decided ?

[JF002]

Mhm I put this on the side to think about it and kind of forgot about it. But no, I'm still not decided. I don't want to make a bad choice. There're so many licenses, and so many terms and conditions... Also, I have to choose a license that is compatible with NimBLE, FreeRTOS and LittleVGL as I use them in the project.

Ok, here is a summary of what I understand:

• GPL guarantees that the code will only be used in open-source project, and that anyone who buys a device with the code will be able to access to the source code of its device
• LPGL is like GPL but allows someone to use the code into a non-opensource project (still has to publish the modification to the LGPL code).
• MIT and Apache allows to use the code anywhere and do not force to publish modification to the code.

These are the 3 main groups of licenses I found.

Personnaly, I think LPGL would be a good compromise, but what is your opinion? Which license do you think would be most benefical to the project?

[endian-albin]

@JF002, are all the components in your project Free Software now, or do you have any non-free dependencies? How about the heart-rate sensor and accelerometer?

It's high time to decide on a license, don't you think? Both the LGPLv3+ and GPLv3+ ("or any later version") would be good choices in my opinion, but if you have zero non-free dependencies, then the conditions of the regular GPL would be more clear, especially for the end user.

[endian-albin]

I see that the project depends on the nRF5 SDK which is non-free. Most of the SDK is under the nRF5 Nordic license, which contains the following restrictions:

4. This software, with or without modification, must only be used with a Nordic Semiconductor ASA integrated circuit.
5. Any software provided in binary form under this license must not be reverse engineered, decompiled, modified and/or disassembled.

Both the LGPL and GPL require reverse engineering to be allowed so this is a problem. From the LGPL license text:

You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications

The best would be to not depend on such non-free libraries at all I think. In the meantime, to release this as partly free under a license similar to the LGPL, you could use the Mozilla Public License 2.0 for your own source files however. This license requires that source code be provided to both modified and unmodified files, but allows redistribution alongside files that are proprietary or licensed differently. Another good thing about the MPL 2.0 is it that it can be upgraded to the LGPL, GPL or AGPL.

[Avamander]

@endian-albin

Both the LGPL and GPL require reverse engineering to be allowed so this is a problem.

It really isn't a problem. There's an exception for this in GPL: https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException

They can license it as totally regular GPL if they wish.

[endian-albin]

@Avamander, I'm not so sure about this. If it were only a question of providing the full corresponding source code, then maybe so, but the firmware image is distributed as a single binary, and if the Nordic license prohibits reverse-engineering, then I suppose all reverse-engineering of the binary is prohibited, and that makes it incompatible with (L)GPLv3. If there had been no Apache 2.0 components in JF's firmware, then the GPLv2+ license could have been used, but that's not the case. Therefore I still think the MPL 2.0 is the safest option in this situation. It's still a copyleft license.

From the GPLv3 license text:

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.

[endian-albin]

Well, another option would be to take the regular GNU GPLv3+ but make use of §7, "Additional Terms", where you add an exception and state that §3 "Protecting Users' Legal Rights From Anti-Circumvention Law." does not apply or something along those lines.

[Avamander]

@endian-albin

but the firmware image is distributed as a single binary, and if the Nordic license prohibits reverse-engineering, then I suppose all reverse-engineering of the binary is prohibited, Well, another option would be to take the regular GNU GPLv3+ but make use of §7, "Additional Terms", where you state that §3 "Protecting Users' Legal Rights From Anti-Circumvention Law." does not apply.

Assuming that RE clause is incompatible won't make the rest of the license void, there's really no need for any exceptions. But if we assume the RE clause is compatible, it would apply only to reverse engineering the SDK. Both of those cases only apply if we assume the RE clause even applies to System Libraries, but as System Libraries aren't a part of Corresponding Application Code they don't fall under the application's GPL at all (I think). Plus Nordic has no history of being mean to FOSS.

And we can't forget that this all also depends on the jurisdiction of the person distributing the binary, just as an example, that no RE clause in the Nordic license is already mostly void in my country :S

In all the possible cases, I don't think that's a problem to be concerned about, IANAL though.

[endian-albin]

Ok, you may be right about system libraries. If one wants to be even more certain, here is exception language by the FSF for combining with non-free libraries:

Additional permission under GNU GPL version 3 section 7

If you modify this Program, or any covered work, by linking or combining it with [name of library] (or a modified version of that library), containing parts covered by the terms of [name of library's license], the licensors of this Program grant you additional permission to convey the resulting work. {Corresponding Source for a non-source form of such a combination shall include the source code for the parts of [name of library] used as well as that of the covered work.}

[JF002]

@endian-albin @Avamander Thanks for waking this thread up! You're right, now is the time to choose the licence ! I'm still completely lost in all these tems, exceptions and compatibility across licenses!

The code uses

• FreeRTOS (MIT)
• Apache NIMBLE (Apache 2.0)
• LVGL (MIT)
• NRF SDK (non-free?)
• Code, info and help from the whole pinetime community

I use the NRF SDK for low-level stuff (logging, startup code, clock driver, register definitions,...). I've already reimplemented the SPI and I2C driver as they were buggy/too slow.

About the accelerometer and the heart-rate sensor : they are not integrated for now in the firmware, BUT... they only way people managed to get them working is using binary libs and BLOBS (I don,t know how they got these libs and files). It would be a shame if we couldn't add support for these devices because of license issues...

So, for now, we are talking about GPL, LGPL and MPL. What do you think?

[Avamander]

@JF002

I said this on TG as well. but I think you should focus on protecting your own code and the values you deem fit. Leaving the fundamentally incompatible binaries out of the equation. Basically the Android ROM and GApps (or Linux and proprietary drivers) model.

I personally would pick GPL, I don't think LGPL or MPL will make distribution any easier but will lose certain protections, but the choice is really yours.

[lupyuen]

Shall we leave out the accelerometer and the heart-rate sensor for now? Maybe it could come from a future OTA download (assuming that we solve the licensing issue). Or it could be distributed via another repo that will have different licensing.

[endian-albin]

About the accelerometer and the heart-rate sensor : they are not integrated for now in the firmware, BUT... they only way people managed to get them working is using binary libs and BLOBS (I don,t know how they got these libs and files).

There is a discussion about getting the accelerometer to work using only Free Software so in this case I think blobs can be avoided.

It would be a shame if we couldn't add support for these devices because of license issues...

Personally, I don't like blobs and think that they don't belong in a project like this. I've removed the heart rate sensor completely from my own device for example.

Although the MPL would be more flexible and easier to apply perhaps, maybe it's still worth it to go for the GPL so as to encourage work on finding replacements to these blobs and non-free libraries that you mentioned? Maybe it would also encourage Pine64 to choose better components in the future...

Instead of leaving out incompatible licenses of the equation, I think it's more appropriate to add an additional permission on top of the GPL which says explicitly that the software may be combined with the Nordic SDK. It would deal with the reverse-engineering issue for the moment, and make it clear that you've made one exception but otherwise intend to keep everything fully free. To do this concretely, you could add the following notice at the top of each of your own source files as well as include the GPLv3 license in the source tree.

Copyright (C) [years] [name of copyright holder]

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, see https://www.gnu.org/licenses.

Additional permission under GNU GPL version 3 section 7

If you modify this Program, or any covered work, by linking or combining it with the nRF5 SDK (or a modified version of that library), containing parts covered by the terms of the nRF5 Nordic license or the nRF5 Garmin Canada license, the licensors of this Program grant you additional permission to convey the resulting work. Corresponding Source for a non-source form of such a combination shall include the source code for the parts of the nRF5 SDK used as well as that of the covered work.

If you are not using anything under the nRF5 Garmin Canada license, then remove it from the text. If you're using anything under the SoftDevice license, you should include it. Then add a notice somewhere in your README saying that contributors to the project must agree to license their contributions under these conditions. (The additional permissions may be removed by anyone who uses the GPL'd code for their own projects.)

This is my suggestion, but it's up to you of course, @JF002.

[Avamander]

@endian-albin

I think it's more appropriate to add an additional permission on top of the GPL which says explicitly that the software may be combined with the Nordic SDK

IMHO the SDK is fine anyways as a System Library and doesn't need special permission. It's how GPLv3 software can use Windows APIs/headers freely, there's no known issues. It's the sensor blobs of unknown origin ("(I don't know how they got these libs and files).") that are an another can of worms. No license or additional permission can help you against blobs that don't allow you (that you don't have the permission to use).

Corresponding Source for a non-source form of such a combination shall include the source code for the parts of the nRF5 SDK used as well as that of the covered work.

If parts of the SDK are binary, you can't ask for the source code. :S

, or (at your option) any later version.

There's no way to predict what the next possible version could bring, I would be wary of adding that part.

[endian-albin]

@endian-albin

I think it's more appropriate to add an additional permission on top of the GPL which says explicitly that the software may be combined with the Nordic SDK

IMHO the SDK is fine anyways as a System Library and doesn't need special permission. It's how GPLv3 software can use Windows APIs/headers freely, there's no known issues. It's the sensor blobs of unknown origin ("(I don't know how they got these libs and files).") that are an another can of worms. No license or additional permission can help you against blobs that don't allow you (that you don't have the permission to use).

You may be right. It's not defined exactly what counts as a system library but I suppose that this does. If so, the added permission isn't necessary, I agree.

Corresponding Source for a non-source form of such a combination shall include the source code for the parts of the nRF5 SDK used as well as that of the covered work.

If parts of the SDK are binary, you can't ask for the source code. :S

But none of the SDK parts used by JF are binary, right?

, or (at your option) any later version.

There's no way to predict what the next possible version could bring, I would be wary of adding that part.

That's true, but it's considered good practice to add it. If you don't, then the license will stay as it is for all eternity. Legal problems in the future may require adjustments. Just look at the many improvements in GPLv3 over GPLv2.

[Avamander]

@endian-albin

But none of the SDK parts used by JF are binary, right?

Maybe not at the moment, but it would be a pain to monitor.

That's true, but it's considered good practice to add it. If you don't, then the license will stay as it is for all eternity. Legal problems in the future may require adjustments.

Absolutely correct, but it's hard to know if GPLv4 will be made taken account the same principles and values. It might be totally fine, but it might not be and the license staying the same is a feature.

Just look at the many improvements in GPLv3 over GPLv2.

Yeah.

[JF002]

Wow, that's a lot of info to process!

But none of the SDK parts used by JF are binary, right?

I've moved from the SoftDevice to NimBLE precisely for this reason. The softdevice and its bootloader are closed-source and provided as a binary file. I can't think of any other binary parts in the code right now.

About the heart rate sensor and accelerometer:

Although the MPL would be more flexible and easier to apply perhaps, maybe it's still worth it to go for the GPL so as to encourage work on finding replacements to these blobs and non-free libraries that you mentioned? Maybe it would also encourage Pine64 to choose better components in the future...

That's an interesting point of view! Maybe we can try to contact the manufacturer of the chip and ask them to open-source these blob? I don't know, who knows... From what I understand, the lib for the HR sensor does the signal processing to convert raw values to heart rate values. I might be possible to design such algorithm by ourselves. The BLOB for the accelerometer seems to be needed to enable advanced function like step counting and activity detection. I think they are done in HW. Without this blob, we'll need to implement them is SW...

I said this on TG as well. but I think you should focus on protecting your own code and the values you deem fit.

Mhm what are my values? I use a lot of open-source SW, and I want to give my contribution to the community. I want the open-source community to be able to read the code, use it, modify it and contribute to it. Do I want proprietary software to use be able to use my code and make money out of it? I don't know. Is it a good thing? In all cases, I want them to contribute to the project if they modify the code. And I would like to do my best and comply to the license of the components I integrate in the project. Also, as some people have already contributed to the project, I want them to be able to give their opinion in this discussion :) Are there any other questions I should ask myself in order to choose the best license?

[endian-albin]

Although the MPL would be more flexible and easier to apply perhaps, maybe it's still worth it to go for the GPL so as to encourage work on finding replacements to these blobs and non-free libraries that you mentioned? Maybe it would also encourage Pine64 to choose better components in the future...

That's an interesting point of view! Maybe we can try to contact the manufacturer of the chip and ask them to open-source these blob? I don't know, who knows...

I already contacted Bosch in April about releasing the accelerometer. I'm still waiting for a response (ticket number 2020041593010742231).

From what I understand, the lib for the HR sensor does the signal processing to convert raw values to heart rate values. I might be possible to design such algorithm by ourselves.

Yep.

The BLOB for the accelerometer seems to be needed to enable advanced function like step counting and activity detection. I think they are done in HW. Without this blob, we'll need to implement them is SW...

I didn't know a blob was involved here. Do you have a reference?

I said this on TG as well. but I think you should focus on protecting your own code and the values you deem fit.

Mhm what are my values? I use a lot of open-source SW, and I want to give my contribution to the community. I want the open-source community to be able to read the code, use it, modify it and contribute to it. Do I want proprietary software to use be able to use my code and make money out of it? I don't know. Is it a good thing? In all cases, I want them to contribute to the project if they modify the code. And I would like to do my best and comply to the license of the components I integrate in the project. Also, as some people have already contributed to the project, I want them to be able to give their opinion in this discussion :) Are there any other questions I should ask myself in order to choose the best license?

I'm glad to hear that the community is the most important factor for you with this project. What's crucial from this point of view, is that you choose any free license (according to the FSF or Open source definition) so that code can be freely used and copied. It's very unfortunate to have source available but without any explicit rights to copy anything from it / using it in any other application, as it is right now, especially when you also encourage forks and accept contributions. Under what conditions can these contributions and forks be used? You'll need to ask every single contributor for releasing their code under a license or you might end up with creating a community around a non-free, "open source" project and that is certainly a dead-end.

[JF002]

I already contacted Bosch in April about releasing the accelerometer. I'm still waiting for a response (ticket number 2020041593010742231).

I was thinking about contacting them too, maybe with the help of Pine64 to give more weight to the request.

From what I understand, the lib for the HR sensor does the signal processing to convert raw values to heart rate values. I might be possible to design such algorithm by ourselves.

Yep.

We just need someone with HR signal processing knowledge to design this algo :)

I didn't know a blob was involved here. Do you have a reference?

A byte array must be send to the chip during the init sequence to enable advanced features like step counting. I have no idea what this byte array contains. The SDK calls it a "configuration file". Here is an example : https://github.com/sethitow/mbed-pinetime/blob/master/drivers/BMA42x_Accelerometer/bma421.c. Search for the variable 'bma421_config_file'.

I'm glad to hear that the community is the most important factor for you with this project. What's crucial from this point of view, is that you choose any free license (according to the FSF or Open source definition) so that code can be freely used and copied. It's very unfortunate to have source available but without any explicit rights to copy anything from it / using it in any other application, as it is right now, especially when you also encourage forks and accept contributions. Under what conditions can these contributions and forks be used? You'll need to ask every single contributor for releasing their code under a license or you might end up with creating a community around a non-free, "open source" project and that is certainly a dead-end.

Yes, it has always been my goal to release the code under an open source license. I haven't specified the license yet because I just don't know which one is the most appropriate.

The last propositions were:

• GPL : is the best for the open-source community. Any modification to the code must be released in GPL too. And if another manufacturer of smartwatch uses the code, he/she must release the firmware and allow the user to replace the firmware with another one.
  • LGPL is a bit less restrictive and allows the use of the code in another project without needed to release this another project as GPL/LGPL.
  • MPL seems quite similar to LGPL.

As the community is one of the most important value of the project, what do you think if we choose the GPL license? Any downside to this choice?

[JF002]

We had an interesting chat earlier today in the chat room about the licenses.

We were arguing about the GPL license. On one side, it the THE open-source license that protects the community and the user. On the other side, it is very restrictive, and could prevent many project/company from using and/or contributing to this project.

In the end, MPL seems a good compromise, but... I'm still not sure I would be able to explain exactly why MPL and not another one. I would like to be able to write the end of the sentence "I choose license XXX because ...".

[endian-albin]

An advantage of choosing the MPL 2.0 over the LGPL is its ease of use and its great compatibility with all the other important licenses, including the GPL. It does one simple thing: it prevents files under it to be made non-free. Other projects would not be forced to a complete relicensing of their code base to use such files.

[JF002]

@endian-albin good point!

[Avamander]

@endian-albin

its ease of use and its great compatibility with all the other important licenses

There are no software projects that would include this OS as a component though, so the compatibility in that direction doesn't really matter much. In the other direction, if you want modules/components built for the OS not to be restricted, something like Linux's syscall note would be required quite likely anways.

@JF002

and could prevent many project/company from using and/or contributing to this project.

I haven't seen a lot of that anyways to be quite honest, if a company does want to contribute GPL et al hasn't been a problem (e.g. in the case of Linux). I personally think GPLv3 (+ optionally "syscall"/API note) would be the best option for a project that strives for user freedoms on a hardware device and the few downsides aren't very relevant for a long while.

[JF002]

@Avamander If I understand correctly, this syscall/API note allows to build a new "application" based on the "core os" from this project? Even if in the end, both will be linked in the same binary?

[Avamander]

@JF002

this syscall/API note allows to build a new "application" based on the "core os" from this project?

It makes it absolutely clear that it's okay to write user(land) applications (watchapps) that call functions in the kernel, without forcing those watchapps themselves to be free software. It does not allow you to build the OS with proprietary components and distribute that.

[JF002]

For now, there is not a clear separation about what is the kernel, and what are the applications, and the whole project must be rebuild/relinked if you add or modify any part of the code. How can we define exactly was is considered as an app that call functions in the kernel, and what is a component that is part of the kernel?

[Avamander]

For now, there is not a clear separation about what is the kernel, and what are the applications, and the whole project must be rebuild/relinked if you add or modify any part of the code.

Then for now, there are no applications like that, the clause would not apply to anything and things compiled in must follow GPL.

It's really a thing that the OS will encounter in the future, the clause would just preemptively allow such things, exactly like Linux does now. Following in their footsteps, in a sense, I think would work just fine.

[JF002]

Over the last few days, I read as much as possible about different open source licenses.

I don't think LGPL would be useful in this case, as it is primarily made for libraries that are dynamically linkable. This project is, for now, a monolithic executable, where everything must be compiled/linked into a single executable.

As I've said before, I want this project to be an open-source project available to the community, and I hope the community will contribute to the code. With this idea in mind, I find MIT/Apache a too permissive, allowing anyone to use, modify and improve the code without having to contribute to the project.

MPL is very flexible, and maybe a bit too much? How to handle license if some files are licenses as MPL, other ones as proprietary,...

In the end, I have the feeling that GPL is much closer to the what I' trying to achieve: the project is open source, and anyone is free to use it, improve it, modify it, as long as she/he contribute back to the community. This is a strong guarantee that the project is and will always be open source.

What do you think about this? Do you agree with this? Do you think of anything that could prove the GPL to be a bad idea?

NOTE : I'm sorry this choice takes so much time. I take it very seriously, and I want to make the best choice possible!

[endian-albin]

Don’t forget to ask permission from all your contributors.

[JF002]

Thanks for the thumbs up! I'll keep this issue pending for a couple of days to let everyone interested give her/his opinion :)

[vilhelmgray]

I'm not sure how much this has been discussed already but I think it's worth mentioning since I don't see it in this thread already: https://en.wikipedia.org/wiki/License_proliferation

GPLv3 is incompatible with several popular open source licenses -- most notably the Apache License. I would highly recommend going with GPLv2 (without the "or later" wording) if you do settle on GPL because it's relatively more compatible than v3.

I also know it's controversial, but the tivozation clause in GPLv3 results in some deadly restrictions on what hardware this firmware can run on; this is one of the reasons Linus Torvalds is opposed to GPLv3: https://opensource.stackexchange.com/questions/7020/what-exactly-is-tivoization-and-why-did-linus-torvalds-not-like-it-in-gplv3

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, whereas if the code was licensed GPLv2 it would be fine. Since it looks like your concerns are more oriented towards ensuring that the source code remains free, I'd encourage the adoption of the GPLv2 license to avoid the hardware restrictions implied by the the GPLv3 license.

[Avamander]

I can envision users in the future wanting to distribute Pinetime firmware loaded in a device with hardware security features;

I see no good reasons not to let the user lock the device themselves. The anti-tivoization clause is exactly there to stop free code being made non-free via hardware locks.

[JF002]

@vilhelmgray That's an interesting comment! This project uses NimBLE BLE stack which is licensed under the Apache 2.0 license.

Do you mean that we cannot use NimBLE if we license the project under GPLv3?

After a quick search, I found this link : https://www.apache.org/licenses/GPL-compatibility.html. It says that GPLv2/v3 can include Apache code, but not the other way around : you cannot integrate GPLv2/v3 into an Apache derivative work.

[Avamander]

Do you mean that we cannot use NimBLE if we license the project under GPLv3?

We can use Apache, but they can't use GPL.

[vilhelmgray]

I can envision users in the future wanting to distribute Pinetime firmware loaded in a device with hardware security features;

I see no good reasons not to let the user lock the device themselves. The anti-tivoization clause is exactly there to stop free code being made non-free via hardware locks.

If I understand the anti-tivoization clause correctly, it would mean that I couldn't distribute the firmware in a ROM component because it's physically incapable of being changed. This means any device I build would need functionality to allow a user to load their own version; this dictates the kind of hardware I must use which restricts my freedom to install and distribute the firmware on any hardware I want.

Although we only have one Pinetime hardware right now, the open-hardware movement means some one can design their own Pinetime-compatible device. I think they should have the freedom to build it with chips and components that they want to use. Fundamentally, it doesn't make sense for a software license to dictate what hardware a user must have.

[JF002]

this dictates the kind of hardware I must use which restricts my freedom to install and distribute the firmware on any hardware I want.

The code restricts the hardware it needs to work correctly. It contains code specific to the nrf52, initializes devices on spi and i²c bus,.. You can modify the code so that it works on another hardware, of course.

I'm not sure if the anti-tiviozation clause specifies how the firmware should be replaced/updated. If your hardware does not support ble and/or provide an external spi flash memory, maybe you can design the hardware so that it's possible to update the firmware using a serial port or an external debugger. Do you think that would be compatible with the anti-tiovization clause?

[Avamander]

If I understand the anti-tivoization clause correctly, it would mean that I couldn't distribute the firmware in a ROM component because it's physically incapable of being changed.

Pretty much, yes.

This means any device I build would need functionality to allow a user to load their own version;

A programming header or OTA functionality would suffice.

this dictates the kind of hardware I must use which restricts my freedom to install and distribute the firmware on any hardware I want.

In some ways, yes, but at the same time the clause would forbid devices that restrict user freedoms.

Fundamentally, it doesn't make sense for a software license to dictate what hardware a user must have.

Firmware rather often does however. I am also very sceptical that it actually limits your choices, what MCU would this code run on that only has ROM?

[vilhelmgray]

This is just a hypothetical of course, but there are snippets of code that are useful for hardware that wouldn't necessarily need the entire source code of the original project. For example:

https://github.com/JF002/Pinetime/blob/b33ad9260026fce5d8d03080013eb96c3f7c3a3b/src/graphics.cpp#L103-L112

This is a pretty generic pixel draw routine that could work in a number of different applications that aren't related to Pinetime specifically. 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. With GPLv2, the source code is still required to be offered, so users can still benefit from see and modify the code. With GPLv3, such a device and such modified code would not even exist.

My argument isn't that tivoization is a good thing (I don't necessarily agree that it is), but GPLv3 severely limits hardware designs that would otherwise not be a problem; with GPLv2 those users would still have access to the source code and could build their own hardware and come up with new code that could even be contributed back to Pinetime.

[endian-albin]

@vilhelmgray That's an interesting comment! This project uses NimBLE BLE stack which is licensed under the Apache 2.0 license.

Do you mean that we cannot use NimBLE if we license the project under GPLv3?

After a quick search, I found this link : https://www.apache.org/licenses/GPL-compatibility.html. It says that GPLv2/v3 can include Apache code, but not the other way around : you cannot integrate GPLv2/v3 into an Apache derivative work.

The FSF has this to say about the Apache 2.0 license:

This is a free software license, compatible with version 3 of the GNU GPL. Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in that GPL version. These include certain patent termination and indemnification provisions. (https://www.gnu.org/licenses/license-list.en.html#SoftwareLicenses).

In other words, since this project integrates Apache 2.0-licensed works, only GPLv3 (or later) is compatible; GPLv2 is incompatible.

[vilhelmgray]

The FSF has this to say about the Apache 2.0 license:

This is a free software license, compatible with version 3 of the GNU GPL. Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in that GPL version. These include certain patent termination and indemnification provisions. (https://www.gnu.org/licenses/license-list.en.html#SoftwareLicenses).

In other words, since this project integrates Apache 2.0-licensed works, only GPLv3 (or later) is compatible; GPLv2 is incompatible.

Ah, that's a fair point. GPLv2 wouldn't be allowed in this case is seems then.