Re: [License-discuss] (no subject)

[Ben Hilburn]

Hi all -

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.

On Fri, Sep 1, 2017 at 11:13 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) <
cem.f.karan@mail.mil> wrote:

> > I'm now encountering a slightly different situation in government, is
> there a way to ensure modifications and fixes are made available to
> > the originator in a limited distribution scenario? Something like a
> limited distribution GPL, but unlike before, there would be no non-
> > government contribution's copyright to piggyback off of.
>
> 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).
>

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.

Related - If you haven't yet, I highly recommend reading these two articles:
https://opensource.com/law/11/7/trouble-harmony-part-1
https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/

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.

On Fri, Sep 1, 2017 at 12:26 PM, Tzeng, Nigel H. 
wrote:

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

I like the UCL a lot, and I agree, the mechanism and license do seem
especially pertinent to this discussion.

Cheers,
Ben
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] (no subject)

[Tzeng, Nigel H.]

Tom,

I disagree that you can’t get useful adoption without contributions from 
non-federal entities.

The NASA WorldWind Java API project (https://worldwind.arc.nasa.gov) didn’t 
take in any external contributions for a very long time (if ever) but did see 
reasonably high adoption until Java desktop apps were largely replaced by 
webapps.  You can do cathedral development and release via a GOSS license 
(NOSA) and still provide significant value to the user community.

With an OSS license release I can “clone and own” moving forward and accept 
upstream changes as desired even if the upstream developer never takes any of 
our pull requests.  We leverage Core Flight Executive (cFE) from NASA Goddard 
in that manner.  Goddard uses cFE for their cFS flight system where we use cFE 
as the foundation of our own flight software system.

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.

If we used GPL, all the downstream modifications would be GPL.  If we pulled 
that back into the original project then it becomes potentially problematic for 
commercial performers to integrate in their proprietary code.

If we used Apache then the downstream modifications are not certain to be FOSS.

So downstream derivative modifications are virally permissive…I hope anyway as 
that was the intent.

Regards,

Nigel

From: License-discuss <license-discuss-boun...@opensource.org> on behalf of Tom 
Bereknyei <t...@dds.mil>
Reply-To: License Discuss <license-discuss@opensource.org>
Date: Friday, September 1, 2017 at 9:47 AM
To: License Discuss <license-discuss@opensource.org>
Subject: Re: [License-discuss] (no subject)

Cem,

Yes, only in the case of fully public domain do our approaches differ. Our view 
was that a project that never had a contribution from a non-federal entity 
would likely not reach a critical mass of adoption anyway. This isn't perfect, 
but the best we could come up with. I'm glad though that at least part of the 
problem has a clear path forward.

Anyone,

I'm now encountering a slightly different situation in government, is there a 
way to ensure modifications and fixes are made available to the originator in a 
limited distribution scenario? Something like a limited distribution GPL, but 
unlike before, there would be no non-government contribution's copyright to 
piggyback off of.
--
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil<mailto:t...@dds.mil>
(571) 225-1630<tel:%28571%29%20225-1630>
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] (no subject)

[Tom Bereknyei]

Cem,

Yes, only in the case of fully public domain do our approaches differ. Our
view was that a project that never had a contribution from a non-federal
entity would likely not reach a critical mass of adoption anyway. This
isn't perfect, but the best we could come up with. I'm glad though that at
least part of the problem has a clear path forward.

Anyone,

I'm now encountering a slightly different situation in government, is there
a way to ensure modifications and fixes are made available to the
originator in a limited distribution scenario? Something like a limited
distribution GPL, but unlike before, there would be no non-government
contribution's copyright to piggyback off of.
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
(571) 225-1630‬
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss