NASA Open Source Summit

Solutions to Issue #2: Licensing

Instructions

  • This is the place for all summit participants to propose and discuss solutions to the one issue listed above.
  • Feel free to build on rather than delete what others are saying.
  • Format for Breakout Sessions:
  • Introduce each other with quick, 1-sentence bios
  • Describe the issue to get everyone on the same page
  • Brainstorm solutions
  • Go in-depth with one solution at a time
  • Record notes or your discussions will not impact policy

Notes

  • The full list of issues is here.
  • If you opened this in Edit mode and it’s now Read Only, there are probably too many editors right now (max is 50). In that case, use this supplemental page to capture your solutions to this issue. Notes from all supplemental pages will be moved to the main page for that issue after the summit.

Description of the Issue

There are two issues that need to be addressed:

Proposed Solution #1: Drop NOSA in favor of a more “standard” license

As was explained in the talk earlier, the NOSA is not a well respected license by the Open Source community. It should be dropped in favor of a more standard one, such as the GPL. Further, apply whatever new license that was selected to new releases of previously NOSA’d software.

Proposed Solution #2: [NOSA was developed for releasing software that is complete. Need another policy and licensing for unfinished or in-progress development.]

Need another NASA policy that addresses licensing options for iterative software development with a community that includes non-NASA workforce.

Proposed Solution #3: Be aware of licensed software within other OSS software (e.g., a piece of OSS software that has a module within it under a different license).

Since some OSS licenses are incompatible, this is something of which to be aware. Especially when some licenses limit distribution.

Proposed Solution #4: Approve a subset of OSI-approved licenses for NASA use

BSD, MIT, etc. are not very restrictive. LGPL may be a bridge too far, although it will defend the community. The restrictions these provide can ensure the long-term viability of the project.

Proposed Solution #5: Provide a one stop shop for current (and to be established) NASA guidance with regards to licensing open source software

Provide a comprehensive source of the current regulations and restrictions.  Perhaps capturing the concerns and suggestions here and links for assistance for those at the agency entering the process for the first time.

Proposed Solution #6: [Title]

[Description of Proposed Solution]

Proposed Solution #7: [Title]

[Description of Proposed Solution]

Proposed Solution #8: [Title]

[Description of Proposed Solution]

Proposed Solution #9: [Title]

[Description of Proposed Solution]

Proposed Solution #10: [Title]

[Description of Proposed Solution]


The following needs to be sorted & folded into the above...

Some OS is released under multiple licenses

  - when is this good?

  - what are the implications of this?

  - can NASA release software under NOSA *and* Apache 2 *and* GPL 3...

Use of GPL

  - one approach: don't develop with GPL stuff

Use of NOSA

  - create a FAQ to help explain what you can/cannot do with it? give

        specific examples

        - can I use the software for derivative commercial work?

        - can I bundle the software?

        - can I combine NOSA work with software under different licenses?

  - create case studies

  - explain background / goals / rational

        - why was NOSA created?

        - what specific things does it cover (for NASA) that other licenses do not?

  - LGPL: license part is small, most of it is explanation of why it

        was created and what it is used for?

  - NOSA was originally developed for release, not community OS

        development, alot has changed over the past few years, so perhaps

        should determine how NOSA should evolve to fit new needs

  - need to reduce the barrier to use of NASA OS that is released under NOSA

        (right now, many people say "NOSA? What's that? If I have to spend

        the time / legal effort to understand it, then the barrier is too

        high for me to use it)

Licenses are like software

  - GPL, Apache 2 have had many, many eyes looking at it (i.e., testers,

        just like OS software that has been tested over and over)

  - if you don't have software that people want to use and reuse, then

        they will not look at your license

How licenses support community development

  - three processes, all of which might require different license

        - building community

        - developing materials (software)

        - maintaining & bringing back

  - in order to accept (& use) third-party contributions, need a CLA.

        - CLA tied to license, so if the license is not understood (or prevents

          certain use), then contributor will not sign the CLA

        - so, for NASA to support OS *development* need to solve the license

          issue *and* the CLA issue

        - Q: would NASA be willing to use an existing CLA (not invent their own)

          --> Learn more about the proposed “Harmony CLAs” that are being developed

      that might help.  (mentioned by Gil Yehuda, Director of Open Source at Yahoo)

        → See also the Fedora CLA, the GNU contributor agreement, and


DARPA F6 project is requiring use of MIT license for all software

Limitations of NOSA?

  - NOSA was originally developed (2003) in a different environment, for

        releasing software in-house to a point-release

  - now, the landscape is different, so may need to improve its use for

        release

  - question: how can NASA get involved with development (from the beginning)

  - NOSA was never intended for a continuous development process

NOSA is considered to be a "special purpose license" by OSI. Why is this?

What is needed for NASA to be able to use a suite of licenses (Apache 2,

  GPL 3, etc.) for release?

  - Have NASA review OSI licenses and determine which ones would be

        "NASA compliant" (i.e., takes into consideration those things

        that are important to NASA and must be covered)

  - Which of the OSI licenses can be used by NASA? This is the same

        as large corporations

  - this would allow us to participate in OS development projects (i.e.,

        ones that use licenses from the approved list)

  - this would allow us to start a new OS community development project

Who creates software policy within NASA?

  - Owned by the NASA Office of Chief Engineer

  - NPR2210 was originally conceived as a tech transfer mechanism, and

        not a development mechanism

  - NPR2210 is owned by Office of Chief Technologist