Hi All,
With some trepidation, I've decided to enter into this conversation.I
think that people wanting to make decision about a topic would like to
be well informed on the topic -- even when they involve potentially
emotional/religious topics (like licensing).
I've decided to offer for your consideration some licensing related
information about portions of LCNC, as I've come to understand it.I will
then finish with a pragmatically oriented suggestion for a course of
action (and it does not involve legal hoop jumping).
I'll start off with the obligatory IANAL. However, I can convey my
understanding of what I've learned as the result of explicitly
discussing this topic with people that are real licensed, working
members of the Bar in California. The content herein reflects my
understanding of some key parts of the reality of the historical
licensing situation wrt to EMC/EMC2/LCNC software.
When I ran biz dev organizations, I learned that when folks talk about
needing a "solution" to something, it can be enlightening to ask what
the problem really is.It's troubling that I can't make a crisp statement
of what this community thinks the "LCNC licensing problem" is. The best
I can do is infer the problem from what I've read, and presume that the
good folks on this list will correct/refine the problem statement as
necessary.
As I've read the mail lists for the last several years, I've noticed
that the talk of "licensing issues" often focuses on various aspects of
mixing GPL v2 and v3 licenses. That makes me think the perceived
"license problem" is:
There are incompatibilities between some combinations of GPL license
revisions. A perceived negative impact of this is that it potentially
prevents LCNC from using some software tool kits.
The "solution" discussions include notions of "changing the license used
for LCNC".The unstated assumption is that LCNC is currently covered by
some flavor(s) of open source license, (specifically the GNU General
Public License varieties: LGPL. GPLvX, etc), and thus the solution talk
tends to focus on GPL sub-versions.
Any issues arising from use of a mixture of GPL flavors (v2, v2+, v3)
can only be a concern for things covered by a some type of GPL license
to begin with. Thus the recurring GPL licensing discussions could be a
concern for parts of LCNC (but not for other parts).
Let's start with a simple model and think of the LCNC source base to be
composed of 3 "chunks" (in layer order):
1: Axis GUI
2: CNC Core (derived from NIST)
3: HAL
Taking them out of (layer) order:
1: Axis is pretty clearly GPL licensed.
It was an original work, and the authors choose to release it with a GPL
license. No controversy there that I'm aware of. If the axis GPL terms
are acceptable for you, you can use it, if they aren't, you don't.
3: HAL is mostly LGPL with a bit of GPL mixed in.
I understand that the bulk of the code was created and released under a
LGPL license. Over the years, it appears a few additional HAL parts
(some components) were created and they have been labeled/released as
GPL. Personally, I suspect that license choice for the GPL parts was as
much a matter of simply saying "GPL" in a generic fashion (like saying
Kleenex for tissues, or using "Xerox" as the verb for photo copying) as
much as it was a matter of careful legal thought and decision. I'd also
guess that the LGPL/GPL mix within HAL could be resolved with a
tractable amount of effort. Personally, I think it would be good if HAL
were a layer that was consistently LGPL.
The situation with the CNC core (#2 group) is not as simple. This layer
represents the bulk of the code that constitutes the CNC part of LCNC.
In this category is all code that was released by NIST.
The legal conditions for the code release from NIST are determined by
a)USA federal law, and
b)The CRADA agreement (that Matt Shaver worked out with NIST).
Before we get to far ahead of ourselves, let's take a quick look at
"copy rights" as this is crucial to understanding the basis of software
licensing.
When an author creates a work, the author has (owns) certain rights in
that work. These rights attach at the moment of creation. An author does
not have to do anything additional to establish their rights. What are
referred to as "copyrights" are actually a set of rights under law that
an author has as of the instant of creation. Some examples of copy
rights are the right to allow copies, rights to make derivative works,
and rights of performance.
When a software author decides to allow others to utilize their work,
they are granting a subset of the author's (or the current owner's
rights if the author transferred them) rights (often with
restrictions/conditions) to other people.The author does not loose their
rights when making such a grant. Licensing some rights does not require
transfer of ownership of the rights being licensed.
GPL licenses (of any version/flavor) are simply examples of a set of
conditions under which an author has granted some rights.It is important
to understand that such a grant of rights can only be done by the owner
of the rights being granted. For example; Tom can't grant Bob rights to
Frank's works unless Tom actually owns the rights to Frank's works.
In Matt's post (June 7, 2013), he drew attention to section 5.3 of the
CRADA (reproduced here for ease of reference):
"5.3*_Subject Data._* All research results and Subject Inventions under
this agreement, including subject data and implementation agreements,
will be available in the public domain and shall not be copyrighted or
patented, and NIST has the right to use such data for any government
purpose."
This explicitly states that the EMC code from NIST is not subject to
either copyright or patents. That condition is consistent with my
understanding of various applicable aspects of federal law concerning
copyright of works developed by the US government (many such works are
not subject to copyright by statute).
For whatever it's worth to readers of this, I've discussed this topic at
some length with two different, very respected senior lawyers, from two
different firms, both of whom specialize in IP law, one of whom also
specializes in open source software licenses.
I am told that no copy rights (the space between the two words is
intentional) exit for any of the EMC code that came from NIST. The EMC
NIST code release was, and is, in the public domain. No author's
copyrights have ever applied, nor ever will, nor can be applied to that
code. This is a true public domain situation, there is no owner of
copyrights for the NIST code.
Note: This is not the same as an individual creating something, then
saying "anyone can do anything they like with this code". That would be
a situation where the author has granted unrestricted rights to anyone.
Here there is still an owner of the copy rights and the owner of the
copy rights can do anything with those rights that the law permits
(including granting unrestricted usage). Making an unrestricted rights
grant does not put the work into the public domain.
The public domain, non-owned situation wrt to NIST EMC code applies to
whatever legal structure currently exists (or does not exist) for the
loosely operating"EMC/EMC2/LCNC" organization. It will also apply to any
governance organization that might be invented. No such entity will be
able to own or control the #2 blob CNC Core code.(If you should
personally not like that reality, please refrain from blaming the
messenger for the message...)
Now remember that license rights can only be granted by the owner of the
underlying rights. There is no copyright owner for any of the code from
NIST, and a GPL license is a grant of rights by the owner of those rights.
I have been told that legally, a GPL (or any other type of ) license can
not be applied to any of the EMC code created and released from NIST.
Please note the use of the phrase "can not" -- literally in this sense
it means "it is not possible" or "there is no ability to".
So what about the comments in a lot of the LCNC files?
When you go back and look, you'll (unsurprisingly) find that the NIST
source files did not have GPL statements in them. At some time in the
past, many NIST source files were edited to add comments about licensing.
One common comment added is that the code is "derived from a work by
Proctor and/or Shackleford" (or similar wording) and that is true: the
code was created in NIST by the people mentioned (and others), while
they worked for NIST.
These same source files also contain comments that claim the contents of
the file are licensed under a GPL license. Counsel tells me those
comments are at best wishful thinking. For better or worse, no matter
what anyone may want or wish, asserting a GPL license status for the
NIST code does not make the existence of GPL license conditions true.
I suppose that about now some readers will be raising their hands and
saying "...but I own characters 3 , 14 and 27-54 on page 12 of file XYZ
and all of page 13 as I wrote those lines!".Such a reaction makes some
assertions about the granularity of ownership of code source etc.
I asked the lawyers about this situation. A programmer's intuitive
notion of "lines of code" is not relevant from the legal viewpoint.The
legal question involved (paraphrasing) is "At what point is a derivative
work sufficiently different from the original that it would be
considered a work that is independently / separately copyrightable?".
Frankly, we could all assert a personal opinion about the answer to that
question, and have some debate over whose personal opinion is "best";
but it would not really matter.
I'm told that this legal question has no objective, quantifiable metrics
in case law that can be used to predetermine the amount of change that
is required. So we can't look at a file and determine "this one is" or
"that one isn't".The question only gets answered on a case by case basis
by a jury, and then the answer is likely only for that specific case.I
gently suggest that one avoid this particular intellectual rat hole.
All this leads me to think that worrying about creating a LCNC
governance structure to address license issues and/or fretting over the
impacts of using GPLvX licensed code with any of the LCNC code that
originated from NIST, seems (at least to me) to be a rather fruitless
exercise.
Should everyone panic and raise a loud hue and cry? Well, if it will
makes anyone feel better, go ahead. Be advised that doing so won't alter
the reality of the situation (and some (at least myself) probably won't
be paying attention until the emotional venting is completed ;-).
"But we need to do something!"... Do we really?
Matt suggested that "we" (the larger community) could start a new
(untainted, born from a virgin?) project and sort of move code over as
it is (re)created. That has generated talk of "agreements with all
contributors" etc.I don't see this as a viable approach and I also don't
foresee that yielding a "license solution" in any time frame that is of
practical interest.
Let's explore the ("one license to rule them all, all one license to
find them, one license to bring them and in the darkness bind them..."
apologies to Tolkien, I could not resist) approach as a "what if"....
Someone gets to create a legal entity (a legal entity/person is needed
to hold ownership of the rights to the new thing). The entity could
maybe acquire (I think I'm being optimistic here) non-exclusive use (but
not ownership) of Axis (but not the EMC derived GUIs) and HAL. Just
getting that done would be a significant project. The new entity can not
(has no ability to) gain ownership of the #2 set of stuff. So this new
entity now has a GUI and a HAL layer, but no core CNC functionality to
connect the two... that combination seems of little practical interest.
Further suppose that the members of this entity set out to recreate the
CNC Core stuff from scratch... Clean room approach?How long will that
take (even without the clean room)?
My answer is "longer than the probable attention span of the volunteers
in the LCNC group".
Frankly, I'm thinking that a pragmatic approach would be to use a bit
more of the "don't worry, be happy" philosophy wrt to licensing and
instead steer community effort to improving the CNC Core code.
When I think about what single initiative would most benefit LCNC as a
project, I end up with:
**
*Build LCNC community consensus around an updated code architecture for
the CNC core (blob #2) which is modular, with well defined module
interfaces (probably message passing based), and then transition to this
gradually (and steadily) over time. *
IMHO, the single biggest barrier to LCNC contribution is the monolithic,
intertwined code blob that makes up the LCNC core code. On a part time
basis (perhaps even on a full time basis) it's hard to wrap one's brain
around enough of the code in sufficient details to be confident that a
change will not break some other part that seems (should be) unrelated.
If the code base were consciously evolved into smaller independent
modules, it would be easier for a potential contributor to learn a
module and improve it. That would increase participation and be good for
the overall health of the project.
[Side bar: If messaging tools are used to define module interfaces, this
also starts to whittle away (over time) at the perceived license issues
(messaging layers are net connections, not compile time linkages).
Modularity also can create "license issue isolating sand
boxes".Modularity with message passing interfaces is a technical
approach that improves both the technical aspects and the license issue
aspects of the LCNC project. ]
Increased modularity will not happen by the wave of a magic wand and it
won't happen by accident.I think there needs to be an architectural plan
to get from here to there over time. I also think that such a plan needs
to have good consensus (that word was used above on purpose; a wagon
moves better when all the animals pull in the same direction, or all the
wood is behind one arrow, or whatever industry phrase you prefer) if it
is to succeed.
I can't predict how long modularization could take as the time required
is totally dependent on the volunteer effort that shows up. A nice
aspect is that as modularity increases, it takes less effort for any
individual volunteer to contribute.
A architectural module plan/road map should draw on the broader
expertise of the community. This is not a topic that benefits from a
lone wolf approach and creating an architectural development road map is
the kind of exercise that benefits from having multiple LCNC folks in
the same place for several days.
I'll be happy to engage in the architectural topic of conversation while
in Wichita if others are also interested.Personally, wrt to LCNC, I find
myself more interested in this, and think it has a better chance of
helping the project, than the various legal/governance topics.
Dave
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
