Am 22.08.2012 um 18:07 schrieb Matt Shaver: > On Sun, 12 Aug 2012 01:40:06 +0300 > "Alex Joni" <[email protected]> wrote: > >> Last emc1 version was 1.2.0-rc1 iirc, >> you can still find the CVS tree for emc1 here: >> http://emc.cvs.sourceforge.net/viewvc/emc/emc/ > > Thanks Alex! > > I've been doing some research into copyright law to determine if > Michael Haberler can use free software components (like 0MQ) that are > available only under licenses that may conflict with the licenses under > which Linuxcnc is made available. > > The situation is complicated and also not 100% knowable because the law > is either vague or silent with regard to important issues. For example, > the issue of what I would call "continuous creation" such as occurs in > a project like this where changes are made nearly every day, and the > actual copyrightable work will _never_ be finished, is not meaningfully > addressed in law. Another example is that a contribution to a work > which may establish a copyright interest for an author must be > "independently copyrightable", but this phrase is not clearly defined > and is subject to interpretation. > > However, after lots of reading I've come to some preliminary > conclusions: > > 1. Linuxcnc is a "collective work" which means, "a work, such > as a periodical issue, anthology, or encyclopedia, in which a number of > contributions, constituting separate and independent works in > themselves, are assembled into a collective whole". > > 2. This means that many parts of Linuxcnc, particularly those created > from scratch after the exit of NIST from the development process, have > known authors with indisputable copyright interests. These authors have > chosen to allow copying of their works subject to licenses of their own > choosing, mostly the GPL I think. In this category you would find > things like AXIS, the HAL system and its components, utilities like > stepconf, the beautiful documentation, the build system and > infrastructure, etc. The important issue is that these are > "independent works", that can stand on their own without the rest of > Linuxcnc. I would suggest that these parts be made _more_ independent > by such actions as packaging them separately so that they can be > installed individually, and also by eliminating installation > dependencies on, and inclusions (include, require, source, import, etc > statements) of (if at all possible), any code that is about to be > defined in the next paragraph (3) below. In short; create as many > "independent works" as possible with good copyright pedigrees, and > enforceable licenses. If any of these are also "joint works" (about to > be discussed at length), the authors should have a written agreement > that codifies their mutual agreement on licensing. > > 3. The remaining part of Linuxcnc is that part which originated at > NIST, and possibly elsewhere. This part itself is a "collective work", > consisting of the interpreter (Tom Kramer + many happy helpers), the > task planner, the motion controller, the I/O controller, rtapi, etc > (Fred Proctor, Will Shackelford, + many more happy helpers), NML (James > Albus, Fred Proctor, Will Shackelford, et al), and other parts with a > similar set of authors. > > A. In the beginning, this was mostly a “work of the United States > Government” which means, "a work prepared by an officer or employee > of the United States Government as part of that person’s official > duties". > > B. There may also be a few files that were provided by third > parties (like Servo To Go, or Delta Tau) to facilitate using their > products, or something provided by another early EMC user like GM. If > anything remains of these in the present day Linuxcnc, then their > copyright owners, and the license under which they are distributed > should be identified within the text of the file itself. > > C. According to U.S. copyright law, "Copyright protection under this > title is not available for any work of the United States Government, > but the United States Government is not precluded from receiving and > holding copyrights transferred to it by assignment, bequest, or > otherwise." (http://www.law.cornell.edu/uscode/text/17/105) > > D. I'm not sure if 'not copyright protect-able' is the same as 'being > in the public domain'. I can't cite an explanation of this and it > seems too important to ignore. > > E. As far as I know, all the earliest non-governmental participants in > the EMC project, including GM's Pontiac Powertran Division, Boeing, > and me signed Cooperative Research And Development Agreements > (CRADAs) in which the government agreed to help with research if the > participants disclaimed any intellectual property interests, > including copyrights, in the results. I'll see if I can dig up my > copy of this just for completeness. > > F. At some time, after my involvement began, and probably before the > move to Sourceforge, I believe some part(s) of EMC became a "joint > work", which means "a work prepared by two or more authors with the > intention that their contributions be merged into inseparable or > interdependent parts of a unitary whole". I believe it became a > "joint work" rather than a "derivative work" because the intent was > always collaboration on successive versions of a single work. For a > summary of the doctrine of "joint works" see: > http://cyber.law.harvard.edu/metaschool/fisher/joint/links/articles/lape.html > > G. Just FYI, a "derivative work" is "a work based upon one or more > preexisting works, such as a translation, musical arrangement, > dramatization, fictionalization, motion picture version, sound > recording, art reproduction, abridgment, condensation, or any other > form in which a work may be recast, transformed, or adapted. A work > consisting of editorial revisions, annotations, elaborations, or > other modifications which, as a whole, represent an original work of > authorship, is a "derivative work." I believe miniEMC2 is an example > of a "derivative work" based on EMC2. For an explanation of the > difference between "joint works" and "derivative works" see: > http://www.owe.com/legalities/legalities28.htm > > H. The above linked owe.com article states, "Under copyright law, > absent a written agreement otherwise, each joint author owns an > undivided interest in the whole work." > > I. There has been some debate about the elements (their quantity, > quality and other characteristics) necessary to form a contribution > sufficient to establish authorship in a "joint work". Generally the > consensus seems to be that a contribution must be: > > i. original or innovative > AND > ii. "fixed in a tangible > medium of expression" (http://codes.lp.findlaw.com/uscode/17/1/102) > > My take on this is that a contribution of code that exceeds the > threshold of just fixing a typographical error or reformatting, and > which represents anything greater than a minimal amount of creativity > would satisfy the first criteria. The second criteria is satisfied > when the contribution is checked into the source code repository and > merged with the existing code. For more information on contribution > requirements to "joint works", see: > http://digitalcommons.lmu.edu/elr/vol12/iss1/8/ > and > > http://euro.ecom.cmu.edu/program/law/08-732/Transactions/LegalIssuesNimmer.pdf > > In summary, I think that Michael Haberler can use 0MQ, even if it is > GPL3 licensed, if: > > I. He is one of the authors of the "joint work" started by NIST by > virtue of his contributions thereto. He can exercise his right to > re-license the use of this part of Linuxcnc in a compatible way, for > example GPL2+. > > OR > > II. Some other author of the "joint work" started by NIST can exercise > their right to re-license the use of this part of Linuxcnc in a > compatible way to aid Mr. Haberler in his endeavor. > > The above assumes that all the work to be done affects only the NIST > originated portions of Linuxcnc. The authors of the other parts of > Linuxcnc will have to decide what they want to do with respect to this > issue. Since most of these other parts are also "joint works", any of > their authors can unilaterally re-license their work to be compatible > with the new 0MQ using version. I would suggest however, that these > decisions be made in consultation with as many of the co-authors of > their respective works as can be found, out of respect for democratic > ideals and to preserve the peace. > > Finally, I feel that these copyright law issues should be considered > when deciding the future form of Linuxcnc. Assuming we all desire > essentially "share and share alike" licensing, rewriting the NIST > originated code would eliminate any ambiguity in the licensing status > of this part of the code. I also strongly suggest that the various > parts of the Linuxcnc system be separated into libraries or standalone > programs as much as is practical. This will help define who the authors > of each piece are, aid testability through modularity, and maximize the > hazard to any hostile party attempting to use the code outside the > terms of the licensing. > > Thanks, > Matt
Matt, thanks for picking this up, I really appreciate it especially since I cant really contribute anything significant to anglo-saxon law issues because I lack the basics. This was very educational for me; so far I had implicitly assumed re-licensing of source file X with Y contributors would require consent of all Y contributors, which I now understand to not be the case due to being a "joint work". That aspect, together with the fact that not all contributors might be reachable, or agree, made it look an unlikely success to me. As for dicing and slicing the codebase, I would think this wouldnt just be beneficial for the issue at hand, but also for spelling out the dependencies clearly, and 'selling' parts of LinuxCNC to other users, increasing use and community reach. For example, spinning out the HAL, RTAPI, component infrastructure, component compiler, and maybe the generic interface part to a new messaging scheme would be a boon to folks doing embedded outboard devices. Right now that is tightly integrated into the code base so few people stumble upon the fact that RTAPI/HAL is a very generic vehicle (which is in fact very well designed, kudos). Even I would need some time separating it out and make sure the recombined projects dont fall on their face. If I understand correctly, the RTAPI and HAL parts are (all?) GPL2+ and hence could be spun out relatively easily, but I need to dig into this and I dont really get around to it before mid-September. as for which parts could be spun out with an eye towards fixing the license issue as well as reusing in LinuxCNC3 (I ignore non-code parts for now): - RTAPI/HAL/component infrastructure, sim/rt support as I said above. - libnml can go, emcnml just as blueprint to map message types onto the new messaging infrastructure. - the interpreter - all of the UI's, where I see decisions to come which shoud be carried forward. To realistically start with LinuxCNC3, I think the minimum list-of-parts would be RTAP/HAL etc, plus GladeVCP, in an license un-encumbered fashion. Others parts can be brought in as they pass the 'rubber glove check'. regards - Michael > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
