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. <nigel.tz...@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
_______________________________________________ License-discuss mailing list License-discuss@opensource.org https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss