[License-discuss] Wrapping OSI licenses (UNCLASSIFIED)

Sat Feb 17 00:34:27 UTC 2018

Cem,

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
code.mil site, I would suggest reviewing their approach and their FAQ.
Specifically two questions:

1) 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

2) "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

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.

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.(https://sqlite.org/copyright.html).

>From DDS's FAQ:

"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."

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.

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.

-Marc

On Fri, Feb 16, 2018 at 5:34 PM Karan, Cem F CIV USARMY RDECOM ARL (US) <
cem.f.karan.civ at mail.mil> wrote:

> CLASSIFICATION: UNCLASSIFIED
>
> 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:
>
> 1) Wrap any OSI-approved license transparently (the original license would
> not need to be changed to work with the meta-license).
> 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?)
> 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.
>
> There are a number of issues with this idea:
>
> - 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.
>
> - I have no idea if it would be desirable by the community to do so.
>
> - 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?
>
> - 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?
>
> - Would OSI approve the idea of a meta-license?
>
> 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!
> ;))
>
> Thanks,
> Cem Karan
>
> [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 (
> https://en.wikipedia.org/wiki/Severability); 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.
>
> Thanks,
> Cem Karan
>
> ---
> 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.
>
>
> CLASSIFICATION: UNCLASSIFIED
>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20180217/a2e696f3/attachment.html>