Hi, I'm opposed to the eclipse public license because of its (L)GPL incompatibility and therefore to joining the Eclipse foundation.
Cheers, Ludwig Am 25. Februar 2015 11:39:08 MEZ, schrieb Emmanuel Baccelli <emmanuel.bacce...@inria.fr>: >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/ >[2] http://iot.eclipse.org >[3] https://eclipse.org/legal/eplfaq.php#CPLEPL >[4] http://en.wikipedia.org/wiki/Contributor_License_Agreement > > >On Wed, Feb 25, 2015 at 2:28 AM, Adam Hunt <voxa...@gmail.com> wrote: > >> 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 <https://www.gnu.org/software/classpath/license.html>] >>> >> >> --adam >> >> >> [1] https://www.gnu.org/software/classpath/license.html >> >> >> On Tue Feb 24 2015 at 5:08:12 PM Oleg Hahm <oliver.h...@inria.fr> >wrote: >> >>> 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 >>> -- >>> The problem with TCPIP jokes is that when I tell them, all I want is >an >>> ACK but >>> usually get FINs and RSTs >>> _______________________________________________ >>> 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 >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >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
