[I don't think my previous message on code.mil got through moderation (sent by incorrect address); re-sending this one, though now that we're on the topic of code.mil contribution policies and license minutiae we're already most of the way to the end. but...]

For discussion purposes (as I consider the right license to be very important) here's a response from my colleague (who used to work with the Software Freedom Law Center) posted here without further comment:

"Seems like a reasonable choice, every situation is different but there really isn't much difference between a BSD license and a MIT license in most cases.

It may not matter to his decision, but he may be misunderstanding the code.mil stuff slightly though. He is correct that it is treating non-US copyrights slightly differently, but only to the extent that the U.S. government can actually claim copyrights in at least some foreign jurisdictions. Copyright is a right granted country by country so for example when a private person writes a book they are essentially simultaneously, but independently, granted a U.S. copyright in the book and a separate Canadian copyright in the same book.

But as a matter of US law, when the US government authors, via its *employees*, a book the U.S. government is not in the typical case granted a copyright in the book in the U.S.. Whether the U.S. government is granted a Canadian copyright is a matter of Canadian law and a separate legal question.

A related point of confusion might be that if the U.S. government contracts with a independent contractor to write a book then the typical case is that the independent contractor as the author would have a copyright in the book; both in the U.S. (and presumably in Canada. But again that depends on Canadian law.) Now it might be that the U.S. government requires the contractor to assign the copyright to the U.S. government but in that case the U.S. government would actually own the U.S. copyright in the book. Any required assignments would be part of the contract between the independent contractor and the u.s. government.

It is not true that when the U.S. government hires a independent contractor to produce a book that there is no copyright in the book. Just the opposite is typically true.

The details will depend on the contracts involved. But a U.S. government contractor can typically assert a copyright over a work the U.S. government paid to have produced. But again contracts may change the default rules.

It looks like they are going with the 3 clause BSD license. But they discuss the 4 clause. They should keep in mind another reason NOT to use the 4-clause is that it is generally regarded as incompatible with the GPL.

If he is concerned about getting credit where credit is due, the GPL or other copyleft license, such as the LGPL, might be a better choice then the 4 or 3 clause license. If I recall correctly some of the code.mil stuff mentions wanting to have the option to use the GPL, but they still had questions about it. But they do not say it can't be used. But again the federal government sits in a different situation then its independent contractors so code.mil may have different concerns as a government agency. But Section 7 of the GPLv3 allows some additional restrictions that might serve similar functions to the no endorsement clause of the 3 clause BSD license. Or at least allow the inclusion of a required non endorsement clause from a contract.

Red Hat legal or a private attorney, such as SFLC, might be able to tell him how this all applies to his situation."


Leaning towards BSD-3 (vs MIT). Here's a synopsis of both:
https://opensource.stackexchange.com/questions/217/what-are-the-essential-differences-between-bsd-and-mit-licences

And the language:
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution

3. Neither the name of [the organization] nor the names of its contributors may be used to endorse or promote products derived from this software without specific written permission.

Reasoning for BSD-3 (up for discussion, of course!):

- Managers of US Gov employees/contractors freak out over contributing back to open source. Some worry their contributions will be seen as an endorsement. BSD-3 explicitly says contributions are not an endorsement. And it prevents downstream from making statements like "our content was co-developed by Lockheed, Red Hat, and NSA!" without written permission from those groups.

- SSG content is redistributed by the US Government, for example through NIST's National Checklist Program. When we signed the legal paperwork for the NIST partnership, Red Hat (on behalf of SSG community) had to accept certain terms. Ref clause 7 of [0]:

"You may not use the name of NIST or the Department of Commerce on any advertisement, product, or service that is directly or indirectly related to this agreement. By accepting this agreement, NIST does not directly or indirectly endorse any product or service provided, or to be provided, by you, your successors, assignees, or licensees. You may not in any way imply that this agreement is an endorsement of any such product or service. You may not combine use of the logo with other Marks, phrases, or logos in such a way that would imply endorsement by NIST"

BSD-3 helps re-enforce reinforce downstream "assignees," aka people who package upstream in their own offerings, cannot claim endorsement by anyone contributing upstream. I recognize I'm likely being super paranoid about this. But I don't care. We've built a lot of trust with NIST, NSA, and others that must be preserved.

I not-so-secretly really want BSD-4, which would add:
All advertizing materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the OpenSCAP Community.
.... but that is really me trying to get (force?) people to acknowledge when OpenSCAP/SSG is embedded into their tech. Have (infrequently) ran into situations where someone claimed they owned complete development of some SCAP content... only to find SSG people in their git logs  (╯°□°)╯︵ ┻━┻



[0] http://people.redhat.com/swells/PublicPoliciesAndAgreements/RHT%20Executed%20-%20NIST%20Appendix%20D.pdf

_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org