At risk of further confusing things maybe there's a happy medium between a strong copyleft/(L)GPL and a the BSD license. While I'm most certainly not a lawyer, copyright or otherwise, a quick look at the Eclipse Public License <https://eclipse.org/org/documents/epl-v10.php> (EPL) and the related EPL FAQ <https://eclipse.org/legal/eplfaq.php#> makes me wonder if it might be another possibility. The way I read it the EPL would keep RIOT itself free and open, along with any changes a person or company makes to the core OS, in-tree drivers, etc... but would also allow for "extensions" to be made and distributed under whatever license the creator sees fit (open or not). It seems to me that this would end up in a similar situation to what Ludwig suggested in his license craziness post but in a slightly more sane way.
Point 27 in the EPL FAQ seems to be very applicable to what we're all talking about here. - - I‘m a programmer not a lawyer, can you give me a clear cut example of when something is or is not a derivative work? If you have made a copy of existing Eclipse code and made a few minor revisions to it, that is a derivative work. If you"ve written your own Eclipse plug-in with 100% your own code to implement functionality not currently in Eclipse, then it is not a derivative work. Scenarios between those two extremes will require you to seek the advice of your own legal counsel in deciding whether your program constitutes a derivative work. For clarity, merely interfacing or interoperating with Eclipse plug-in APIs (without modification) does not make an Eclipse plug-in a derivative work. One potential issue with the EPL is GPL (in)compatibility. The FSF has stated that GPL code can not be linked or otherwise incorporated into an EPL licensed codebase. While the EPL isn't GPL compatible I'm reasonably certain that it *is *compatible with the LGPL. A fairly informative post on the topic of EPL/(L)GPL compatibility can be found on Stack Overflow here <https://stackoverflow.com/questions/5393873/epl-eclipse-public-license-gpl-gnu-public-license-lgpl-lesser-gpl-and-lic> . Another issue with using the EPL is the "choice of law" clause which states that "This Agreement is governed by the laws of the State of New York and the intellectual property laws of the United States of America." That would most certainly need to be altered. Anyway, I just figured I'd mention this as another potential license. On Mon Dec 15 2014 at 12:03:19 PM Emmanuel Baccelli < emmanuel.bacce...@inria.fr> wrote: > Hi Oleg, > > On Mon, Dec 15, 2014 at 6:39 PM, Oleg Hahm <oliver.h...@inria.fr> wrote: >> >> Hey Hauke! >> >> > To my experience the typical situation in >> > (larger) companies is, that technical people actually would like to work >> > with LGPL products an give code back but that they are not allowed to >> from >> > their management due to their lawyers not allowing LGPL. For MIT I see a >> > different picture: from my experience there are mostly strong rules in >> > industry about choosing a certain license, but not so many about giving >> back >> > changes to the community. >> >> Actually, the person from FSFE we've contacted told us that the attitude >> of >> several executives towards open source software is: "Oh, it's free, but >> you >> have to contribute back? Okay, then we have to live with that." or "Oh, >> it's >> free and we don't have to give anything back? Great, why the hell should >> you >> publish our code. Don't do it!" >> >> (Of, course there might be many more executives just saying: "Oh, it's >> free, >> but you to contribute back? Don't even think about touching it!") >> > > > It's not entirely surprising that FSF is advocating (L)GPL ;) > The crux here is: are there constraints specific to IoT software, that > make LGPL too often problematic, technically? > I think that's what Hauke (among others) was hinting at. > > >> >> > (iii) Last I think the community is not influenced very much by >> changing to >> > MIT. It's not like a company can take the code and forbid anyone to >> continue >> > working on RIOT. If the is a company taking the code, developing it >> further >> > internally and selling the results without sharing it can happen. But >> in the >> > mean time RIOT will move on (and that fast to the current point) and >> that >> > means the motivation for paying for a closed-down RIOT clone instead of >> > using the open Original is not very high. >> >> I second this thought! As Kaspar has written, too: It's all about the >> community and the fun time spending with this awesome tool. It's gonna be >> always free and open source, no matter what stupid companies try to do >> with it >> behind closed doors. We are RIOT, the rest is just code! >> >> > +1 > > > Emmanuel > _______________________________________________ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
