[riot-devel] From hwtimer to xtimer: What Changes for RIOT Features?
Hello everyone, As (I suppose) everybody here knows, the 'hwtimer' kernel feature has been replaced by the 'xtimer' module. Consequently, I'm wondering about some features that were specific to RIOT OS, and how they have evolved. More precisely, I have questions to ask: 1] Is RIOT OS kernel still *tickless*? The now gone 'hwtimer' that was in RIOT kernel only fired when an time-related event was actually happening---meaning there was no 'useless' wake-up (i.e.: simply related to the underlying timer frequency) where MCU was activated only to find that there was nothing to do and get back to low-power mode. That's why RIOT OS kernel could be qualified as tickless (no regular and potentially useless interrupt/wake-up). I see that xtimer, according to its documentation (Doxygen comments) is based on an unique hardware timer supposed to have a fixed 1 MHz frequency. Does it mean that there will be an interrupt every microsecond when 'xtimer' is used, or will we still have only an interrupt when a time-related event actually happens (which means RIOT still qualifies as a tickless OS) ? 2] Unless I'm mistaken, the 'hwtimer' feature that allowed to use as much 'hwtimer' instances (as the underlying hardware timers could offer counters/comparators is now gone, 'xtimer' being based on an unique (high-resolution) hardware timer onto which every 'xtimer' instance is multiplexed. Can someone confirm me that the previous statement---based on what I understand---is correct? 3] 'xtimer' is said to be based on a 1-MHz hardware timer, but does it mean we *really* have a granularity/jitter of the order of the microsecond? Dianel Krebs warned me (during the discussion on PR #4178) that xtimer_usleep() was dependent on the scheduler and the delay for its next context switch, and that consequently, the delay passed as a parameter could suffer for an undetermined and potentially *big* jitter. Is this problem specific to the sleep-related functions and their implementation, or does the whole 'xtimer' mechanism suffer from the same problem (i.e.: the xtimer_set[*,_msg,_wakeup]() functions)? In that case, what kind of jitter can we expect relative to the delays we pass as parameters to the xtimer functions? If this jitter is too high or too hard to predict, the status of RIOT OS as a real-time OS could be put in jeopardy? Since be able to have fine-grained real-time features is necessary to my work, can someone reassure me about the 'xtimer' module and its abilities? Thanks in advance to enlighten me: my job during this year didn't allow me to follow correctly the evolution of RIOT's timer mechanisms, and I quite need some technical details about the new low-level timers' inner workings. Best regards, -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] From hwtimer to xtimer: What Changes for RIOT Features?
Hello,
First, thanks to your quick reply, Hauke and Kaspar.
I indeed understood that these changes were made to enhance reliability
and code quality.
* For the tickless part, I am now totally reassured : a wake-up every
overflow is no big deal (at least for me in the current situation). RIOT
indeed still deserves to be defined as tickless---especially since
'xtimer' is a module, and not a kernel part like 'hwtimer'.
* I am looking into the 'xtimer' module code, and it probably should
suit my needs, if I use the callback mechanism efficiently.
My work is about having high-performance, adavanced MAC/RDC
protocols, that I have to implement into RIOT's netstack (have a look at
PRs #4178, #4180, #4184 and #4213). The granularity I need is in the
order of the tens of microseconds.
Actually, the 30.5 microsec. granularity 'hwtimer' offered on MSP430
(Telosb/Z1) platforms---as it is the length of their HW timer
"ticks"---was perfectly fine for my needs.
I will try to use 'xtimer' wisely, as your explanations make me
believe I will have (at least) a similar granularity.
If not, I will take a look into 'periph/timer', and maybe devise a
way to use it directly. Thanks a lot to both of you to pointing me to
that possible low-level solution.
Best regards, and see you,
Le 09/12/2015 13:50, Kaspar Schleiser a écrit :
Hey,
On 12/09/15 12:57, ROUSSEL Kévin wrote:
1] Is RIOT OS kernel still *tickless*?
Does it mean that there will be an interrupt every microsecond when
'xtimer' is used, or will we still have only an interrupt when a
time-related event actually happens (which means RIOT still qualifies as
a tickless OS) ?
("tickless" refers to the scheduler. That said:)
Well, in order to keep the notion of "time" for periods larger than a
timer register, xtimer has to wakeup whenever the timer register
overflows in order to count exactly those overflows. At 1MHz accuracy on
32bit timers, that's one tick every ~71minutes. On 16bit platforms, it's
more often.
I would still call that 'tickless' in the former case.
Also, there are plans to remove those wakeups if an RTC/RTT/slow low
power timer is present.
2] Unless I'm mistaken, the 'hwtimer' feature that allowed to use as
much 'hwtimer' instances (as the underlying hardware timers could offer
counters/comparators is now gone, 'xtimer' being based on an unique
(high-resolution) hardware timer onto which every 'xtimer' instance is
multiplexed.
Can someone confirm me that the previous statement---based on what I
understand---is correct?
Remember that xtimer provides multiplexing and wider-than-hardware-timer
periods on top of 'periph/timer'.
'periph/timer' can be used as replacement for hwtimer.
We replaced hwtimer (which abstracted timer hardware) and vtimer (which
provided multiplexing and long-term timers) with periph/timer and
xtimer. hwtimer had a "lifo queue", which we dropped in periph/timer to
keep that interface slim.
Together, they have a much more sane design:
periph/timer is the slimmest possible abstraction of the different
hardware timers that we could come up with.
xtimer adds the timer functionality needed in most systems, like
multiplexing, long term timers, LPM abstraction, convenience like
sending message, unlocking mutex, ...
They've been designed from the ground up, with the experience from
hwtimer/vtimer.
So while still young compared to hwtimer, I think the combination will
be better suited for all applications compared to the old code.
3] 'xtimer' is said to be based on a 1-MHz hardware timer, but does it
mean we *really* have a granularity/jitter of the order of the microsecond?
xtimer tries to offer a usable timer API that allows the use of natural
time values ("sleep 100 microseconds") on hardware that allows only
"sleep n timer ticks".
In order to simplify (and thus make more efficient) the implementation,
it assumes that the underlying hardware timer runs at 1MHz. (that will
change soon in some way).
If 1us accuracy is actually possible depends a lot on the hardware.
If you check the "timer_periodic_wakeup" example, you will see that on
most hardware (and depending on correct xtimer tuning values) the wakeup
is extremely periodic (when waking up every second, the jitter is less
than can be measured with the same timer).
native is a notable example, because when run under Linux, the acuracy
goes to hell.
A single timer might arrive a little (constant) time late. I've got a
patch to mitigate that (trigger timer a couple of microseconds early,
then spin before shooting).
xtimer as of now is only as exact as the underlying timer, so if 1*10^6
timer ticks are not 1sec, xtimer is doomed.
Dianel Krebs warned me (during the discussion on PR #4178) that
xtimer_usleep() was dependent on the scheduler and the delay for its
next context switch, and that consequently, the delay passed as a
parameter could suffer for an undetermined and
[riot-devel] Device ID feature in RIOT
Hello everyone, I just wanted to know if there was already a feature to determine a mote's unique ID (when available) in RIOT. Such a feature can be highly desirable when running a test on many devices (I think about IoT-LAB testbed, for example), to automatically assign/compute node addresses, or seed RNGs with numbers really specific to each device. If there is none, I can provide the one I have just built for my ongoing tests on IoT-LAB M3 motes: other users could then implement it for other motes later... Best, -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Device ID feature in RIOT
Hello, I've just made a branch with this. I'll PR it, so everyone can see what I mean. And indeed, I think it's related to #3221, since it would be way to have a seed (hopefully) unique for every mote/device. Regards, Le 19/06/2015 14:05, Emmanuel Baccelli a écrit : Hi Kevin On Fri, Jun 19, 2015 at 1:05 PM, ROUSSEL Kévin kevin.rous...@inria.fr mailto:kevin.rous...@inria.fr wrote: Hello everyone, I just wanted to know if there was already a feature to determine a mote's unique ID (when available) in RIOT. Such a feature can be highly desirable when running a test on many devices (I think about IoT-LAB testbed, for example), to automatically assign/compute node addresses, or seed RNGs with numbers really specific to each device. If there is none, I can provide the one I have just built for my ongoing tests on IoT-LAB M3 motes: other users could then implement it for other motes later... Thanks for the proposal. Can you give a brief sketch of your idea? I think this is related to https://github.com/RIOT-OS/RIOT/issues/3221 There were indeed some discussions about this some months ago, but I can't find a pointer to that. Anyone has some pointers to such discussions? Best Emmanuel -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] SAM R21 board
Hello everyone, I'm currently trying to test my developments on a pair of SAM R21 evaluation boards. Surprisingly, I just cannot manage to receive any packet on these devices... While the emitting and the receiving one are both sitting on my desk! Of course, I checked that both the boards have their transceiver on, run on the same 802.15.4 channel/frequency (which is easy to check and set with the 'default' example). Did anyone experience the same problem, or shall I assume that my hardware is failing?... Thanks in advance, -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] About function pointers
Hello Oleg, Le 18/02/2015 23:16, Oleg Hahm a écrit : Hi Kévin! I began to use function pointers in the 'radio_driver.h' when trying to create a unified model for radio drivers. I guess it went over later to the whole netdev effort. Yes, I remember that, but why can't this be implemented in a similar way we did for most of the peripheral drivers like SPI? Instead of calling a function pointer, we simply pass a struct describing the low-level device (driver) that should be used. This is more or less how Contiki actually works -- and what I planned to use in the 'radio_driver.h' mechanism : you use structs... But these structs ultimately contains function pointers. Of course, if this struct is 'const' -- and it *should* be -- it actually translates into a single indirect call in assembler (as I said before). My idea then was to have a fast, predictable call chain from the MAC layer to the physical radio transceiver functions: most MAC protocols expect to run with precise delays, and a mechanism relying on message between threads (like 'transceiver') did not fit that need. I completely agree on the point that we need to have direct function calls for MAC protocols (see also http://arxiv.org/abs/1502.01968). The model of driver as structs containing function pointers is the one used in Contiki: it seemed quite a natural way to handle the problem to me... In their code, the needed drivers are aliased as 'NETSTACK_xxx' macros, then functions are called by invoking 'NETSTACK_xxx.func()'. I think it is indeed one of the two natural solutions - the other one would be MACROing everything. I made experiences with both versions while developing on firmware for older sensor board platforms. And both had their drawbacks. Thus, when I started to work on what now is known as RIOT, I wanted to avoid Macros and a function pointer based abstraction layer model as much as possible. Of course, there are cases where either the one or the other will be the best solution, but I think we have to make sure to check if there are no alternative solutions that might work better on the long run. The const struct of function pointers seems actually cleaner and easier to understand IMHO. Macros in C can quickly turn into a mess if they are used too liberally. The only macros used in Contiki's netstack model is for choosing the used driver for a given layer. This seems clear enough to me; not to mention that Contiki is known for its efficiency to use constrained devices. As P. Nikander said, since you are supposed to know your hardware at compile time, these pointers are actually constants that should be resolved at compile (linking) time -- even with GCC. Theoretically, it should be translated by standard indirect calls at the assembler level. You name it: If everything is known at link time, then there is also always a way around function pointers. As I've written in the previous mail: I'd rather tell the compiler (or linker) how to do the stuff in an efficient way than hoping for the toolchain being smarter than me. Explicitly mentioning which drivers to use (thanks to simple macros like NETSTACK_xxx), in the board definition for the radio PḦY layer, and in the application Makefile for higher layers, seems quite simple and efficient IMHO... Could you tell us more about your previous experiments? It seems quite strange to me that such a mechanism (that seems simple to me) could impose speed and debugging penalties. I cannot disclose any code here, because it was proprietary code for my old company, but the problem was a layered one. We had a highly abstracted driver model, similar to Linux' one with char and block devices, abstracted serial line devices and the like. Thus, an application or any high level code accessing low-level drivers would be de-referenced multiple times. This made it incredible hard to debug (because you had to follow all the pointer de-referencing) and made it almost impossible to hold some strict deadlines for TDMA on our old MSP430F1612. OK I get the point: your former boss(es) wanted to have a high-level abstraction model, like in Linux. Well, this is like allocating memory at runtime for everything: a good practice on powerful hardware that (more importantly) includes a VMMU -- like our PCs --, but it becomes a chore on less powerful, MMU-less microcontrollers... As said before, I didn't think to variable function pointers allocated at runtime, but to the driver as a const struct of function pointers model. The other question is how could we implement the network stack? Using a mechanism like 'transceiver', that relies on message-passing between threads, implies that there is no predictable delay for executing network functions (one has to wait for the scheduler to switch to the thread(s) that execute(s) the feature(s) you want to use). At some levels -- like between MAC and PHY -- this can be a huge disadvantage. I think we can live with the overhead
Re: [riot-devel] About function pointers
Hello, I began to use function pointers in the 'radio_driver.h' when trying to create a unified model for radio drivers. I guess it went over later to the whole netdev effort. My idea then was to have a fast, predictable call chain from the MAC layer to the physical radio transceiver functions: most MAC protocols expect to run with precise delays, and a mechanism relying on message between threads (like 'transceiver') did not fit that need. The model of driver as structs containing function pointers is the one used in Contiki: it seemed quite a natural way to handle the problem to me... In their code, the needed drivers are aliased as 'NETSTACK_xxx' macros, then functions are called by invoking 'NETSTACK_xxx.func()'. I've never seen advanced dereferencing (-) nor object-oriented like constructs in that context. As P. Nikander said, since you are supposed to know your hardware at compile time, these pointers are actually constants that should be resolved at compile (linking) time -- even with GCC. Theoretically, it should be translated by standard indirect calls at the assembler level. Could you tell us more about your previous experiments? It seems quite strange to me that such a mechanism (that seems simple to me) could impose speed and debugging penalties. The other question is how could we implement the network stack? Using a mechanism like 'transceiver', that relies on message-passing between threads, implies that there is no predictable delay for executing network functions (one has to wait for the scheduler to switch to the thread(s) that execute(s) the feature(s) you want to use). At some levels -- like between MAC and PHY -- this can be a huge disadvantage. Is there a better way to obtain deterministic/direct API calls than using the struct of function pointers scheme ?... Regards, Le 18/02/2015 11:38, Oleg Hahm a écrit : Dear remodeling IoTlers! Ludwig just made me aware that Joakim's PR for NVRAM [1] introduces function pointers as part of the device driver struct. This made me remember that there were already similar function pointers introduced as part of netdev. As I was always opposed to use function pointers in that way, I could not recall what was the reason to use them for netdev. I don't like this pseudo object oriented C style (dev-write() and the like) because we made bad experiences with it at my former company. While writing the whole HAL for our firmware there using function pointers this way, made programming pretty convenient, it turned out to become problematic speed-wise and was a nightmare to debug. Hence, I would like to trigger a fundamental discussion on this topic. Does anyone has a particular opinion on the topic why function pointer based device drivers should be a good or a bad idea? And can anyone explain to me the need of function pointers for netdev? Cheers, Oleg [1] https://github.com/RIOT-OS/RIOT/pull/2353 ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] 'defalut' example on SAMR21 Xplained Pro
Hello everyone, Does the 'default' example work correctly on SAMR21 Xplained Pro? I compiled and flashed successfully this application on the Xplained Pro I have; but when doing 'make term', I just can't obtain any output from the board (via the same debug USB port I used to flash). Was anyone able to run this example successfully on the SAM R21, or there a known problem? Thanks, -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Suggested new platform for RIOT: calling for volunteers
Hello everyone, Since RIOT has been adapted to the AVR architecture, there is a chip that--I think--would be a great platform for development and production: the ATmega 256RFR2. The RFR2 family is presented here: http://www.atmel.com/devices/ATMEGA256RFR2.aspx but to sum it up, this MCU has the following advantages: - the well-known, low-power AVR 8-bit architecture - an integrated 802.15.4 transceiver, quite similar to the AT86RF231 - 256 Kb or Flash and, even better, 32 Kb of RAM (a huge amount for an 8-bit MCU!) - a complete set of integrated peripherals: the usual timers, PWM, UART, SPI, I2C, ADC, JTAG... as well as a some less common, very nice features like a true random number generator or a 32-bit symbol counter - it is available in a cheap starter kit board that is in itself a simple but functional mote with MCU, antenna socket, temperature sensor, and extension slots (see http://www.atmel.com/tools/ATMEGA256RFR2-XSTK.aspx) As such, it seems to make an ideal platform for future motes, and I think it is bound to be quite successful in the market. That's why I plan to make an extensive use of this device as soon as possible. As usual, I will start the port and try to have it up and running as fast as I can, but since I am now in the last year of my PhD, my time schedule is now really tight. Consequently, it will be extremely hard for me to push the porting effort further that the bare minimum (CPU and transceiver). It means that my code probably won't represent a clean, production-ready port by itself. Since running RIOT on this platform would benefit everyone in the community, it would be nice if I could receive help in this task; knowing that I will most likely be the first to use it, and as such feedback on the port is guaranteed. Thanks in advance, and best regards. -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] AVR platform maturity
Hello everyone, It's been a few months now since an AVR device (Arduino Mega) port has been available in RIOT. Does somebody use it regularly? I would like to try some developments on AVR, and I was wondering if AVR support was production-ready, or if there was still rough edges to aware of? Thanks in advance, -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Hello everyone, Maybe was it already envisioned, but another strategy would be dual licensing, something akin to what FreeRTOS does for example. Using this scheme: * we got (L)GPL by default, for academic contributors and everyone that has nothing against open-source; * the same code can be licensed under an alternative license for those that don't want to contribute back. Financial resources could even be drawn from this, as the project could charge for such a proprietary license. Of course, I guess this approach has its drawbacks; I was just citing a possible alternative, I have not really thought about it. Best regards, KR Le 12/12/2014 17:55, Emmanuel Baccelli a écrit : Hi Johann, Le 12 déc. 2014 00:48, Johann Fischer johann_fisc...@posteo.de mailto:johann_fisc...@posteo.de a écrit : Can you explain exactly what you expect of licence change? That more hardware will be supported? That RIOT will be more spread? The motivation for a more permissive license now is that the RIOT community has significantly more chances to spread and reach a critical mass fast enough to not let the current momentum go to waste. There might be other strategies to reach critical mass, but for now, none have been brought forward. Reaching critical mass is arguably an important goal. If the community does not reach this goal, it might not survive -- and none of us wants that. Thus this thread, to propose and discuss a strategy based on a license change allowing direct and indirect interactions with more industrial partners. I agree this strategy is not without potential drawbacks. Other strategy proposals are very welcome ;). My main point is: we need a strategy. Cheers, Emmanuel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Switch to BSD?
Hello again, As I said, I was just mentioning the possibility of dual-licensing. I never said it was the right thing to do, as I didn't really thought about it... The only thing I'm really afraid of are software patents, since these are visibly at the origin of many bad things (see the patents trolls and co in the US...) This is why I would personally prefer the Apache License--or any other license explicitly handling that problem--as the new solution. But to be honest, since I'm no lawyer, I think in fine I'll just follow the community's wisdom on that topic. Regards, KR Le 15/12/2014 11:52, Peter Kietzmann a écrit : Hi everyone, I'm sorry to hop in that late. To be honest, I didn't come to a final conclusion for myself, regarding the license-topic. Let me first say that I wouldn't boycott the change to BSD. Still I need to say that I have similar doubts like my previous speakers mentioned. One the one hand I do trust Emmanuel who indicated that there is a strongly need of this change to reach/hold companies that were interested in RIOT. Of course there have been good resonance from some of these comapnies. On the other hand I fear that BSD could lead to the situation that our work might be exploited by some companies and the primary idea of a wider propagation of RIOT will not take place, as one will not see the RIOT-background in every application. Regarding a the dual licensing I didn't understand the real concept behind it maybe, but I can not see in which way this avoids the mentioned doubts. What I see is an additional overhead of workload. Best regards, Peter K. Am 15.12.2014 um 11:10 schrieb Ludwig Ortmann: Hi, All in all, dual licensing is an interesting thought, but I'm afraid it inevitably leads to extra work and frustration. Because the users of the commercial branch will most likely be a major contributer of resources, the free branch would end up being treated as a second class citizen. (Please refer me to examples where this has not been the outcome if they exist.) As for the general topic of relicensing: I would wish for a license with patent clauses for Christmas. But such a clause is supposed to scare the big company lawyers away. So, a switch to Apache would probably not help with the goal of getting big companies to consider RIOT. Personally, I'm not convinced these companies are really needed for RIOT to stay alive. In order to cater to commercial use *today* (because we don't currently have tools to help satisfy the linking clause of the LGPL), I'd rather add a static linking exception to our current license (or switch to GPL with linking exception which amounts to the same as far as I remember). I am aware that this probably makes the license even more troublesome for the lawyers in question as it would probably need extra ratification, but it would help smaller companies. One aspect of this rationale is that we currently have several interested smaller companies, while the big companies could as well implement the missing bits themselves. That being said I would also be excited to see some bigger company contribute to RIOT. If switching to MIT is what it takes to achieve this, I'm fine with it. Cheers, Ludwig On Mon, Dec 15, 2014 at 09:51:13AM +0100, ROUSSEL Kévin wrote: Hello everyone, Maybe was it already envisioned, but another strategy would be dual licensing, something akin to what FreeRTOS does for example. Using this scheme: * we got (L)GPL by default, for academic contributors and everyone that has nothing against open-source; * the same code can be licensed under an alternative license for those that don't want to contribute back. Financial resources could even be drawn from this, as the project could charge for such a proprietary license. Of course, I guess this approach has its drawbacks; I was just citing a possible alternative, I have not really thought about it. Best regards, KR Le 12/12/2014 17:55, Emmanuel Baccelli a écrit : Hi Johann, Le 12 déc. 2014 00:48, Johann Fischer johann_fisc...@posteo.de mailto:johann_fisc...@posteo.de a écrit : Can you explain exactly what you expect of licence change? That more hardware will be supported? That RIOT will be more spread? The motivation for a more permissive license now is that the RIOT community has significantly more chances to spread and reach a critical mass fast enough to not let the current momentum go to waste. There might be other strategies to reach critical mass, but for now, none have been brought forward. Reaching critical mass is arguably an important goal. If the community does not reach this goal, it might not survive -- and none of us wants that. Thus this thread, to propose and discuss a strategy based on a license change allowing direct and indirect interactions with more industrial partners. I agree this strategy is not without potential drawbacks. Other strategy proposals are very welcome ;). My main point is: we need a strategy. Cheers
Re: [riot-devel] Switch to BSD?
Hello, I'm not absolutely against licence switch but... I actually feel uneasy about about this kind of demands... If I understand right, some corporations which have probably contributed nothing to the project just barges in and said : if you want us to use your work, you have to let us make whatever we want with it, ask nothing in return, no code contribution, no financial help (since this is free software), nothing. To be honest, I find this kind of behavior quite... displaced. If I'm not mistaken, LGPL absolutely doesn't impose anything on the applications made with RIOT OS, only that changes made *into* the OS are contributed back. How could that harm a business that use RIOT (at not cost, remember) to build its solution? Of course, I'm no specialist, maybe there something I'm missing here, but... Moreover, with that software patent crap that flourishes almost everywhere out of EU (and maybe even here in the future), wouldn't that change make us vulnerable to being sued for just developing our own code? As Rene Kijewski said, if we must change, we should find a license that protects us from that kind of trap... Of course, it's good to broaden RIOT community, but what kind of members will be attracted by that kind of move? I can just wonder. Best regards, KR PS: sorry for my lack of contribution these last weeks, I'm finishing some paper submissions, and will be able to get back with some interesting element soon. Le 03/12/2014 22:59, Emmanuel Baccelli a écrit : Dear RIOTers, we have been receiving an increasing amount of negative feedback from various companies concerning the practical usability of our LGPL license in their context, being a show-stopper. For this reason, INRIA, Freie Universitaet (FU) Berlin and Hamburg University of Applied Science (HAW) are currently considering changing the license of their contributions to RIOT to a less restrictive license (i.e. BSD, potentially as soon as next release). Such a switch to BSD is betting that the effect of a potentially smaller percentage of user/devel contributing back to the master branch will be dwarfed by the effect of a user/devel community growing much bigger and quicker. This seems doable considering the current momentum around RIOT. In a second phase, if such a license switch takes place for INRIA/FU/HAW contributions, we would then contact other contributors individually, to check their status concerning a similar switch for their own contributions. But in the first place, we would like to debate this topic. In particular: is anyone violently opposing the idea of migrating to a less restrictive license, such as BSD? If so, why? On the other hand, if you explicitly support the license change, feel free to indicate this as well. Please send your opinion to the list before Dec. 10th. Cheers, Emmanuel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
