[License-review] License Committee Report - for board meeting of 2013-11-06 [NASA, EUPL, and Tidepool]

Wed Jun 25 17:56:04 UTC 2014

Richard, Luis,

I finally went back through old emails to see what has been holding things up on certification of the new NASA Open Source Agreement 2.0.  It appears that a response to the email below remains outstanding, for which I apologize (oversight on my part).  Please see below in red for my specific responses.  I hope that we can move forward with this.  Please let me know any thoughts/concerns.  As a foundation, please consider:

First, understand that, because NASA is a government agency, we are subject to statutory and regulatory restrictions that the world at large are not, resulting in some unique requirements in an open source agreement designed for use by the federal government.  Two of these requirements are found in Paragraphs 3F and 3K, and a more specific explanation for each is given below following your comments.

Second, in considering your comments, Richard, I don't see where you identified a violation of any points of the Open Source Definition (OSD).  Your concerns are characterized as "substantive," leading to your conclusion that "I cannot consider NOSA 1.3 an open source license," and yet no substantive breach of the OSD is alleged.  If there is another standard in play here, please help me understand so that we can respond.

Bryan A. Geurts
Chief Patent Counsel
NASA Goddard Space Flight Center
Code 140.1, 8800 Greenbelt Road
Greenbelt, MD 20771
Phone:  301-286-7352
Fax:  301-286-9502

This document, including any attachments, contains information that is confidential, protected by the attorney-client or other privileges, or constitutes non-public information.  It is intended only for the intended recipients.  If you are not an intended recipient, please take appropriate steps to destroy this document in its entirety and notify the sender of its destruction.  Use, dissemination, distribution or reproduction of this information by unintended recipients is not authorized and may be unlawful.

This communication should only be used for the particular matter discussed herein.  Changes in circumstances and changes in law can greatly alter any current legal advice.

-----Original Message-----
From: Richard Fontana [mailto:fontana at sharpeleven.org]
Sent: Thursday, October 31, 2013 9:02 PM
To: License submissions for OSI review
Cc: luis at tieguy.org; Geurts, Bryan A. (GSFC-1401)
Subject: Re: [License-review] License Committee Report - for board meeting of 2013-11-06 [NASA, EUPL, and Tidepool]

On Wed, 30 Oct 2013 10:49:22 -0700
Luis Villa <luis at tieguy.org> wrote:

> Reminder: if you have comments on NASA or EUPL (Tidepool still has its
> own semi-active thread) now is the time for them :)

[...]

> > Comments: There have been some questions about the clarity of the
> > license, particularly the use of "requests" in a section that NASA
> > informs us is optional, and suggestions have been made to resolve
> > those concerns. However, it appears that no substantive concerns
> > about OSD-compliance have been raised.

License text for reference:
http://projects.opensource.org/pipermail/license-review/attachments/20130607/0d342a59/attachment-0001.txt

I would like to raise some substantive concerns about OSD-compliance.
Sorry I did not pay much attention to this earlier. I am cc'ing Bryan Geurts who submitted the license.

