Luis (as usual, take with a grain of salt since I'm very much the newbie here)

If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster@..., and do not use or disseminate such information.  Pursuant to IRS Circular 230, any tax advice in this email may not be used to avoid tax penalties or to promote, market or recommend any matter herein.

From: spdx-legal-bounces@... [mailto:spdx-legal-bounces@...] On Behalf Of Wheeler, David A
Sent: Thursday, March 15, 2012 4:33 PM
To: 'spdx-legal@...'
Subject: Add license entry/entries for U.S. Government Works to SPDX

I propose adding SPDX entries for “U.S. Government Works”.  I talked with a few people about this on March 7, and they seemed positive about the general idea (I realize the complications are always in the details).

 

So here is my specific proposal, based on that earlier discussion.  In particular, I suggest adding at *least* US-GOVERNMENT-WORK to SPDX, and I think it’d be best to also add US-GOVERNMENT-WORK-FOREIGN-COPYRIGHT and US-GOVERNMENT-WORK-NO-FOREIGN-COPYRIGHT (which are like standard “riders”).  Background & the proposal itself are below.

 

BACKGROUND

 

First, here’s some background.  The U.S. federal government spends a large amount of money each year to develop and modify software.  Most of this is done through contractors, but a non-negligible amount of software development (including changes) is done by U.S. federal government employees as part of their official duties.  Some examples of this kind of OSS include “expect” (a common utility program that’s probably in every Linux distribution repository), “VistA” (not Windows, but the software that supports day-to-day operations at local Department of Veterans Affairs health care facilities), and significant portions of security-enhanced Linux (as used in Red Hat Enterprise Linux and Fedora, among others).  This isn’t hypothetical; this happens NOW.

 

But this kind of software is under a different legal regime than other software, leading to a need for a different SPDX identifier.  Under U.S. law, ”Copyright protection under this title is not available for any work of the United States Government” (17 USC § 105), and “A ‘work of the United States Government’ is a work prepared by an officer or employee of the United States Government as part of that person’s official duties.” (17 USC § 101).    Typically no “license” text is distributed with the code itself.  But there *is* a need to indicate that some software is in this particular situation.

 

PROPOSAL

 

So I propose that SPDX add at least the name “US-GOVERNMENT-WORK” (or similar), to indicate software that is a U.S. federal government work as defined under U.S. law.  In this case, it’s an *absence* of copyright (at least in the US), not its presence, but it is still valuable to indicate its license status.  For the ‘license’ text, I recommend simply quoting U.S. law; it’s clearly authoritative within the US, and it’s the US federal government’s own work.  So I suggest that the “license” text be as follows:

This software, or portions of it, are a U.S. government work.

Copyright protection under this title is not available for any work of the United States Government. (17 USC § 105)

A “work of the United States Government” is a work prepared by an officer or employee of the United States Government as part of that person’s official duties.” (17 USC § 101)

 

There are two challenges I see; let me try to address them.

 

First, there isn’t an official standard “header text” that indicates this circumstance either. This is part of the larger problem that very often the government and public have lots of rights, but cannot determine that they do. See “[CENDI GUESSING]” below which bewails this.  My hope is that SPDX could help solve this; if there is an easy, standardized way to notate legal circumstance, it’s more likely to be notated.  That said, [CENDI FAQ 2008] section 3.1.8 gives header text that was developed and recommended by a team of US government lawyers, and it’s used directly by [CENDI GUESSING] among others.  Thus, I suggest using that as the “standard” header text that people should look for.  Later on you might allow some alternative wording as well, but they’d only be in addition to this.  Here’s that standard header text:

This is a work of the U.S. Government and is not subject to copyright protection in the United States. Foreign copyrights may apply.

 

The second challenge is hinted at by the text above. Although the U.S. government cannot copyright a U.S. government work in the U.S., it CAN assert copyrights in foreign countries if it chooses to do so.  See [CENDI FAQ 2008] #3.1.7, which says, “Copyright is sometimes asserted by U.S. Government agencies outside the United States.”  Most of the time the U.S. government does NOT assert copyright outside the US, but there is usually NO WAY for a recipient to determine if this is the case or not.  So really have 3 cases:

1. US government has asserted copyright outside the US.

2. US government asserts that it will NOT assert copyright outside the US.

3. No evidence has been found for any particular assertion either way (the common case).

Yes, that’s a mess in many cases.  But SPDX can help us, by giving us a clear way to describe which case applies to some given software.  These fine license distinctions are exactly like the “riders” that apply to many licenses like the GPL (e.g., “GPL with classpath exception”). So the SPDX rider mechanism can be easily used to handle this distinction.

 

With that, I propose three SPDX license names:

1. US-GOVERNMENT-WORK-FOREIGN-COPYRIGHT: US government work per 17 USC § 105, foreign copyright asserted.  I know of no standard header text for this, but there’s an obvious derivative: “This is a work of the U.S. Government and is not subject to copyright protection in the United States. Foreign copyrights apply.”

2. US-GOVERNMENT-WORK-NO-FOREIGN-COPYRIGHT: US government work per 17 USC § 105, with assertion by the US government that they will not assert any foreign copyright.  Again, there’s no standard header text, but there’s an obvious derivative: “This is a work of the U.S. Government and is not subject to copyright protection in the United States. Foreign copyrights do not apply.”

3. US-GOVERNMENT-WORK: US government work per 17 USC § 105, but no evidence has been identified for either of the more specific assertions above. Again, this is the common case.  Use the header text I already listed above.  This category could be refined still further, e.g., a subcategory meaning “no one knows” and another meaning “the organization hasn’t decided either way”.  But I don’t think it’s important to refine this further, as the difference is basically irrelevant to recipients; no matter what, recipients have to hunt for more information if it matters, including contacting the US government if they can.

 

In practice, people treat US-GOVERNMENT-WORK as I’ve defined above exactly like US-GOVERNMENT-WORK-NO-FOREIGN-COPYRIGHT.  That is sloppy but it is not my fault!  At the least, a recipient who has this marking knows that they certainly *can* do a lot of things in the US, and that there are potential issues outside the US.  For example, someone could receive software marked US-GOVERNMENT-WORK, do Google searches and other analysis to see if there’s a foreign copyright assertion, and if not, record that they believe the license is actually . US-GOVERNMENT-WORK-NO-FOREIGN-COPYRIGHT (along with the rationale).  This would make the SPDX names quite useful; it would give an analyst a place to start, as well as indicating what kind of analysis may need to be done.

 

SPDX cannot solve all the weirdness of US law… nor does it need to.  Simply making it clear what is known… and in some cases, what is not… is very valuable.

 

We also had a discussion about the term (copyright) “public domain”.  I understand why the SPDX developers want their terms to be more precise… I think that makes sense.  So I’d suggest that SPDX work on creating precise definitions for things like US-GOVERNMENT-WORK-NO-FOREIGN-COPYRIGHT and CC0, and people (SPDX or others) can define broad categories like “permissive” or “copyright public domain” or “strongly protective”.  Then, SPDX’s specific licenses can be examined to see which ones meet the definitions of broader categories.  But that means that SPDX has to include, in its list, enough common specific definitions so that this crosswalk can be useful.

 

In any case, it’s important that SPDX have a way to notate these cases, so this is a proposal to make it happen.

 

===================================

 

For more information, see:

 

[17 USC § 105]

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.copyright.gov/title17/92chap1.pdf#Section106

 

 

[17 USC § 101]

A “work of the United States Government” is a work prepared by an officer or

employee of the United States Government as part of that person’s official duties.

 

[CENDI GUESSING]

CENDI. “DON’T KEEP THE PUBLIC GUESSING: BEST PRACTICES IN NOTICE OF COPYRIGHT AND TERMS & CONDITIONS OF USE FOR GOVERNMENT WEB SITE CONTENT”

CENDI 2004/4

http://www.cendi.gov/publications/04-4website_policy.html

 

[CENDI FAQ Software]

CENDI. “Frequently Asked Questions about Copyright and Computer Software: Issues Affecting the U.S. Government with Special Emphasis on Open Source Software”, revised Oct 1, 2010, http://www.cendi.gov/publications/09-1FAQ_OpenSourceSoftware_FINAL_110109.pdf

 

[CENDI FAQ 2008]

CENDI. “Frequently Asked Questions About Copyright Issues Affecting the U.S. Government”. CENDI/2008-1. October 8, 2008 http://www.cendi.gov/publications/04-8copyright.html

In particular, see its section 3.

 

[DoD OSS FAQ]

DoD CIO.

“DoD Open Source Software (OSS) FAQ”

http://dodcio.defense.gov/sites/oss/Open_Source_Software_%28OSS%29_FAQ.htm

 

CENDI is an interagency working group of senior scientific and technical information (STI) managers from 12 U.S. federal agencies; they provide a lot of cross-US-government guidelines in these kinds of matters. CENDI has a number of related publications, see: http://www.cendi.gov/publications/