[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.civ at 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. <Nigel.Tzeng at jhuapl.edu>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20170901/3386b1cb/attachment.html>