David brings up some important points that have not really been
articulated before as far as I recall. Basically the bottom line is
that the NIST code is in the public domain and can not be changed to be
(L)GPL. That being said, according to the licensing compatibility doc
http://www.gnu.org/licenses/license-list.html the use of public domain
software is compatible with (L)GPL, as is CC0 licensed works. I think
it is important that the GPL notices at the top of any of the NIST code
be removed, and the proper NIST/public domain notices be placed there
instead. It should have never been marked as GPL.
Now on to the heard of issues that I have bumped into others in the
past is basically the thought "if you use it in a project/product you
distribute you have to distribute the source code". That is a
requirement of the GPL, as I understand that if I modify/upgrade any
LGPL code that I am obliged to pass those changes along, but not for
anything beyond changes to the LGPL code. No, IANAL, but that is my
understanding of what people have told me in the past.
So, what obligations do you hope to place on people using, selling, and
adding onto LCNC?
The one point where David asks `"But we need to do something!"... Do we
really?` Personally I would say yes if you want to assert any
obligation on the community both within and outside of LCNC. There are
people who have expectations that if their code is used in a commercial
product that the company either has to cough up the code or enter into a
commercial license. I've actually had someone in my face about that
when I was porting EMC1 and the alpha version of EMC2 to the commercial
version of RT-Linux for FSM Labs. The funny thing what that FSM Labs
was willing to fund that and other work to support LCNC (nee EMC) as an
example of what you can do with RTL, and all of the EMC related code
would go back to EMC. The hue and cry was such that frankly I am still
pissed a decade later. That is why I am only moderately involved with
LCNC efforts, and other those that I really want to see forwarded.
Resolving the expectations and legal responsibilities (via licensing)
would help a lot, but past that I am to busy with other things to have
any motivation to become a key player.
EBo --
On Jun 9 2013 5:40 PM, David Bagby wrote:
> 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
------------------------------------------------------------------------------
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
