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 <[email protected]> wrote: > > > On 7/26/17 4:26 AM, [email protected] 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 > >
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
