On Fri, 8 Mar 2013 06:39:25 +0100 Michael Haberler <mai...@mah.priv.at> wrote:
> Am 08.03.2013 um 04:06 schrieb Matt Shaver: > > 4. According to this page: > > http://www.zeromq.org/area:licensing > > they say: > > *************************************************************** > > Static linking exception. The copyright holders 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 must > > extend this exception to your version of the library. > > > > ØMQ for Commercial Applications > > > > ØMQ is safe for use in close-source applications. The LGPL > > share-alike terms do not apply to applications built on top of > > ØMQ. > > > > You do not need a commercial license. The LGPL applies to ØMQ's > > own source code, not your applications. Many commercial applications > > use ØMQ. > > *************************************************************** > > This description is spot on. But, the way I read it: "The copyright holders give you permission to link this library with independent modules to produce an executable, REGARDLESS OF THE LICENSE TERMS of these independent modules" Do we need to actually include 0MQ code in Linuxcnc to use it (other than header files which are excepted by the LGPL)? Is our use of 0MQ going to exceed the permission granted by the "Static linking exception"? > > If this is the problem, let's figure out which are the actual > > "roadblock" files. If this is not the problem, or if there are other > > licensing issues, please let me know. > > yes, that is what needs to be done. I'm actually happy to work on this! If you were to say to me, "Matt, you should work on analyzing our current licensing situation and attempt to make it better because it's the right thing to do", I would be pleased to do all I can towards that end. I would just like to understand what the problem is with _actual_ license incompatibility. As far as I can tell, 0MQ would be OK to use _today_ under the "Static linking exception". > the only remarks I have: > > 1) affects not just me, and not just the ZeroMQ package. Folks are > routinely bitten by it, and several packages which would be > attractive for use with LinuxCNC are off limits, for instance the > excellent Kivy touch screen UI project, Link: https://github.com/kivy/kivy/blob/master/COPYING License: LGPLv3 Matt's Opinion: This library could be used with no changes to the Linuxcnc licensing PROVIDED THAT no "linking" occurs between Kivy code and anything in Linuxcnc that is licensed "GPLv2 only". ************************************************************* If you use this library, do the following: 1. Package and distribute the resulting program as an "independent and separate work". 2. Communicate with Linuxcnc only over an interface that does not require the code of the Kivy based program to incorporate any of the Linuxcnc code that is "GPLv2 only", for example, over TCP/UDP, sockets or pipes. ************************************************************* I have assiduously avoided any discussion of "linking" as it applies to the GPL because it is so contentious an issue with regard to the perceived definition of the term. For a more complete discussion of the issues involved, see: http://www.law.washington.edu/lta/swp/law/derivative.html > or the RPCz layer ontop of > ZeroMQ. Link: http://code.google.com/p/rpcz/source/browse/COPYING License: Apache Version 2 Matt's Opinion: Use it with no worries, today, as long as you don't create a Derivative Work. The Apache License says, "Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof". The mere use of this library does not create a Derivative Work. > Those can be worked without; the story on equivalent > replacements for ZeroMQ is short and lacking a wide range of language > bindings in particular. And I simply do not have the time and energy > to work around by re-coding such completely generic tools just > because of the licensing status of LinuxCNC. > > Other examples are libmodbus Link: http://libmodbus.org/documentation/ License: "The license of libmodbus is LGPL v2.1+ and the licence of programs in the tests directory is GPL v3". Matt's Opinion: Use it, as desired, today! See: http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility > and OpenSCAM; Link: http://openscam.com/ License: This is licensed "GPLv2 or later", plus they specifically target the Linuxcnc version of G-code to visualize. Matt's Opinion: Use it, as desired, today! Release any _combined_ code as "GPLv2". > in these cases I could > work around the issue by convince the authors to relicense _their_ > package. This does not scale - it only works for rather small > projects, and those are not the ones which are a huge boost in such > an effort. > > 2) Given JMK's expressed willingness to relicense along these lines > and fact that the list of folks who contributed to RTAPI/HAL is > rather short, this seems to be the easy part. That's true, but with one notable exception: Mr. Paul Corner of England, wrote me in response to my earlier essay on Linuxcnc copyright issues. Since he forbid me to share the content of his communications with anyone, I can't quote him directly, but he made it clear that he will not allow the re-licensing of any of his work. He explicitly stated that he would not allow the appending of the words, "or later" to the GPLv2 license declaration. The ramifications of this will need further study to determine, but several areas that are likely affected (if a license change is desired) are libnml, the backplotter in lklinuxcnc, and RTAPI. RTAPI is the major problem in my opinion. > Since e.g. task and > motion must tie into the middleware by linking to ZeroMQ, and both > are GPL2only, it is one of the hot spots. Same goes for UI components > which will need to tie in. This is a bit ironic given the fact that > task hasnt changed all that much since it came out of NIST with a > public domain status. I think it's possible that all of the work based on the NIST code is _still_ in the public domain, despite the addition of license notices added to the code later. I base this on three things: 1. The NIST portions could be considered "Derivative Works" rather than "Joint Works" due to NIST's overwhelmingly large contribution to the whole. In my previous essay I argued that only a minimal contribution to a work was required to become an author in a "Joint Work", but I don't know where the line is actually drawn. In fact, allowing contributions to a Work by US Government employees which results in a "Joint Work" would vest in those US Government employees an undivided copyright interest therein (absent any other agreement), giving them the right to license it as "Public Domain". This is an incredibly sticky issue and to avoid further damage to my previous good mood this morning, I'll leave it at that... 2. The original copyright notice in the code on Sourceforge (as I remember) said something like, "GPLv2 and other rights". Fred Proctor told me the "other rights" meant that it was in the Public Domain. I need to do some research to confirm this before relying on it. 3. Since changing out NML for 0MQ will likely mean large changes to the NIST code anyway, we could (maybe) try to start from the last Public Domain NIST code, rather than what's in git/master today since the differences are, as you point out, not too large. > I would be very grateful if that work item were picked up. I will do all I can. > I am happy to help, and I know others will too. 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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
