> >> P.S. We are bound by the warranty, anti-tivoization, patent, and > >> other terms of the (L)GPLv3 if we use 0MQ.
Wait! Stop right here! I wrote the above quoted text, as an afterthought to a post I made earlier in this thread. Now that I consider it again, this may not be the case. Since the linking of 0MQ is permitted, even for commercial applications, what I wrote above must be wrong as no commercial software company would accept these added responsibilities. Just for a moment, step back far enough from these details so that you can see the full picture of what's going on here. What we have are several groups, each of which has developed some computer programs which they want to make available for others to use on a "share and share-alike" basis. They all chose to use a "free software" licenses, mostly the GPL with some Apache and such thrown in. I would guess that the version of the GPL selected by each group for their work was mostly based on whatever version was current at the time. If the person who typed the license notice in the file headers had read an article on the FSF site, it might have got an "or later" stuck on the end like it said you should do in the article. The idea that these groups are unable to cooperate or collaborate with each other as they desire because of license text minutia, most likely unconsidered at the time their licenses were adopted, is just ridiculous and counter productive. My late friend and mentor in the real estate business, Allen Codd would have said, "Well, that's just a bunch of crazy talk". If we all had to consider every possible legal ramification of each thing we do everyday, we would all be frozen in terror, unable to get out of bed in the morning. This can't continue or we'll never get anywhere. Here is what I propose: 1. MH said that we should be able to state: "The license(s) applicable to the LinuxCNC code is/are here: <link(s)>" I'll work on clarifying what the license status for each file/module/section is now, and how it came to be that way. If re-licensing is contemplated, this is a necessary first step. 2. MH also said that we should be able to state: "The dependent package licenses are here: <links>" I'll get together this list of dependencies and license information. I'll also contact each of these projects and tell them about our plans to use their code so that if they plan on objecting, they can do it now. I acknowledge this may not be good enough to satisfy the lawyers who work for these big distributions, but we're in the situation where, "the best is the enemy of the good" - Voltaire. 3. In the mean time, proceed as if none of this is a consideration. The worst case is that we'll never be able to release the work without removing the dependency on code whose owners object to its use by linuxcnc. The benefit is that we will "flush out" any complaints by these other projects, if any. If need be, you can blame all this on me :) I'm happy to act as the "complaint department" if that will move things forward. If I get any complaints, I'll let you know and we can figure out what to do at that time. No complaints = No worries. Thanks, Matt ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
