On Mar 8 2013 12:25 PM, Michael Haberler wrote: > Am 08.03.2013 um 19:04 schrieb Matt Shaver: >>> 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.
can you put together a: http://static.mah.priv.at/public/paul_corner_now_irrelevant_commits.txt file so that we can simply get rid of his crap? Also, from this point on all submissions should be bound to at least a license of choice (whatever it is, and GPLv2+ seems the easiest route). > 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 sweet... I'm not sure I can break away enough time from work/life at the moment to help, but by all the gods of old and new, this is tempting... >>> 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. According to 0MQ's Licensing web page <http://www.zeromq.org/area:licensing> it is LGPL with a link exception, and simply linked. It also explicitly states that as long as you do not modify 0MQ, then you can use it for commercial uses, etc. Am I missing something here? What middlewhare are we talking about? NML? >> 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. but then again, starting with a decent software engineering approach (Agile/XP/whatever) and building a Testing Anything Complaint (TAP) regression testsuite (if it does not already have one already, which I think it might in part) will obviate a major overhaul... > 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. ------------------------------------------------------------------------------ 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
