<div dir="ltr">Cem,<div><br></div><div>Your idea sounds very much like some of the things that the Defense Digital Service considered when they tried to figure out how they where going to deal with FOSS licenses. Now that they have formally published their <a href="http://code.mil">code.mil</a> site, I would suggest reviewing their approach and their FAQ. Specifically two questions:</div><div><br></div><div>1) What happened to the draft Defense Open Source Agreement? </div><div><a href="https://www.code.mil/frequently-asked-questions.html#what-happened-to-the-draft-defense-open-source-agreement">https://www.code.mil/frequently-asked-questions.html#what-happened-to-the-draft-defense-open-source-agreement</a></div><div><br></div><div>2) "How are you attaching licenses to your projects? Are they just public domain?"</div><div><a href="https://www.code.mil/frequently-asked-questions.html#how-are-you-attaching-licenses-to-your-projects-are-they-just-public-domain">https://www.code.mil/frequently-asked-questions.html#how-are-you-attaching-licenses-to-your-projects-are-they-just-public-domain</a><br></div><div><br></div><div>I am not trying to suggest what they did was ideal or perfect for all government agencies, but since you appear to have a similar concept in mind to what DDS originally conceived of for their Defense Open Source Agreement it might be a helpful starting place to work out with your internal counsel what your agency would like to do differently or the same. <br></div><div><br></div><div>DDS does not have a "meta-license" per se, but they did adopt a licensing strategy that seems to be pretty sensible and does not require creating a new license or dealing with contract law. DDS is taking the position that within the U.S. its code bases should be treated as FOSS since they are intentionally taking contributions from contractors only under FOSS licenses. Once that code becomes sufficiently intertwined with the government created code compliance with the license is essentially mandatory for the whole code base (even if the license does not technically apply to the government created portions). And outside of the U.S., DDS is taking the position that the government does have copyright and therefore can directly release the code under a FOSS license. I do not know if they explicitly have a strategy of incorporating third party FOSS libraries into their code, but that is another way of incorporating FOSS license obligations into a otherwise public domain code base. In many ways they are just doing the opposite of what SQLite is doing in its effort to put its code in the public domain.(<a href="https://sqlite.org/copyright.html">https://sqlite.org/copyright.html</a>). </div><div><br></div><div>From DDS's FAQ:<br></div><div><br></div><div>"The updated strategy in INTENT.md does not attempt to attach licenses to Government-written code. Rather, the strategy attaches the license to copyrighted contributions by using the Developer Certificate of Origin (DCO) process and to Government-written code in countries where that code is eligible for copyright protections."<br></div><div><br></div><div><div>Considering that FOSS is pretty international, and  Once a sufficient amount of third party contributions, or even just third party libraries, are incorporated into the code base, this seems like it is getting pretty close to just releasing code under a FOSS license as the Federal government can get. Anyone who wanted to take the position that they were only using the government written portions and were doing so only inside of the United States to avoid the FOSS license obligations would have a interesting compliance challenge.</div></div><div><br></div><div>Your agency might want to engage with a licensing consultant, a private FOSS attorney, or DDS to explore options that work for your agency. Although it feels like it on occasion, I don't believe this list is setup for designing a license, only to discuss existing ones. But I am relatively new, so perhaps I am wrong on that.</div><div><br></div><div>-Marc</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 16, 2018 at 5:34 PM Karan, Cem F CIV USARMY RDECOM ARL (US) <<a href="mailto:cem.f.karan.civ@mail.mil">cem.f.karan.civ@mail.mil</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">CLASSIFICATION: UNCLASSIFIED<br>
<br>
Hi all, as some of you know, I'm the guy at the US Army Research Laboratory that is trying to push forward our Open Source policy.  As a part of that, I've outlined my concerns on copyright-based licenses, and the need for the US government (USG) to have an Open Source license that will continue to work even on works that don't have copyright attached[1].  The NOSA agreement (not a license!  It's in its name!) tries to address this by avoiding copyright entirely.  But it occurred to me that not everyone in the USG (or elsewhere) is going to want to use NOSA; there are good reasons for using (for example) AGPLv3, or Apache 2.0, etc.  Which is why I came up with the thought that maybe it's time to come up with a meta-license.  The meta-license would be designed to do the following:<br>
<br>
1) Wrap any OSI-approved license transparently (the original license would not need to be changed to work with the meta-license).<br>
2) Add in a severability clause, making it clear that if any one clause was struck down by the courts, then the others still stand (maybe a good idea, maybe bad?  Thoughts?)<br>
3) Add in a new clause that makes it clear that for those portions of the covered work that don't have copyright attached, then the recipient of the code is agreeing to treat the material as if it had copyright for the purposes of the wrapped license.<br>
<br>
There are a number of issues with this idea:<br>
<br>
- I have no idea if this is even possible; I'm not a lawyer, and I'm not sure that monkey patching a license like this is possible.<br>
<br>
- I have no idea if it would be desirable by the community to do so.<br>
<br>
- I'm not sure if I've got all the right ideas in place; that is, would we need to add or remove anything to the meta-license?  If so, what?<br>
<br>
- Would it be compatible with all OSI-approved licenses?  If not, would there need to be a list of licenses it's approved to be used with?  How would that list be maintained and updated?  What if there are other, additional meta-licenses?  Could you mix and match them together and still have an Open Source license?<br>
<br>
- Would OSI approve the idea of a meta-license?<br>
<br>
I'm hoping for a constructive debate on this idea; if it worked, it could solve a fair number of problems (while creating a whole new set, no doubt! ;))<br>
<br>
Thanks,<br>
Cem Karan<br>
<br>
[1] Most US Government works do not have copyright within the jurisdication of the USA.  If a license has a clause in it that relies on copyright (most OSI-approved licenses seem to), a lawyer could argue in court that the clause is invalid under US law because USG works generally don't have copyright attached.  How does this affect the USG, and the wider community as a whole?  The problem is the legal notion of severability (<a href="https://en.wikipedia.org/wiki/Severability" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Severability</a>); most, if not all, OSI-approved licenses don't address what happens to the license as a whole if a single clause in the license is found to be unenforceable.  A court may decide that the other clauses still stand on their own, or it may decide that the entire license is null and void.   This includes those wonderful clauses about no liability or warranty, which could be very, very expensive in litigation.  What's more, downstream users of USG-furnished code could get attacked once the license is null and void (after all, it's how the USG is getting contributions from the outside, and malicious actors could try to sabotage USG Open Source via this route and FUD).  This could turn into a really ugly FUD campaign that I personally would rather avoid.  This is WHY I keep hammering on this issue.<br>
<br>
Thanks,<br>
Cem Karan<br>
<br>
---<br>
Other than quoted laws, regulations or officially published policies, the views expressed herein are not intended to be used as an authoritative state of the law nor do they reflect official positions of the U.S. Army, Department of Defense or U.S. Government.<br>
<br>
<br>
CLASSIFICATION: UNCLASSIFIED<br>
<br>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div>