<div dir="ltr"><div><div><div><div>Hi all -</div><div><br></div><div>I figured I would throw in my thoughts for this discussion. IANAL and all of the usual disclaimers. My 
expertise, as it pertains to this thread, is really in the building 
& sustainment of F/OSS communities and projects, albeit outside of 
the government space.<br></div><br>On Fri, Sep 1, 2017 at 11:13 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) <span dir="ltr"><<a href="mailto:cem.f.karan.civ@mail.mil" target="_blank">cem.f.karan.civ@mail.mil</a>></span> wrote:<span class="gmail-m_2253395872215869758gmail-m_1299225116402926498gmail-"><br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_2253395872215869758gmail-m_1299225116402926498gmail-">
> I'm now encountering a slightly different situation in government, 
is there a way to ensure modifications and fixes are made available to</span><br><span class="gmail-m_2253395872215869758gmail-m_1299225116402926498gmail-">
> the originator in a limited distribution scenario? Something like a
 limited distribution GPL, but unlike before, there would be no non-</span><br><span class="gmail-m_2253395872215869758gmail-m_1299225116402926498gmail-">
> government contribution's copyright to piggyback off of.</span><br><span class="gmail-m_2253395872215869758gmail-m_1299225116402926498gmail-">
</span><br><span class="gmail-m_2253395872215869758gmail-m_1299225116402926498gmail-">
</span>If this is government-only, then it is possible to use various 
contract mechanisms to enforce what you want.  ARL has done this kind of
 thing for a long time now, and can share what we do with you directly 
(contact me off list).<br></blockquote>
<span class="gmail-m_2253395872215869758gmail-m_1299225116402926498gmail-"><br></span></div>In my 
experience, contracts are tremendous burden, both for individuals and 
organizations, and pose a significant barrier to both adoption and 
upstreaming. As an FSF maintainer of a large GNU project, I can tell you
 that even the FSF CLA causes significant issue for many groups, and 
outright inhibits growth of the developer community. I can't speak to 
how burdensome it is to get contracts signed within a government agency,
 but I have to imagine it is still burdensome. And requiring a contract 
for not just upstreaming, but adoption, in my opinion would cripple all 
but the largest projects.</div><div><br></div><div>Related - If you haven't yet, I highly recommend reading these two articles:</div><div style="margin-left:40px"><a href="https://opensource.com/law/11/7/trouble-harmony-part-1">https://opensource.com/law/11/7/trouble-harmony-part-1</a></div><div style="margin-left:40px"><a href="https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/">https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/</a><br></div><br></div>Have you seen something 
different at ARL? How have you worked things to be successful with your 
F/OSS projects and external groups? I'm really interested to learn more 
about your approach and the results you've seen.<br>
<br>On Fri, Sep 1, 2017 at 12:26 PM, Tzeng, Nigel H. <span dir="ltr"><<a href="mailto:Nigel.Tzeng@jhuapl.edu" target="_blank">Nigel.Tzeng@jhuapl.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">







<div bgcolor="white" lang="EN-US">
<div class="gmail-m_2253395872215869758gmail-m_1299225116402926498gmail-m_-532933352856991754WordSection1"><span style="font-size:11pt;font-family:Calibri"></span>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri">UCL
 (upstream compatibility license) was recently approved by the OSI. The 
original body of work is licensed UCL while all new derivative works 
must be licensed Apache.  It doesn’t force
 the downstream to provide the upstream developer with fixes and changes
 but if it’s put into an external repo the original upstream developer 
has rights to use the new work because of Apache.  The intent was if an 
entity (like say a federal agency) released
 a large completed project as open source that it could never get locked
 out of downstream modifications made by the OSS community.  The core 
code is always UCL and the new derivative changes are always Apache.</span></p></div></div></blockquote><div><br></div><div>I like the UCL a lot, and I agree, the mechanism and license do seem especially pertinent to this discussion.</div><div><br></div><div>Cheers,</div>Ben</div>