If you actually had any intentions to contribute to RIOT, then you would dual or tri-license your contributions ...
You cannot use any of my contributions under any BSD license, because I don't think that it is a logic choice. I would welcome Apache v2.0, and would think about MIT, but there is actually nothing that speaks in favor of BSD.
Sorry Adam, I don't know how your name got intermixed into my answer. I had no intention to misquote you, and I like your previous letter very much.
Hi Carsten,
on the topic of rewriting history 
it would be interesting to know if you have an estimation of the proportion of RIOT code your people would have developed that would have been contributed back to the master branch, over the last 1,5+ years, taking into account the constraints of your customers over that period of time? (assuming RIOT code was, say, MIT licensed).
Best,
Emmanuel
Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> writes:
Hi Carsten, on the topic of rewriting history
it would be interesting to know if you have an estimation of the proportion of RIOT code your people would have developed that would have been contributed back to the master branch, over the last 1,5+ years, taking into account the constraints of your customers over that period of time? (assuming RIOT code was, say, MIT licensed).
Hi Emmanuel,
this would be a more useful question if I were the only person on earth who looks at licensing issues before adopting some technology. I can assure you I'm not.
But to answer the question anyway: Honestly, I don't know. I don't know because, without a reasonable platform, we simply did not procure work in this space. On the university side, the work on ccast (draft-bergmann-bier-ccast) might have gone into RIOT instead of Contiki (unfortunately, the hacks we needed to make this work in Contiki are probably too gross to make it back into mainline there). I also know that I could have steered the student project that started in October towards something that uses RIOT, and I didn't (they now have a different subject). We had some other ideas in 2013 that would have benefitted from RIOT that we didn't pursue because we didn't have a suitable platform. On the company side, there was a potential opportunity in the summer of this year that we let pass, but that was a somewhat longer shot.
So, it could have been substantial, or it could have been trivial. What I was aiming at with my throwaway comment was that there are lots of opportunities withering on the vine, and aggressively waiting (for what?) is not the bold move that will remove this roadblock.
Gruesse, Carsten
Carsten Bormann <cabo@tzi.org> writes:
On the university side
To second that: I have been considering switching to RIOT as the major development platform for at least a year now. Although the license is not the major concern hesitating, it is this sort of ever-ongoing discussions that makes me always feel a bit uncertain which direction this platform will take in the future.
Grüße Olaf
I agree with you: we need "another Linux" and not "another Contiki". But two questions: (1) can we realistically mimic the Linux story and stay with LGPL? (2) why would RIOT necessarily become "another Contiki" if the license evolves to BSD/MIT?
Concerning (1): what does our experience from the last year show? That LGPL is far from a perfect solution, because too many company lawyers cannot deal with it. On the other hand, we know that BSD/MIT also has its down sides. So we have to trade-off between the "dangers of BSD/MIT" and the "dangers of LGPL". There is no perfect solution, I agree. But still, we have to make a choice.
On one hand, if we do not change the license, we can force people to do things our way, and it has indeed moral value. But it's difficult to force people/companies to do things. Those who do not want to, or cannot, "give back" will simply not use RIOT in the first place -- hence a much slower adoption that looks like a potentially fatal problem in the short term.
If we change the license, some people/companies could indeed fork and close their source, and that is not what we want. However, these people will use RIOT and have a chance to change their mind about contributing back -- when they realize the burden of rebasing their code all the time. The bet is that the momentum in the community will remain sufficiently attractive to aggregate enough contributions to thrive in the mid-term.
Hello Emmanuel, sorry for late reply. The company where I work develops and produces embedded boards and makes the portings of linux kernel. We know the advantages and disadvantages of (L)GPL. We spend time and money to porting linux to our boards because we want to sale hardware and our customers benefit from it.
What is the most unclear to me is: what are the consequences of the choice of license in the long run?
Can you explain exactly what you expect of licence change? That more hardware will be supported? That RIOT will be more spread? There are also companies that have made the ports for contiki but will only give the porting for the hardware back to the project, but not the improvements of core (I can not say more).
However, one thing is for sure: this question is irrelevant if we're out in the mid-term.
The value of an open source community is equally (i) the quality of the code base it provides and (i) the liveliness of the community. So concerning (2), do you think BSD/MIT would:
- harm the RIOT community?
-yes, not everyone will agree with the change.
- harm the RIOT code base?
-no, but I think it will not improve the code base.
If so how, and at which stage (short, mid long term), and how bad? Is it worse the risks of too slow adoption if we stay with LGPL? This is what we really have to gauge now.
Johann Fischer
Hi Johann,
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
Hi Olaf,
if both LGPL and other considered licenses are OK for you, then switch to RIOT right now
What is holding you back, more precisely? I would be interesting to know about it, it might bring some arguments to this debate.
Best,
Emmanuel
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,
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
Hi all,
sorry for the late reply.
I'm not against a license change in general.
I understand the positions of companies to be restrained on LGPL. They will not provide much effort, in manpower and finance, to find a way to link their implementations to RIOT not violating LGPL. Just as Joakim stated, R&D always produce an amount confidential parts of code that cannot be released to the public.
I see a license change pragmatically, I don't expect that most companies that insist turning from LGPL to a less restrictive license such as BSD/MIT before even "think about using RIOT", will contribute back to the RIOT codebase. But if we can lure companies to actively use RIOT, this may gain the visibility in serious markets and promote RIOT as the "Product" of choice for the IoT. Still I'm a little bit sceptical if a license change will result in the desired pull effect.
In this context I'm in favour of an Apache like license over BSD/MIT.
Best regards, Martin
(sorry for the post in users) Hi all,
sorry for the late reply.
I'm not against a license change in general.
I understand the positions of companies to be restrained on LGPL. They will not provide much effort, in manpower and finance, to find a way to link their implementations to RIOT not violating LGPL. Just as Joakim stated, R&D always produce an amount confidential parts of code that cannot be released to the public.
I see a license change pragmatically, I don't expect that most companies that insist turning from LGPL to a less restrictive license such as BSD/MIT before even "think about using RIOT", will contribute back to the RIOT codebase. But if we can lure companies to actively use RIOT, this may gain the visibility in serious markets and promote RIOT as the "Product" of choice for the IoT. Still I'm a little bit sceptical if a license change will result in the desired pull effect.
In this context I'm in favour of an Apache like license over BSD/MIT.
Best regards, Martin
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.
Hey,
Hi,
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 :
Hey,
Hey,
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.
I'm violently opposing the switch to a less restricitive license.
IMHO the floating interpretations on LGPL (e.g., [1]) pose the following restrictions on any product using LPGL'ed RIOT:
1. The entity distributing such a product must mention the use of RIOT.
E.g., the user manual has to state that RIOT has been used. This is common practice, just pick your favirote gadget and look for that.
2. The entity distributing such a product must make a copy of the used RIOT version available via means specified in the LGPL.
This is also common practice. Nowadays, about all vendors of Linux based routers provide a "GPL tarball" containing copies of any used GPL stuff.
3. The entity distributing such a product must release any part of RIOT that it modified under LGPL.
4. The entity distributing RIOT must provide means to exchange the RIOT part of the product's software with a (newer) version of RIOT.
This requires the device to be field-upgradable and also it requires the distributor to provide at least the object files that were used in the final linking step.
Mind that 4. doesn't require the released object files to be compatible with *any newer version* of the library.
So basically, LGPL forces changes to core RIOT to stay under LGPL and it also forces vendors to sell products which can be updated.
As far as I interpret the opinions of the RIOT community, we mostly agree that the actual license does what we expect our license to do (apart from patent protection).
The only reason why we think about another license change is FUD on the company side, as the perception of the license scares away potential users. We don't want to push away potential users, so we try to find a license which takes away the FUD by giving up all rights to the code that we develop in order to please those companies.
IMHO, we don't need those companies to succeed as a community project which will play a large role in IoT.
Also IMHO, the advantages of LGPL, like the forced upgradability (implying possible security advantages), impossibility of sell out of community contributions, higher value of devices due to lack vendor lock-in / repurposability, complete vendor independence, ... outweigh the promise of a stream of contributions by companies selling products. Companies which are unwilling to comply to our fairly unrestrictive license.
That said, if most of the community agrees to switch to a less restrictive license, I will agree to that, too. That is not because I have been convinced that the change is the right choice, but because I really like the biggest strength of RIOT: the community and the actual people behind it.
Kaspar
Hi!
> >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) > What kind of "static linking exception" do you have in mind?
The regular kind
In general, I would agree that - to my understanding - (L)GPL with linker exception is more aligned to what we're looking for than to LGPL only.
The last time I though and researched about this topic, I came to the conclusion that the main problems of the linking exception clause is, that there's no "official" version of it. So, we might end up in a similar case compared to inventing our own license.
Cheers, Oleg