Hi,
Hey,
Please explain without analogies and use concrete examples instead.
We release RIOT under BSD. Company X takes the BSD'ed code and sells some infrastructure around that, but basically, they sell commercially supported RIOT under a non-free license.
Now there's a bug. It takes weeks to fix, but *we* fix it. Company X takes the bug fix, releases a new (non-opensource) version and makes its customers happy.
Open source is nice.
Now there's another bug. It takes weeks to fix, but company X fixes it. So they release a new (non-opensource) version and make the customers happy.
But as they see their sales not optimal (e.g., there could be more customers), they decide not to share the bugfix in order to give potential customers more incentive to invest in their product instead of just using the open source version.
Same goes with features.
As time goes on, company X's version of RIOT gets a huge advantage over the closed source version, because, while the open source version cannot access the closed source improvements, company X can always profit from the open source improvements. They can even advertise those improvements when releasing a new version, advertise that they have the better product, so they can charge money.
My personal problem now is that if I contribute to the open source version and company X directly makes profit from it, I'm not contributing to make RIOT the best RIOT around, but I contribute to make the commercial RIOT the best RIOT.
Also, if there are two bugs, I fix one, company X fixes the other as they know I'm fixing the first, but they don't share, I feel exploited.
Also, if I fix bugs I *know* are already fixed (because they are in company X's version), I feel like wasting my time.
Kaspar
Hey,
Hi,
>>>>(L)GPL tries to put some restrictions on that. Mostly, the source code >>>>cannot realistically be sold as long it's (L)GPL. >>> >>>This is not correct (depending on your definition of code and selling >>>of course). >>I know that you know what my definition of selling is with respect to the >>discussion. > >Actually, I'm not sure this is the case, please elaborate. If you sell (L)GPLed source code, that code *must* be under (L)GPL, so the first buyer can freely distribute it (under those libraries terms).
So practically you can sell that code only once.
Maybe I'm missing something, but the BSDs say:
""" Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. ... """
This means that if you sell BSD licensed source code to someone, they can freely distribute it just like they could with LGPL'd code. The BSD licenses do not allow you to change the license ("sublicense") [1].
Cheers, Ludwig
[1] Exemplary web search result:
Hey,
In http://lists.riot-os.org/pipermail/devel/2014-September/001185.html
Ludvig Ortmann stated:
Last but not least, none of us intends to sue anyone for building proprietary applications with RIOT as long as they are in line with our goals (as given above). We embrace your contributions and will be happy to help you in the task of getting them into RIOT as best we can. However, it is possible for anyone, for example your competitors, to sue you for copyright infringement if you build a proprietary application on top of RIOT that does not comply with it’s license terms.
This is what started us thinking about the implications of building applications on RIOT. We want to be able to write binary only applications for RIOT, and not have to release the source code, regardless of what license the kernel and drivers are released under. We wish RIOT to succeed as an OS and we will contribute back any changes that we make to platforms, cpus or core, but we do not want to end up in a situation where a competitor can force us to release proprietary algorithms or other code released as an application running on an OS just because the OS is LGPL. Some vendor provided libraries are also binary only. On the other hand, we do not want our competitors to take the open source software and close it off and not contribute back to the project. All in all, I think it is important for RIOT to find a way to allow binary application code, similar to what open source desktop OSes do.
Best regards, Joakim Gebart Managing Director Eistec AB
Aurorum 1C 977 75 Luleå Tel: +46 730-65 13 83 joakim.gebart@eistec.se www.eistec.se
Hi everyone,
this thread has been silent since new year’s break.
Has anyone changed his/her mind on the topic in the mean time?
Else, here’s a tentative summary on where we are at, so far, in terms of expressed opinions:
- a few have stated their enthusiasm for MIT/BSD
- a few have stated their enthusiasm for (L)GPL
- the vast majority is less enthusiastic to either direction but could approve a switch to MIT, for pragmatic reasons
Is that fair enough, in a nutshell?
On a related topic, concerning the technical feasibility of LGPL licensing with RIOT, I assume you have all seen this proposal https://github.com/RIOT-OS/RIOT/wiki/LGPL-compliancy-guide which is the first attempt at a practical guide to proprietary code in RIOT.
Any comments on this in the context of the license discussion?
Best,
Emmanuel
If the proposed method in add infrastructure for binary LGPL compliance checks by kaspar030 · Pull Request #2362 · RIOT-OS/RIOT · GitHub provides a way to legally comply with LGPL and still run proprietary binary application level code on RIOT, then my vote is on LGPL.
This will make sure that any improvements to core, sys, drivers etc are passed back to the project in the future as well, even if the actual applications are not open.
Best regards, Joakim Gebart Managing Director Eistec AB
Aurorum 1C 977 75 Luleå Tel: +46(0)730-65 13 83 joakim.gebart@eistec.se www.eistec.se
Dear RIOTers,
I just found the eCos license: [1] http://ecos.sourceware.org/license-overview.html
It's basically a modified version of the GPL with linker exception. The interesting point: it is officially recognised as a GPL-compatible Free Software License: https://www.gnu.org/licenses/license-list.html#eCos20 and it seems to enable exactly what most of us want for RIOT: it makes it possible to implement proprietary applications on top of the OS, but any changes to the OS have to be made freely available. It seems also possibly to apply this exception on device drivers if this driver is implemented in a particular way. A very quick search revealed immediately one commercial user of this rule:
To me this looks very promising. What do you think?
Cheers, Oleg
[1] eCos is another "free open source real-time operating system intended for embedded applications."
Hi Oleg,
I thought that we already decided to exclude exotic licenses.
With respect to this specific license:
(1) We cannot use the license because the license text is specific to eCos (e.g., "eCos is distributed [...]").
(2) We should not use the license because it is not approved by the Open Source Initiative. OSI approval is important for some open source funding programmes etc.
If you want to spend more time on this, I recommend the thread http://projects.opensource.org/pipermail/license-review/2014-August/000853.html, in particular http://projects.opensource.org/pipermail/license-review/2014-September/000910.html.
Cheers matthias
Hi Matthias!
I thought that we already decided to exclude exotic licenses.
Yes. GPL + Linker Exception is not exotic.
With respect to this specific license:
(1) We cannot use the license because the license text is specific to eCos (e.g., "eCos is distributed [...]").
And original BSD license (License:BSD-4-Clause - Free Software Directory) is specific to "Computer Systems Engineering group at Lawrence Berkeley Laboratory", which is obviously no blocker to be adopted elsewhere. I don't see why replacing the name of the project should invalidate a license.
(2) We should not use the license because it is not approved by the Open Source Initiative. OSI approval is important for some open source funding programmes etc.
Seems to work quite successfully for eCos, ERIKA [1], GNU Guile [2], libgcc [3], NetBeans [4], ChibiOS [5] and several other bigger projects. Would be interesting what FSF says about it. At least eCos, ERIKA and ChibiOS are very similar to RIOT from a software architecture point of view (OS for embedded hardware).
If you want to spend more time on this, I recommend the thread http://projects.opensource.org/pipermail/license-review/2014-August/000853.html, in particular http://projects.opensource.org/pipermail/license-review/2014-September/000910.html.
I haven't found any clear answers in these two mails and don't want to spend the rest of the evening reading through another license discussion, I have enough with this one here. From what I've read, I gather that oSI doesn't want to approve it, because there's no need to approve it: "why not simply stop referring to 'the eCos License 2.0' as though it were a special license and instead characterize eCos as being licensed as 'GPLv2 or later' with a permissive exception? I've encountered other projects using similarly-worded GPL exceptions but to my recollection those projects characterize themselves as being GPL-licensed."
Long story short: I see your concerns, but for me GPL + Linking Exception is a common license model that works well for many well-known and mature projects. Personally, I would think that GPL + Linking Exception matches our needs far better than LGPL.
As I see it now, we won't come to any conclusion for or against switching to a non-copyleft license that satisfies everyone, because the goals and visions where to go with RIOT are too different.
Cheers, Oleg
[1] http://erika.tuxfamily.org/ [2] GNU's programming and extension language — GNU Guile [3] https://gcc.gnu.org/ [4] http://netbeans.org/ [5] ChibiOS free embedded RTOS - This topic does not exist yet
Hi Oleg,
> I thought that we already decided to exclude exotic licenses.
Yes. GPL + Linker Exception is not exotic.
but the name (or license branding). We had this discussion before. Rather unknown licenses need to be explained. Using eCos license is similar to use a RIOT license.
> With respect to this specific license: > > (1) We cannot use the license because the license text is specific to > eCos (e.g., "eCos is distributed [...]").
And original BSD license (License:BSD-4-Clause - Free Software Directory) is specific to "Computer Systems Engineering group at Lawrence Berkeley Laboratory", which is obviously no blocker to be adopted elsewhere. I don't see why replacing the name of the project should invalidate a license.
Misunderstanding.
I'm just wondering if eCos is the first license with the introduced exception -- I will not research on this ;).
> (2) We should not use the license because it is not approved by the > Open Source Initiative. OSI approval is important for some open source > funding programmes etc.
Seems to work quite successfully for eCos, ERIKA [1], GNU Guile [2], libgcc [3], NetBeans [4], ChibiOS [5] and several other bigger projects. Would be interesting what FSF says about it.
I never said it's impossible. In this type of discussion you will always find counterexamples. I just wanted to point out that I see it as an advantage to use an OSI approved license.
At least eCos, ERIKA and ChibiOS are very similar to RIOT from a software architecture point of view (OS for embedded hardware).
No comment ;).
> If you want to spend more time on this, I recommend the thread > http://projects.opensource.org/pipermail/license-review/2014-August/000853.html, > in particular > http://projects.opensource.org/pipermail/license-review/2014-September/000910.html.
I haven't found any clear answers in these two mails and don't want to spend the rest of the evening reading through another license discussion, I have enough with this one here. From what I've read, I gather that oSI doesn't want to approve it, because there's no need to approve it: "why not simply stop referring to 'the eCos License 2.0' as though it were a special license and instead characterize eCos as being licensed as 'GPLv2 or later' with a permissive exception? I've encountered other projects using similarly-worded GPL exceptions but to my recollection those projects characterize themselves as being GPL-licensed."
Long story short: I see your concerns, but for me GPL + Linking Exception is a common license model that works well for many well-known and mature projects. Personally, I would think that GPL + Linking Exception matches our needs far better than LGPL.
Can you explain in one our two sentences why? Because it's more inclusive?
As I see it now, we won't come to any conclusion for or against switching to a non-copyleft license that satisfies everyone, because the goals and visions where to go with RIOT are too different.
At least we don't get new basic insights with this thread.
Cheers matthias
Hi Matthias!
but the name (or license branding). We had this discussion before. Rather unknown licenses need to be explained. Using eCos license is similar to use a RIOT license.
Yes, I agree, but at least it's listed (approved?) by FSF. Another option (see citation from the OSI list from my previous mail) we could just state GPL as a license and point to the exception for commercial users. I think the text on the eCos page is pretty comprehensible.
The Wikipedia is even claiming that the perception "that without applying the linking exception, code linked with GPL code may only be done using a GPL-compatible license" is "unsupported by any legal precedent or citation".
I'm just wondering if eCos is the first license with the introduced exception -- I will not research on this ;).
I don't think so, but it's the only listed license from FSF that specifies the linking exception.
I never said it's impossible. In this type of discussion you will always find counterexamples. I just wanted to point out that I see it as an advantage to use an OSI approved license.
I agree, but if the choice is between a FSF approved license (as I understand eCos License is) that matches our needs and a less matching OSI approved license, I'm willing to bite this bullet.
> At least eCos, ERIKA and ChibiOS are very similar to RIOT from a > software architecture point of view (OS for embedded hardware). > No comment ;).
For clarification: I was referring to the fact that these systems have a similar use case as RIOT, not that there concept or feature set is similar to RIOT.
> Long story short: I see your concerns, but for me GPL + Linking > Exception is a common license model that works well for many > well-known and mature projects. Personally, I would think that GPL + > Linking Exception matches our needs far better than LGPL. > Can you explain in one our two sentences why? Because it's more inclusive?
Again taken from the Wikipedia article: "the LGPL formulates more requirements to the linking exception: you must allow modification of the portions of the library you use and reverse engineering (of your program and the library) for debugging such modifications."
> As I see it now, we won't come to any conclusion for or against > switching to a non-copyleft license that satisfies everyone, because > the goals and visions where to go with RIOT are too different. > At least we don't get new basic insights with this thread.
Which is too bad.
Cheers, Oleg
I’d be willing to bet that GNU Classpath is one of the oldest projects licensed under the GPL with a linking exception.
Classpath is distributed under the terms of the GNU General Public License with the following clarification and special exception.
Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obliged to do so. If you do not wish to do so, delete this exception statement from your version. [1]
–adam
Hi everyone,
GPL with linking exception seems relevant in this discussion – especially since eCOS, which is also a well-known embedded OS, uses this license.
As a side note, but highly related: at Embedded World yesterday, we met with the Eclipse Foundation [1] guys. RIOT is now officially invited to become an Eclipse project.
There are a number of advantages to be under the Eclipse umbrella: they provide legal services, and the IoT part of this umbrella [2] is actively helping communities such as RIOT to grow organically: in particular they promise promotion, and matchmaking with other FOSS communities and relevant industrial partners.
There are however strings attached: Eclipse has good reputation as far as I can tell, but nevertheless some of our independence is lost if we join, and we have to use the Eclipse Public License [3].
In any case, the Eclipse Foundation guys were stressing that CLAs [4] are crucial, whatever we do, whether we join Eclipse Foundation or not.
Best,
Emmanuel
[1] https://eclipse.org/org/foundation/
[3] https://eclipse.org/legal/eplfaq.php#CPLEPL
[4] http://en.wikipedia.org/wiki/Contributor_License_Agreement
argh - license madness - lets add some complexity fe. tri-licensed like jruby 
jruby/COPYING at master · jruby/jruby · GitHub
let riot stay as independet and open as possible please - thats my only concern. i see the websites of iot-ubuntu, iot-"mbed’a likes, iot-eclipse, and for my personal view its looks like some “business strategy” that has less and less todo with technical or “co-development” reasons.
Jan
Hi,
I'm opposed to the eclipse public license because of its (L)GPL incompatibility and therefore to joining the Eclipse foundation.
Cheers, Ludwig
Hey,
GPL with linking exception seems relevant in this discussion -- especially since eCOS, which is also a well-known embedded OS, uses this license.
If we are thinking about amending an existing license, we could also try to ease the restrictions of LGPL to fit our vision (whatever that is).
Like, as LGPL expects developers of proprietary code to
a. release everything needed to change RIOT (e.g., object files), b. to provide "reverse engineering" stuff to debug such a solution,
we could add exceptions to LGPL that clarify these terms.
e.g., we could add an exception that if that developer provides an LGPLed port of RIOT for a specific device and also the same means to get a basic RIOT on that board using the same means as for it's own customers (none if that device is not supposed to be field upgradable), we allow skipping those the original requirements.
Kaspar
Hi!
>GPL with linking exception seems relevant in this discussion -- >especially since eCOS, which is also a well-known embedded OS, uses this >license.
If we are thinking about amending an existing license, we could also try to ease the restrictions of LGPL to fit our vision (whatever that is).
In general yes, in practise I wonder if it wouldn't be more advisable to adopt something already existing.
Btw. I just realized during the last days that even FreeRTOS is using GPL with some kind of linking exception: License Details - FreeRTOS™
Cheers, Oleg
Hi,
If we are thinking about amending an existing license, we could also try to ease the restrictions of LGPL to fit our vision (whatever that is).
In general yes, in practise I wonder if it wouldn't be more advisable to adopt something already existing.
IMHO GPL + linking exception doesn't cut it. I'm not trying to change LGPL into that.
In my opinion the IoT world needs something that is more oriented towards respecting the needs of potential end users.
-> "IoT must be hackable."
A nice example of why:
"Hacking into Internet Connected Light Bulbs"
(short summary: Contiki based light bulbs distributed the users' WiFi credentials over a 6LoWPAN mesh using the same static AES key on all shipped bulbs.)
If code contributions is all we want, *BSD is probably the way to go.
Btw. I just realized during the last days that even FreeRTOS is using GPL with some kind of linking exception: License Details - FreeRTOS™
Nice example, as there are some successful products using it.
Take a look at Pebble: http://pages.getpebble.com/pages/opensource
Kaspar