License #22
Comments
|
Do you have any to recommand? |
|
You could keep it MIT licensed like LittleVGL? But personally I would just GPL it. Version 3 or later. |
|
MIT or Apache are the most flexible, |
|
See also https://choosealicense.com/, the appendix has a comparison: https://choosealicense.com/appendix/ |
|
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. |
@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. |
|
@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. |
@endian-albin I consider just having the code out in the open helping, and it allows things like custom ROMs to be made. |
|
I had an interesting discussion on the chat about licenses the other day. I'm still wondering if I should choose GPLv3 or LGPLv3... |
|
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). |
|
Still not decided ? |
|
Mhm I put this on the side to think about it and kind of forgot about it. Ok, here is a summary of what I understand:
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? |
|
@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. |
|
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:
Both the LGPL and GPL require reverse engineering to be allowed so this is a problem. From the LGPL license text:
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. |
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. |
|
@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:
|
|
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. |
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. |
|
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:
|
|
@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
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). So, for now, we are talking about GPL, LGPL and MPL. What do you think? |
|
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. |
|
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. |
There is a discussion about getting the accelerometer to work using only Free Software so in this case I think blobs can be avoided.
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.
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. |
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).
If parts of the SDK are binary, you can't ask for the source code. :S
There's no way to predict what the next possible version could bring, I would be wary of adding that part. |
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.
But none of the SDK parts used by JF are binary, right?
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. |
Maybe not at the moment, but it would be a pain to monitor.
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.
Yeah. |
|
Wow, that's a lot of info to process!
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:
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...
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. |
I already contacted Bosch in April about releasing the accelerometer. I'm still waiting for a response (ticket number 2020041593010742231).
Yep.
I didn't know a blob was involved here. Do you have a reference?
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. |
I was thinking about contacting them too, maybe with the help of Pine64 to give more weight to the request.
We just need someone with HR signal processing knowledge to design this algo :)
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'.
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:
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? |
|
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! |
|
Don’t forget to ask permission from all your contributors. |
|
Thanks for the thumbs up! I'll keep this issue pending for a couple of days to let everyone interested give her/his opinion :) |
|
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. |
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. |
|
@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. |
We can use Apache, but they can't use GPL. |
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. |
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,.. 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? |
Pretty much, yes.
A programming header or OTA functionality would suffice.
In some ways, yes, but at the same time the clause would forbid devices that restrict user freedoms.
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? |
|
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: 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. |
The FSF has this to say about the Apache 2.0 license:
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. |
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. |
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. |
@vilhelmgray, you should actually read the license instead of spreading FUD. I quote directly from the GPLv3 license, section 6:
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. |
|
I was mistaken, it looks like ROM is not affected by this clause then. |
|
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. |
Huh, don't know how I've missed that. Thanks for informing me/us. |
|
Thanks for all these details! So, we are still good to go with the GPLv3? |
|
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. |
|
Yes, but I see two related issues that should also be resolved:
My own answers to these questions:
|
|
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. |
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.
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. |
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.
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. |
Nah, not really forever and that's really not needed either.
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.
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. |
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.
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?
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:
I still think the standard "or, at your option, any later version" is the way to go though. |
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.
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+? |
|
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 :) |
Could you please add a license to this project?
The text was updated successfully, but these errors were encountered: