On
2017-07-26 02:59, Shawn Wells wrote:
Still reading/learning about the code.mil process, but it looks
like
it'll really help contributions from the non-US community. This
gives
US Gov employees/contractors what they need for Public Domain
protections, and non-US Gov people can follow an agreed license
like
MIT/GPL etc.
Added bonus: This might also be a way to solve a long-standing
gripe
about certain vendors using the SSG content without attribution.
Philippe: Can you review the code.mil process?
As far as i know, it would be perfect. This should resolve the
copyright problem for other countries like France.
It's even better if, as you said, it also resolve the problem of
vendors using SSG without attribution. However, maybe we can
decide of an unified Open-source license to avoid multiplicity of
licenses in the same project.
We can use BSD-3 (as described in [1], which is clearly
permissive), or license such as (L)GPL, which is more restrictive
depending on how the community which to protect itself against
vendors.
https://github.com/deptofdefense/code.mil
[1]
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