Matt, (caution: I'm not familiar with Anglo-Saxon law and licensing)
Am 08.03.2013 um 19:04 schrieb Matt Shaver: > 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"? Yes, linking is needed. I have asked the ZeroMQ steward, Pieter Hintjens, wrt to compatibility of a GPL2only project and ZMQ, and his answer was a straight 'no'. Maybe I didnt ask the right question, this is for sure worthwhile following up with Pieter in more detail. Note we are talking about a networking library. A network interface (one of the standard workarounds you mention below) to a networking library is unrealistic. > >>> 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. Yes, I would really appreciate if you take on the lead role on this. So: "Matt, you should work on analyzing our current licensing situation and attempt to make it better because it's the right thing to do" Many more are interested in getting this done, and will help - be it git esoterics, or rewrites. > > 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 The 'communicate over an interface that does not require.. etc' has given rise to the introduction of network interfaces in code just to work around that issue. I call them the 'RMS memorial protocols', so everybody memorizes what nonsense a full-blown jihad is able to produce. All this during the rise of hosted services which makes the point moot to start with for many applications; unfortunately not really for linuxCNC. > >> 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. I exchanged mails with the author Nadav Samet on the issue, and he went back to the google lawyers - the answer does not confirm your view: > Hi Michael, > > Thanks for considering using RPCZ. I'd be happy to help you. I forwarded your > request to the open source program leads at Google, and I was told that if > LinuxCNC was GPLv3 then it would be compatible. Will it be possible to update > LinuxCNC license to GPLv3? > > > On Sun, Jul 22, 2012 at 2:51 PM, Michael Haberler <m...@mah.priv.at> wrote: > Hi Nadav, > > I consider using rpcz in the linuxcnc.org CNC software > > Unfortunately the LinuxCNC software license (GPLv2) and Apache 2.0 license > are incompatible > > is there any chance you would relicense rpcz under a GPLv2-compatible license? > > best regards > > Michael Haberler NB: I do not consider this package essential. > >> 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 Yes, that is after I asked the author kindly to relicense. libmodbus already was GPLv3. > >> 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". same here. > >> 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. I had such an "exchange" as well and it was less than productive. That said, I did a quick git scan to gauge the problem: Files touched by Paul Corner in v2.5_branch: http://static.mah.priv.at/public/paul_corner_files_touched.txt 216 commits: http://static.mah.priv.at/public/paul_corner_commits.txt Many of those are already irrelevant. The nml stuff will become irrelevant by that very project same for the usr_intf in its current form TCL: this community better made a decision - I dont see anybody who can port or actually does maintain this. TCL use should be deprecated AFAIC. The hal and rtapi commits need study but I feel confident with de-Cornerizing those The task, motion and interpreter commits need to be looked at not a firm estimate, but a gut feeling: divy this up to 3-5 folks, one per directory, and we're done in a month > >> 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. 3) will mostly affect canon and task, but nothing significant of the the interpreter. These are very few files, and basically stubs. Motion needs review for post-NIST work which needs to be reverted. I dont think throwing away years of fixes and features is a good starting point; I would welcome if someone would start over with a clean codebase, like the OpenSCAM interpreter though. Interpreters are pluggable in principle; this feature hasnt seen much use. I would rather vote for backing out or rewriting nontrivial changes. I do assume there is a lower limit as for the level of intellectual contribution which constitues something relevant under the licensing angle. Many changes are editorial and not 'code' or original for that matter. - Michael > >> 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
