[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