For ex, say your org or company is developing GOTS code and you want to release it. When it comes to namespaces or package structure, what do you do?
NASA World Wind uses a gov.nasa.x package structure (and a government copyright, which I thought was problematic for some reason) and FalconView uses a GaTech copyright.
We want to eventually release a few things (using our co's copyright) but insure whether a gov.something namespace/package is a good idea or not.
Just curious what others have done or plan to do.
Thanks!
Andy
Sent from my iPhone
> --
> You received this message because you are subscribed to the "Military Open Source Software" Google Group.
> To post to this group, send email to mil...@googlegroups.com
> To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
>
> www.mil-oss.org
-----------------------------------------------------------
John Scott
240.401.6574
< jms...@gmail.com >
http://powdermonkey.blogs.com
@johnmscott
Have you joined MIL-OSS?:
http://groups.google.com/group/mil-oss
http://mil-oss.org/
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
"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. "
If so, do you happen to have a citation? If not, perhaps NASA only
thinks they can.
Miles Fidelman
In order to satisfy the subsequent [citation needed] that is forthcoming:
A quick googling says "FAR 52.227-14, as modified by NFS 1852.227-14, allows NASA to control copyright in work created under NASA contract."
-ben
Classification: UNCLASSIFIED
Caveats: NONE
> Ok... which goes back to: There's a difference between "work of the United States Government" (created by Government employees, on Government time), which is not copyrightable per 17 USC 105, and by a contractor, where copyright is owned by the contractor, with licensing dictated by contract. (Note that some of us are old enough to remember the days when, if the Government paid for it, it went directly into the public domain).
The other detail devil there, though, is that 17 USC 105 only precludes the U.S. Government from _U.S._ copyright protection. Not only can the Gov't be assigned copyright, but they can make copyright protection claims in other countries.
I've always thought that such claims would be dubiously enforceable at a state-level, but I've encountered numerous closed Gov't codes over the years asserting that right. Prior to open source, when BRL-CAD was distributed under contract terms, it included the following statement throughout the sources:
* This software is Copyright (C) 2000 by the United States Army in all countries except the USA. All rights reserved.
As for Nasa, NFS 1852.227-14 is very interesting because it was originally described to me as NASA being given authority by congress to claim copyright on their works. That clearly isn't what NFS 1852.227-14 says [1] now that I read it. Unless there is some other clause, NASA already had the ability to require assignment from their contractors. This just defaults their authority to require copyright assignment at their whim.
Cheers!
Sean
maybe in the space act?
On Feb 13, 2012, at 10:51 AM, Miles Fidelman wrote:
Package name, repository placement, and copyright are all different things. Here are some comments about these, and by "some comments" I mean "a ridiculously long reply that I hope answers your question and several other questions you haven't thought of yet" :-).
Let's dive in...!
As far as giving a package a *name*, that's harder than you might think. I recommend creating a completely *unique* name, since that makes your program easy to find. (If you Google, and find nothing, it's unique.) Also, the name should be related to what it does (e.g., "flawfinder" is a program that searches for vulnerabilities, aka flaws, in source code). A counter-example is the "why" program, a useful program with a completely unfindable name :-(.
Regarding repository *placement*... there are pros and cons to all options. I see three possibilities: Generic commercial hosts for OSS projects (e.g., Sourceforge), government (.gov/.mil) sites, and contractor sites. There are lots commercially-available OSS hosting sites like gitorious, github, Sourceforge, and so on, that are free for use. If they meet your needs, then you probably shouldn't spend time and money redoing them, and using them makes it easier to get commercial contributions. That said, many bigger projects do set up their own infrastructure (using OSS components), since that simplifies things when you have lots of custom needs or you need to deal with export control staging. If the government really intends to maintain the project, there are probably advantages to putting them in the .gov namespace. There big disadvantages to the government if a project is hosted on a *contractor* site, especially if they are for-profit contractor, since that can make changing the project leadership unnecessarily difficult.
Copyright is a different beast. If a government employee does it as part of his/her official duties, it is not subject to copyright in the US (17 USC 105). It can be copyrighted outside the US (though few do that), but those can only be enforced there (!). If you want to be technical, there are a few VERY narrow exceptions for government employees of NIST and the US Postal Service, but these exceptions are so narrow that they're normally not even worth mentioning. A general treatise on government and copyright is here: http://www.cendi.gov/publications/04-8copyright.html
Contractors are a different story; if a contractor wrote it, it's copyrighted. However, who ends up with which rights depends on the contract.
NASA is *not* an exception, it's still a government agency. If a NASA government employee writes code as part of his official duties, it is not subject to copyright in the US.
HOWEVER, for *contractors*, the default NASA contract is different from the usual FAR and DFARS clauses. The NASA FAR Supplement (NFS) 1852.227-14 (http://www.hq.nasa.gov/office/procurement/regs/5227.htm) gives NASA the right, under typical conditions, to demand that a contractor assert copyright and assign the copyright to the government. It says: " (ii) If the Government desires to obtain copyright in computer software first produced in the performance of this contract and permission has not been granted as set forth in paragraph (d)(3)(i) of this clause, the Contracting Officer may direct the contractor to assert, or authorize the assertion of, claim to copyright in such data and to assign, or obtain the assignment of, such copyright to the Government or its designated assignee. "
Note that this makes NASA's typical contractor clauses DIFFERENT from the default FAR and DFARS clauses (both have alternative clauses if the government wants the copyright, but you have to decide that before signing the contract - the typical contract doesn't have an "I can demand it later" clause).
Current NASA policies make it hard to use anything other than the nasty "NOSA" license, unfortunately; I hope that will change.
The basic decoder ring for rights is here, though it doesn't discuss NASA specifically:
"Publicly Releasing Open Source Software Developed for the U.S. Government"
http://journal.thedacs.com/issue/56/180
--- David A. Wheeler
Andy Ennamorato:
> Curious what others do regarding naming and copyrighting open source/GOTS products.Package name, repository placement, and copyright are all different things. Here are some comments about these, and by "some comments" I mean "a ridiculously long reply that I hope answers your question and several other questions you haven't thought of yet" :-).
> For ex, say your org or company is developing GOTS code and you want to release it. When it comes to namespaces or package structure, what do you do?
> NASA World Wind uses a gov.nasa.x package structure (and a government copyright, which I thought was problematic for some reason) and FalconView uses a GaTech copyright.
> We want to eventually release a few things (using our co's copyright) but insure whether a gov.something namespace/package is a good idea or not.
Let's dive in...!
As far as giving a package a *name*, that's harder than you might think. I recommend creating a completely *unique* name, since that makes your program easy to find. (If you Google, and find nothing, it's unique.) Also, the name should be related to what it does (e.g., "flawfinder" is a program that searches for vulnerabilities, aka flaws, in source code). A counter-example is the "why" program, a useful program with a completely unfindable name :-(.
Regarding repository *placement*... there are pros and cons to all options. I see three possibilities: Generic commercial hosts for OSS projects (e.g., Sourceforge), government (.gov/.mil) sites, and contractor sites. There are lots commercially-available OSS hosting sites like gitorious, github, Sourceforge, and so on, that are free for use. If they meet your needs, then you probably shouldn't spend time and money redoing them, and using them makes it easier to get commercial contributions. That said, many bigger projects do set up their own infrastructure (using OSS components), since that simplifies things when you have lots of custom needs or you need to deal with export control staging. If the government really intends to maintain the project, there are probably advantages to putting them in the .gov namespace. There big disadvantages to the government if a project is hosted on a *contractor* site, especially if they are for-profit contractor, since that can make changing the project leadership unnecessarily difficult.
Copyright is a different beast. If a government employee does it as part of his/her official duties, it is not subject to copyright in the US (17 USC 105). It can be copyrighted outside the US (though few do that), but those can only be enforced there (!). If you want to be technical, there are a few VERY narrow exceptions for government employees of NIST and the US Postal Service, but these exceptions are so narrow that they're normally not even worth mentioning. A general treatise on government and copyright is here: http://www.cendi.gov/publications/04-8copyright.html
Contractors are a different story; if a contractor wrote it, it's copyrighted. However, who ends up with which rights depends on the contract.
NASA is *not* an exception, it's still a government agency. If a NASA government employee writes code as part of his official duties, it is not subject to copyright in the US.
HOWEVER, for *contractors*, the default NASA contract is different from the usual FAR and DFARS clauses. The NASA FAR Supplement (NFS) 1852.227-14 (http://www.hq.nasa.gov/office/procurement/regs/5227.htm) gives NASA the right, under typical conditions, to demand that a contractor assert copyright and assign the copyright to the government. It says: " (ii) If the Government desires to obtain copyright in computer software first produced in the performance of this contract and permission has not been granted as set forth in paragraph (d)(3)(i) of this clause, the Contracting Officer may direct the contractor to assert, or authorize the assertion of, claim to copyright in such data and to assign, or obtain the assignment of, such copyright to the Government or its designated assignee. "
Note that this makes NASA's typical contractor clauses DIFFERENT from the default FAR and DFARS clauses (both have alternative clauses if the government wants the copyright, but you have to decide that before signing the contract - the typical contract doesn't have an "I can demand it later" clause).
Current NASA policies make it hard to use anything other than the nasty "NOSA" license, unfortunately; I hope that will change.
The basic decoder ring for rights is here, though it doesn't discuss NASA specifically:
"Publicly Releasing Open Source Software Developed for the U.S. Government"
http://journal.thedacs.com/issue/56/180
--- David A. Wheeler