A general comment: I believe that because this license is coming from NASA, it should be held to a relatively high standard. I think there is a natural bias in favor of approval of the license (because of NASA's prominence, technological and cultural, as a US government agency, and because OSI has certified a predecessor license).

Agreed.  Please understand that the NOSA 2.0 is the result of significant time and effort by a team of NASA IP lawyers who have been working on this and other open source issues for the Agency for several years now.  We do not submit NOSA 2.0 for certification lightly and believe that we have done our homework to address the needs of NASA, and perhaps other federal government agencies, in a better way, all while complying with the open source definition.

3F: What if non-NASA Contributor A or non-NASA recipient B, allow me to say that they endorse a product or service provided by me: am I violating NASA's license? As drafted this seems to be possible under 3F, yet it would be an absurd and unfair result.

Paragraph 3F is a requirement imposed by NASA's charter Statute, the Space Act, where it states:  "No person . . . may knowingly use the words "National Aeronautics and Space Administration" or the letters "NASA", or any combination, variation, or colorable imitation of those words or letters either alone or in combination with other words or letters . . . in connection with any product or service being offered or made available to the public in a manner reasonably calculated to convey the impression that the product or service has the authorization, support, sponsorship, or endorsement of, or the development, use, or manufacture by or on behalf of the Administration which does not, in fact, exist."  See 51 USC §20141(a).  Other federal agencies have a similar restriction in their charter statutes.  This same restriction is found in NOSA 1.3, Paragraph 3E.  Since the NOSA is designed to govern software created by an agency with such a restriction against endorsement, such a prohibition is required.  If you or any other non-government agency entity wishes to endorse a product or service not related to a government agency, you are free to do so.  I don't see how this restriction could be construed or interpreted any differently.

'Requests' issue (3K):

If, as has been said, 'requests' means 'we'd appreciate it if you did this, but you don't have to', there is obviously no OSD-compliance concern, but we have to consider reasonable future interpretations by others using this license, such as some other government agency. A mandatory provision would, IMO, clearly not be open source.

Let me cite to an earlier response I made concerning this paragraph, which I believe is dispositive of this issue:  "Section 3.K. is included as a nod to the NASA Software Release Program (see generally NASA Procedural Requirements 2210.1C), which requires that all NASA software that is released to others, whether to another NASA or government project or to the public, be tracked for metrics regarding interest generated by the software (see in particular paragraph 3.6 of NPR 2210.1C).  More specifically, paragraph 3.6.2 requires that, in the case of a release that is "solely by electronic means," "each recipient shall be requested to register with a NASA point of contact for all transfers of . . . Open Source software for which no Software Release Record was required (e.g., release by click wrap agreement)."  Thus, all NASA released OS software that is governed by the NOSA must include Section 3.K.  However, realizing that other government agencies using the NOSA may not require the same efforts to track released software, we decided to make Section 3.K. optional according to the particular needs/requirements of the agency.  Understanding that a requirement to register or provide recipient information would violate the OS Definition, this step is entirely voluntary.  Luis is absolutely correct in observing that nothing more than the plain meaning of "request" is applied or implied here."

Patent and copyright termination (3J):

If this were limited to termination upon the bringing of patent litigation, it would resemble provisions in a number of OSI-approved licenses. What I believe is unusual about the NOSA 1.3 provision is the extension to copyright infringement litigation.

Your observation is correct - yes, many open source licenses terminate automatically upon bringing patent litigation and, yes, NOSA 2.0 extends this automatic termination to copyright infringement litigation.  However, I'm not sure how you can distinguish between termination upon patent litigation and termination upon copyright litigation, saying that one violates the OSD while the other does not.  That is a non-sequitur.

This clause seems to say the following: If a NOSA 1.3 work X incorporates some (say) upstream MIT-licensed code authored by A, and A receives work X, and B, another recipient of X, commits copyright infringement as a consequence of failing to comply with the MIT license on A's code, if A sues B for copyright infringement, NASA can terminate the copyright license granted on X to A. That seems unreasonable to me and seems to undermine an implicit open source policy of general nonobstruction of legitimate enforcement of open source licenses and legitimate pursuit of copyright infringement claims inside the open soure licensing system.

This scenario is not plausible under NOSA 2.0.  Paragraph 3J only applies to the original work and contributions to the original work, collectively called the "Subject Software."  Paraphrasing NOSA 2.0, a contribution is a derivative work, which is defined as "a Work that is based on (or derived from) the Subject Software . . . . Derivative Works shall NOT include . . . additions to the Subject Software which are separable modules of software distributed in conjunction with the Subject Software, or parts of the Subject Software, under their own license agreement."  Thus, in your example, since the MIT-licensed code is a separable module governed by its own license, NOSA would not apply to this software i.e. it would not be "Subject Software" and termination for copyright litigation could not occur.

My concern about 3J would be eliminated if it were triggered only by patent litigation.

Again, I don't see a substantive difference, at least when it comes to the OSD, between patent and copyright litigation.  In the view of our group of IP attorneys, automatic termination upon a Recipient instituting copyright infringement is warranted to discourage litigation over U.S. taxpayer-funded and developed OS software.

Apart from these concerns, I think this license could be made clearer in a number of other areas, but I do not think those other parts raise OSD-compliance issues.

Any specific suggestions (recognizing that it has been almost a year since we started the process of certification)?

In its current form I cannot consider NOSA 1.3 an open source license.

- Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20140625/d41acc31/attachment.html>