Hello everyone,
since I am no specialist at all when it comes to SW licenses, I'd like to hear somebody else opinion on the attached license file.
Do I read it correctly, that it should be no problem to include files with this header into RIOT?
Cheers, Hauke
Hey!
since I am no specialist at all when it comes to SW licenses, I'd like to hear somebody else opinion on the attached license file.
Do I read it correctly, that it should be no problem to include files with this header into RIOT?
Since this topic is hot again (see PR #1191 and #1291 - nice numbers by the way), I think we should clarify this.
Actually, I'm afraid that René might be right in this case and the sentence "for the sole and exclusive purpose of developing versions of such Licensed Software only for use within the Product" might indeed conflict with the LGPL that requires no restrictions for the use of the software at all. Agreed, that it doesn't make sense to use this code with any non-STM hardware, but unfortunately making sense does not always help in a legal conflict.
Both PRs include only one C file under this license. Maybe we can avoid any trouble here by just replacing the file with a variant from libopencm3?
Cheers, Oleg
Hey!
> since I am no specialist at all when it comes to SW licenses, I'd like > to hear somebody else opinion on the attached license file. > > Do I read it correctly, that it should be no problem to include files > with this header into RIOT?
Since this topic is hot again (see PR #1191 and #1291 - nice numbers by the way), I think we should clarify this.
Actually, I'm afraid that René might be right in this case and the sentence "for the sole and exclusive purpose of developing versions of such Licensed Software only for use within the Product" might indeed conflict with the LGPL that requires no restrictions for the use of the software at all. Agreed, that it doesn't make sense to use this code with any non-STM hardware, but unfortunately making sense does not always help in a legal conflict.
Both PRs include only one C file under this license. Maybe we can avoid any trouble here by just replacing the file with a variant from libopencm3?
Hi,
yes we can if you want, see my mail from 19.05.2014. I use it alredy. We can integrate libopencm3 to RIOT or adopt the core functions (and then we would have the support of several boards). Is there plan or design for a hal?
Greetings
Johann Fischer
P.S. Why is the list not to be used for discussions, not everyone can come to meeting and Skype is no solution.
Hi Johann,
Hey!
since I am no specialist at all when it comes to SW licenses, I’d like to hear somebody else opinion on the attached license file.
Do I read it correctly, that it should be no problem to include files with this header into RIOT?
Since this topic is hot again (see PR #1191 and #1291 - nice numbers by the way), I think we should clarify this.
Actually, I’m afraid that René might be right in this case and the sentence “for the sole and exclusive purpose of developing versions of such Licensed Software only for use within the Product” might indeed conflict with the LGPL that requires no restrictions for the use of the software at all. Agreed, that it doesn’t make sense to use this code with any non-STM hardware, but unfortunately making sense does not always help in a legal conflict.
Both PRs include only one C file under this license. Maybe we can avoid any trouble here by just replacing the file with a variant from libopencm3?
Hi,
yes we can if you want, see my mail from 19.05.2014. I use it alredy. We can integrate libopencm3 to RIOT or adopt the core functions (and then we would have the support of several boards). Is there plan or design for a hal?
Greetings
Johann Fischer
P.S. Why is the list not to be used for discussions, not everyone can come to meeting and Skype is no solution.
This list is indeed used for discussion. These discussions are completed by periodical meetings (we organize them so that telepresence is possible). So feel free discuss on this list and/or to participate remotely in periodical meetings!
Best
Emmanuel
Hi Johann,
yes we can if you want, see my mail from 19.05.2014. I use it alredy. We can integrate libopencm3 to RIOT or adopt the core functions (and then we would have the support of several boards).
if I remember correctly, Hauke and Stefan evaluated libopencm3 and came to the conclusion that it has some flaws, too. So, we decided not to use any thirdparty libraries and implement the necessary stuff on our own. Still for some defines and basic initialization stuff, there's some STM32 code included and my question was if it might be possible to remove just this stub with libopencm3 code.
Is there plan or design for a hal?
What exactly do you mean when you talk about HAL? I personally think that anything more complex than just a clean interface through header files is too much overhead.
P.S. Why is the list not to be used for discussions, not everyone can come to meeting and Skype is no solution.
Well, I think there are things that are much easier to discuss face-to-face or via Skype (that's the reason for regular meetings). But you're right, we should try to be as inclusive as possible.
Cheers, Oleg
Hi Johann,
> yes we can if you want, see my mail from 19.05.2014. > I use it alredy. We can integrate libopencm3 to RIOT or adopt the core > functions (and then we would have the support of several boards).
if I remember correctly, Hauke and Stefan evaluated libopencm3 and came to the conclusion that it has some flaws, too. So, we decided not to use any thirdparty libraries and implement the necessary stuff on our own. Still for some defines and basic initialization stuff, there's some STM32 code included and my question was if it might be possible to remove just this stub with libopencm3 code.
How much time did it take you to bring STM32 board to run? What works? With libopencm3, for example with two threads and UART, I needed a few hours. If you want to replace some STM32 code (and tomorrow nRF51 code, or TM4C12x) with libopencm3 code, why not take everything that's missing or fits?
> Is there plan or design for a hal?
What exactly do you mean when you talk about HAL? I personally think that anything more complex than just a clean interface through header files is too much overhead.
What about I2C, SPI, USB? (But that's OT).
Greetings
Johann Fischer
Hi Johann,
Hi Johann,
yes we can if you want, see my mail from 19.05.2014. I use it alredy. We can integrate libopencm3 to RIOT or adopt the core functions (and then we would have the support of several boards).
if I remember correctly, Hauke and Stefan evaluated libopencm3 and came to the conclusion that it has some flaws, too. So, we decided not to use any thirdparty libraries and implement the necessary stuff on our own. Still for some defines and basic initialization stuff, there's some STM32 code included and my question was if it might be possible to remove just this stub with libopencm3 code.
How much time did it take you to bring STM32 board to run? What works? With libopencm3, for example with two threads and UART, I needed a few hours. If you want to replace some STM32 code (and tomorrow nRF51 code, or TM4C12x) with libopencm3 code, why not take everything that's missing or fits?
The actual time to get the STM board to run wasn't too bad, maybe little more then some hours, but nothing that took forever - the delay for getting the boards into master was more caused by not continuously working on the port...
I personally see 2 huge and 1 not so big reasons why not to libopencm3 as default: 1) I found on my last evaluation, that the lib is not complete and that the interfaces varies in some aspects between boards 2) libopencm3 only supports ARM Cortex-M platforms - RIOT in contrary supports a wider range of uC families, MSP430, ARM7 and even Atmel ATMega coming up. The low-level driver interface is designed to provide a simple to use, consistent and clean interface to the hardware peripherals, independent of the CPUs architecture 3) Last and most important: the driver interface in it's current form beats libopencm3 in terms of memory usage and code size.
Is there plan or design for a hal?
What exactly do you mean when you talk about HAL? I personally think that anything more complex than just a clean interface through header files is too much overhead.
RIOT/drivers/include/periph at master · RIOT-OS/RIOT · GitHub What about I2C, SPI, USB? (But that's OT).
Its all planned but mostly not implemented yet, see PR #1311 for example.
So overall I would opt for not using libopencm3 as default for any port but make it as a package with subsequent Makefiles in /pkg so that anyone, who would like to use it in their projects can use it. So don't get me wrong, I am not completely against using libopencm3, I just don't like it as a default.
Cheers, Hauke