Hi All,
I'm sending you that little e-mail because i'm confronted to a specific license constraint while i have to declare my personal work as i'm working for French government. My manager told me that in France i can't declare my contribution as being in the public domain as the french civil code doesn't permit an author to completely loose all the copyright of a given content (not for the public domain, which can be reach only after years). What is possible is to use a very permissive license such as BSD-2 clause license for my work.
Do you think, as it's already done for some of the SSG files copyrighted by Red-Hat, to set a BSD-2 clause copyright to the Debian/ and Ubuntu/ dir ? Maybe reducing them to the lonely content i write (and not the whole dir content, which contains files that have also be written by others) would be better ?
Thanks !
On 7/18/17 11:39 AM, phil@reseau-libre.net wrote:
Hi All,
I'm sending you that little e-mail because i'm confronted to a specific license constraint while i have to declare my personal work as i'm working for French government. My manager told me that in France i can't declare my contribution as being in the public domain as the french civil code doesn't permit an author to completely loose all the copyright of a given content (not for the public domain, which can be reach only after years). What is possible is to use a very permissive license such as BSD-2 clause license for my work.
Do you think, as it's already done for some of the SSG files copyrighted by Red-Hat, to set a BSD-2 clause copyright to the Debian/ and Ubuntu/ dir ? Maybe reducing them to the lonely content i write (and not the whole dir content, which contains files that have also be written by others) would be better ?
SSG is Public Domain because of original co-sponsorship from the US Government (specifically, NSA). In the US, Government employees and contractors have no claims to intellectual property and must use public domain. Over time, Public Domain has accelerated contributions from other US Gov agencies and contractors (Lockheed, Northrup, etc) because they don't need special approvals to collaborate.
I'm not sure how dual-licensing content (RHEL vs Deb) would work for downstream releases in RHEL(+derivatives) and Ubuntu. Can packages be dual licensed?
p.s. while OpenSCAP tooling is LGPL [0], SSG is entirely Public Domain [1]. This has caused some issues in the past when proprietary companies took SSG and re-branded as their own content.... so there is definite interest in licensing to something that requires attribution.
Martin: This has come up before, and you suggested there was a Public Domain variant that is more acceptable to the international community?
Alternatively, could the Creative Commons licensing work? e.g. - https://wiki.creativecommons.org/wiki/Public_domain - https://wiki.creativecommons.org/wiki/CC0
[0] https://github.com/OpenSCAP/openscap/blob/maint-1.2/COPYING [1] https://github.com/OpenSCAP/scap-security-guide/blob/master/LICENSE
On 2017-07-19 18:08, Shawn Wells wrote:
SSG is Public Domain because of original co-sponsorship from the US Government (specifically, NSA). In the US, Government employees and contractors have no claims to intellectual property and must use public domain. Over time, Public Domain has accelerated contributions from other US Gov agencies and contractors (Lockheed, Northrup, etc) because they don't need special approvals to collaborate.
I'm not sure how dual-licensing content (RHEL vs Deb) would work for downstream releases in RHEL(+derivatives) and Ubuntu. Can packages be dual licensed?
For Debian & derivatives it can, while the debian/copyright file is properly written.
p.s. while OpenSCAP tooling is LGPL [0], SSG is entirely Public Domain [1]. This has caused some issues in the past when proprietary companies took SSG and re-branded as their own content.... so there is definite interest in licensing to something that requires attribution.
Martin: This has come up before, and you suggested there was a Public Domain variant that is more acceptable to the international community?
Alternatively, could the Creative Commons licensing work? e.g.
After taking a look to CC0, will have the same problem (i.e. can't release the copyright): https://en.wikipedia.org/wiki/Copyright_law_of_France That's why i proposed BSD-1-clause, which seems the simpliest (and the less restrictive) licencing for these files.
[0] https://github.com/OpenSCAP/openscap/blob/maint-1.2/COPYING [1] https://github.com/OpenSCAP/scap-security-guide/blob/master/LICENSE _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
On 7/21/17 11:02 AM, phil@reseau-libre.net wrote:
On 2017-07-19 18:08, Shawn Wells wrote:
SSG is Public Domain because of original co-sponsorship from the US Government (specifically, NSA). In the US, Government employees and contractors have no claims to intellectual property and must use public domain. Over time, Public Domain has accelerated contributions from other US Gov agencies and contractors (Lockheed, Northrup, etc) because they don't need special approvals to collaborate.
I'm not sure how dual-licensing content (RHEL vs Deb) would work for downstream releases in RHEL(+derivatives) and Ubuntu. Can packages be dual licensed?
For Debian & derivatives it can, while the debian/copyright file is properly written.
p.s. while OpenSCAP tooling is LGPL [0], SSG is entirely Public Domain [1]. This has caused some issues in the past when proprietary companies took SSG and re-branded as their own content.... so there is definite interest in licensing to something that requires attribution.
Martin: This has come up before, and you suggested there was a Public Domain variant that is more acceptable to the international community?
Alternatively, could the Creative Commons licensing work? e.g.
After taking a look to CC0, will have the same problem (i.e. can't release the copyright): https://en.wikipedia.org/wiki/Copyright_law_of_France That's why i proposed BSD-1-clause, which seems the simpliest (and the less restrictive) licencing for these files.
Personally I've no idea how to handle this, so I asked members of Red Hat's legal team for help.
Also sent a note requesting feedback from other Red Hat members who work on international FOSS projects on how they've handled this. Will report back.
Le 22/07/2017 à 05:48, Shawn Wells a écrit :
Personally I've no idea how to handle this, so I asked members of Red Hat's legal team for help.
Also sent a note requesting feedback from other Red Hat members who work on international FOSS projects on how they've handled this. Will report back.
Ok. Thank you for that !
On 7/22/17 2:46 AM, Philippe Thierry wrote:
Le 22/07/2017 à 05:48, Shawn Wells a écrit :
Personally I've no idea how to handle this, so I asked members of Red Hat's legal team for help.
Also sent a note requesting feedback from other Red Hat members who work on international FOSS projects on how they've handled this. Will report back.
Ok. Thank you for that !
Turns out Red Hat has an open source legal affairs team, chartered with helping projects tackle issues like this. Have connected with them -- but nothing to report back yet.
On 7/25/17 5:14 PM, Shawn Wells wrote:
On 7/22/17 2:46 AM, Philippe Thierry wrote:
Le 22/07/2017 à 05:48, Shawn Wells a écrit :
Personally I've no idea how to handle this, so I asked members of Red Hat's legal team for help.
Also sent a note requesting feedback from other Red Hat members who work on international FOSS projects on how they've handled this. Will report back.
Ok. Thank you for that !
Turns out Red Hat has an open source legal affairs team, chartered with helping projects tackle issues like this. Have connected with them -- but nothing to report back yet.
Comments from that team:
Shawn, there are a lot of potential approaches here, but one I'd recommend is what DoD code.mil is doing. See: https://github.com/deptofdefense/code.mil
The idea is basically this: A project will generally start out with public domain code in the US (to the extent it has been created by federal civil servants). But the project will designate a true open source license at the outset, such as GPLv3 or the Apache License 2.0 or what have you, and the project will use the Developer Certificate of Origin with the understanding that non-civil-servant contributors are agreeing to license in their contributions under the designated open source license. Over time the project becomes a mix of (a) federal civil servant code that is public domain in the US, (b) federal civil servant code that is under the designated project license outside the US, and (c) code from other contributors that is under the designated project license.
As further explanation, note that the statement that US government employees "cannot hold intellectual property" is not correct. What is true is that in the US Copyright Act, works by federal civil servants in the scope of employment are outside the scope of copyright - i.e., public domain. However, it is generally agreed that this has no applicability to works published outside the US. Software today is generally published simultaneously in multiple jurisdictions (for example, the SCAP Security Guide, by being published on GitHub, is published internationally in multiple countries).
I have a contact who is a lawyer for the code.mil people who may be able to help if there is interest in this approach.
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?
https://github.com/deptofdefense/code.mil
IIRC: 1) We add https://github.com/deptofdefense/code.mil/blob/master/Proposal/INTENT.md 2) CONTRIBUTING gets updated to look like this: https://github.com/deptofdefense/code.mil/blob/master/Proposal/CONTRIBUTING.... 3) CONTRIBUTORS.md gets updated to look like this: https://github.com/deptofdefense/code.mil/blob/master/Proposal/CONTRIBUTORS.... 3) We pick a new license that best serves the community
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.
On 7/26/17 4:26 AM, phil@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.
Leaning towards BSD-3 (vs MIT). Here's a synopsis of both: https://opensource.stackexchange.com/questions/217/what-are-the-essential-di...
And the language:
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- 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
- 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%2...
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@redhat.com wrote:
On 7/26/17 4:26 AM, phil@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:
- Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
- 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
- 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
[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:
- Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
- 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
- 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
On 7/27/17 12:38 AM, Fen Labalme wrote:
[I don't think my previous message on code.mil http://code.mil got through moderation (sent by incorrect address); re-sending this one, though now that we're on the topic of code.mil http://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 http://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 http://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 http://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."
So he's saying the DoD legal guidance is wrong? I don't understand.
Packages can have as many licenses as you want (in RPMs at least) https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/Li...
Trevor
On Fri, Jul 21, 2017 at 11:48 PM, Shawn Wells shawn@redhat.com wrote:
On 7/21/17 11:02 AM, phil@reseau-libre.net wrote:
On 2017-07-19 18:08, Shawn Wells wrote:
SSG is Public Domain because of original co-sponsorship from the US Government (specifically, NSA). In the US, Government employees and contractors have no claims to intellectual property and must use public domain. Over time, Public Domain has accelerated contributions from other US Gov agencies and contractors (Lockheed, Northrup, etc) because they don't need special approvals to collaborate.
I'm not sure how dual-licensing content (RHEL vs Deb) would work for downstream releases in RHEL(+derivatives) and Ubuntu. Can packages be dual licensed?
For Debian & derivatives it can, while the debian/copyright file is properly written.
p.s. while OpenSCAP tooling is LGPL [0], SSG is entirely Public Domain [1]. This has caused some issues in the past when proprietary companies took SSG and re-branded as their own content.... so there is definite interest in licensing to something that requires attribution.
Martin: This has come up before, and you suggested there was a Public Domain variant that is more acceptable to the international community?
Alternatively, could the Creative Commons licensing work? e.g.
After taking a look to CC0, will have the same problem (i.e. can't release the copyright): https://en.wikipedia.org/wiki/Copyright_law_of_France That's why i proposed BSD-1-clause, which seems the simpliest (and the less restrictive) licencing for these files.
Personally I've no idea how to handle this, so I asked members of Red Hat's legal team for help.
Also sent a note requesting feedback from other Red Hat members who work on international FOSS projects on how they've handled this. Will report back.
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@lists.fedorahosted.org
-
Fen Labalme -
Gabe Alford -
phil＠reseau-libre.net -
Philippe Thierry
-
Shawn Wells -
Trevor Vaughan