You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code in stm/lib comes from the STM32F4xx standard peripheral library, v1.1.0. I'm not sure about the license for this, and whether or not we can have it in the repo. Need to work out the situation, and how to deal with this.
I believe all you need to do is put the copyright of this code in your license. They grant you use and modification rights but don't transfer ownership to you. So I think you're okay by adding this to your LICENSE-
stm libraries in stm/lib are COPYRIGHT 2013 STMicroelectronics. Licensed under MCD-ST Liberty SW License Agreement V2 which can be found here-
* Licensed under MCD-ST Liberty SW License Agreement V2, (the "License");
* You may not use this file except in compliance with the License.
* You may obtain a copy of the License at:
*
* http://www.st.com/software_license_agreement_liberty_v2
Product: means Your and Your’s end-users’ product or system, and all the related documentation, that includes or incorporates the Licensed Software and provided further that such Licensed Software or derivative works of the Licensed Software execute solely
and exclusively on microcontroller devices manufactured by or for ST.
That's already not Open Source. And now consider case of cross-device software. The license above literally says that if you use their source that you must develop only for STM devices. Yes, that just one possible interpretation, it makes no sense and complete b/s, but it means that some lawyer in some court may interpret it just like that.
You acknowledge and agree that any use, adaptation, translation or transcription of the
Licensed Software or any portion or derivative thereof, for use with processors manufactured by or for an entity other than ST is a material breach of this Agreement and requires a separate license from ST.
Here we go again, up and high. Does lying around in source code repository alongside similarly bullshit-licensed source from TI, Freescale, NXP, etc. with the ability of the entire source code product to be compiled for competing devices construes "any use"?
That's the situation in embedded development. Even initial attempts to change that (kudos to ARM) are awkward:
What to do now? Have this ticket around ;-). Ideally, it would be nice to move STM's code to a submodule, but there're more useful things to do now than try to accommodate all this b/s.
I think you're reading too much in this license. The 'Licensed Software' is the code in stm/lib. There is no clause that changes the license of micropython. Since this code is used in the stm portion of the code to build stm products I don't see a problem with it just staying there. In the future when other micro controllers are added either code from that manufacture will be used or a new HAL layer to encompass all micro controllers can be created. As long as the 'Licensed Software' (read the code that STM provides) is not used to derive a HAL for other micro controllers then it perfectly okay.
AFAIK, the MIT license doesn't restrict adding non-open source code to a project. Neither does it modify the license of non open source either.
There is no clause that changes the license of micropython.
There is no.
I think you're reading too much in this license.
I'm applying conservative ("everything which can be considered to be user's fault is user's fault") reading of what's written there. Hopefully you agree that there're enough ambiguity and loopholes in that wording.
AFAIK, the MIT license doesn't restrict adding non-open source code to a project.
Yes, but a project which has both opensource and non-opensourse code as a whole is NOT opensource. And obvious way to resolve that situation is to move away non-opensource code somewhere else.
I don't see any ambiguity. When building a product for the stm micro controllers, the code would include the stm/lib code and therefore would have to only run on a stm microprocessor as per the license. If micro python is ported to another micro controller, it would not include the stm 'Licensed Software' therefore could not even remotely be considered a derivative of the work, therefore their license doesn't apply.
I think including the STM license as I described satisfies both the copyright holder (STM) and any open source enthusiasts. The freedom is there for anyone to remove the stm licensed code and substitute others.
This is last time I'm showing you the ambiguity and loophole. I'm not a lawyer, and you can consult with one to get an opinion on what's plausible and what's not (only court can have authoritative decision). Myself, interested more in hacking.
If micro python is ported to another micro controller, it would not include the stm 'Licensed Software' therefore could not even remotely be considered a derivative of the work, therefore their license doesn't apply.
And yet here's MicroPython software: https://github.com/micropython/micropython . It's publicly available, so court can invite unlimited number of experts which will swear on bible that what's there is indeed MicroPython software. And here's where it includes STM-licensed software https://github.com/micropython/micropython/tree/master/stm/lib (experts will confirm it indeed includes). So, if said software is still in this state when said software supports other manufacturers' microcontrollers, then you're in breach of STM license, and at least lose right to use said software with STM-licensed software.
The whole idea of OpenSource licenses is that they protect their users from such b/s scenarios. And STM license vice-versa makes it possible. That's why STM license is not open source, and contaminates opensource projects (by subjecting users to liability which true opensource projects would not).
For the record, the stmhal/ port now has an MIT-style license for the STM Cube HAL layer. Only thing that has remained as the original license is the usb driver (which we are using).
That's great progress. Any thoughts on future fate of "stm" port. If "stmhal" truly supersedes it, might be a good idea to remove it in some time, to cut most of the above controversy.
Ok, stm/ was removed some time ago. Does everyone agree that we should be reasonably safe against http://www.phoronix.com/scan.php?page=news_item&px=MTczNDU and can close this now (is there any STM file in the codebase w/o explicit BSD license)?
Is this still an issue? There seems to be pretty clear copyright/license headers for STMicroelectronics in the relevant parts of the code in the MicroPython repository?
Activity
hagenkaye commentedon Jan 1, 2014
The license-
http://www.st.com/st-web-ui/static/active/en/resource/legal/legal_agreement/license_agreement/software_license_agreement_liberty_v2.pdf
I believe all you need to do is put the copyright of this code in your license. They grant you use and modification rights but don't transfer ownership to you. So I think you're okay by adding this to your LICENSE-
stm libraries in stm/lib are COPYRIGHT 2013 STMicroelectronics. Licensed under MCD-ST Liberty SW License Agreement V2 which can be found here-
http://www.st.com/software_license_agreement_liberty_v2
pfalcon commentedon Jan 1, 2014
stm324x7i_eval.c:
There's no such license in http://opensource.org/licenses .
http://www.st.com/software_license_agreement_liberty_v2 :
That's already not Open Source. And now consider case of cross-device software. The license above literally says that if you use their source that you must develop only for STM devices. Yes, that just one possible interpretation, it makes no sense and complete b/s, but it means that some lawyer in some court may interpret it just like that.
Here we go again, up and high. Does lying around in source code repository alongside similarly bullshit-licensed source from TI, Freescale, NXP, etc. with the ability of the entire source code product to be compiled for competing devices construes "any use"?
That's the situation in embedded development. Even initial attempts to change that (kudos to ARM) are awkward:
So, good open-source response is "f$%^ off", and that's why projects like https://github.com/pfalcon/cortex-uni-startup , https://github.com/pfalcon/libperipha (shameless plug), http://libopencm3.org/ , etc exist.
What to do now? Have this ticket around ;-). Ideally, it would be nice to move STM's code to a submodule, but there're more useful things to do now than try to accommodate all this b/s.
hagenkaye commentedon Jan 1, 2014
I think you're reading too much in this license. The 'Licensed Software' is the code in stm/lib. There is no clause that changes the license of micropython. Since this code is used in the stm portion of the code to build stm products I don't see a problem with it just staying there. In the future when other micro controllers are added either code from that manufacture will be used or a new HAL layer to encompass all micro controllers can be created. As long as the 'Licensed Software' (read the code that STM provides) is not used to derive a HAL for other micro controllers then it perfectly okay.
AFAIK, the MIT license doesn't restrict adding non-open source code to a project. Neither does it modify the license of non open source either.
pfalcon commentedon Jan 1, 2014
There is no.
I'm applying conservative ("everything which can be considered to be user's fault is user's fault") reading of what's written there. Hopefully you agree that there're enough ambiguity and loopholes in that wording.
Yes, but a project which has both opensource and non-opensourse code as a whole is NOT opensource. And obvious way to resolve that situation is to move away non-opensource code somewhere else.
hagenkaye commentedon Jan 1, 2014
I don't see any ambiguity. When building a product for the stm micro controllers, the code would include the stm/lib code and therefore would have to only run on a stm microprocessor as per the license. If micro python is ported to another micro controller, it would not include the stm 'Licensed Software' therefore could not even remotely be considered a derivative of the work, therefore their license doesn't apply.
I think including the STM license as I described satisfies both the copyright holder (STM) and any open source enthusiasts. The freedom is there for anyone to remove the stm licensed code and substitute others.
pfalcon commentedon Jan 2, 2014
This is last time I'm showing you the ambiguity and loophole. I'm not a lawyer, and you can consult with one to get an opinion on what's plausible and what's not (only court can have authoritative decision). Myself, interested more in hacking.
And yet here's MicroPython software: https://github.com/micropython/micropython . It's publicly available, so court can invite unlimited number of experts which will swear on bible that what's there is indeed MicroPython software. And here's where it includes STM-licensed software https://github.com/micropython/micropython/tree/master/stm/lib (experts will confirm it indeed includes). So, if said software is still in this state when said software supports other manufacturers' microcontrollers, then you're in breach of STM license, and at least lose right to use said software with STM-licensed software.
The whole idea of OpenSource licenses is that they protect their users from such b/s scenarios. And STM license vice-versa makes it possible. That's why STM license is not open source, and contaminates opensource projects (by subjecting users to liability which true opensource projects would not).
dpgeorge commentedon Jan 2, 2014
Hmmm, tricky stuff (or not, if you just go open source the whole way).
How are others dealing with this? Espruino seems to have just included everything: https://github.com/espruino/Espruino/tree/master/targetlibs/stm32f4/lib .
Like @pfalcon I'd rather be coding, but this stuff is important.
At worst we have to create a separate repo with the STM port.
hagenkaye commentedon Jan 3, 2014
eLua includes everything as well-
https://github.com/elua/elua
And they have lumped all the different platforms for different manufacturers (including stm) in one directory-
https://github.com/elua/elua/tree/master/src/platform
dpgeorge commentedon Mar 30, 2014
For the record, the stmhal/ port now has an MIT-style license for the STM Cube HAL layer. Only thing that has remained as the original license is the usb driver (which we are using).
pfalcon commentedon Mar 31, 2014
That's great progress. Any thoughts on future fate of "stm" port. If "stmhal" truly supersedes it, might be a good idea to remove it in some time, to cut most of the above controversy.
dpgeorge commentedon Mar 31, 2014
Yes, I'd remove stm/, but I think some people are still using it.
dhylands commentedon Mar 31, 2014
Perhaps rename it to stm-obsolete for a couple months and then remove it?
pfalcon commentedon Jul 20, 2014
Ok, stm/ was removed some time ago. Does everyone agree that we should be reasonably safe against http://www.phoronix.com/scan.php?page=news_item&px=MTczNDU and can close this now (is there any STM file in the codebase w/o explicit BSD license)?
dpgeorge commentedon Jul 20, 2014
ST's USB drivers are not BSD style. See eg https://github.com/micropython/micropython/blob/master/stmhal/usbdev/core/src/usbd_core.c
pfalcon commentedon Jul 20, 2014
I see, then let's keep this open as a live warning.
2 remaining items
Powerup (micropython#26)
Merge pull request micropython#26 from adafruit/main
Merge pull request micropython#26 from kwagyeman/openmv
jonnor commentedon Jul 2, 2024
Is this still an issue? There seems to be pretty clear copyright/license headers for STMicroelectronics in the relevant parts of the code in the MicroPython repository?
dpgeorge commentedon Jul 3, 2024
Yes you're right. And we now have the non-MIT licenses of all third party code listed in the top-level LICENSE file as a notice for all users.
nrf: Add new port to Nordic nRF5x MCUs.
nrf: Add new port to Nordic nRF5x MCUs.