I say that if it works with Phil and others that we do BSD-4
Gabe
On Wed, Jul 26, 2017 at 5:44 PM, Shawn Wells <shawn(a)redhat.com> wrote:
On 7/26/17 4:26 AM, phil(a)reseau-libre.net wrote:
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
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.
fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@
lists.fedorahosted.org