<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I wasn't going to bring it up but there is an approved special purpose license that may meet your needs.<div><br></div><div>UCL v1.0 (<a href="https://opensource.org/licenses/UCL-1.0">https://opensource.org/licenses/UCL-1.0</a>) is a copyleft license based on Laurence Rosen's OSL license (<a href="https://rosenlaw.com/OSL3.0-explained.htm">https://rosenlaw.com/OSL3.0-explained.htm</a>) with effectively a 1/2 line change where derivative works of the original must be dual licensed UCL and Apache and not just OSL.</div><div><br></div><div>You get the rough equivalent of a CLA since you can choose the apache license on any derivative work rather than use under the UCL license.</div><div><br></div><div>It is a special purpose license because only when a large body of work is open sourced for the first time is this license likely to be useful/chosen.  Unfortunately my sponsor ran out of funding before I could get them to release our project under UCL...now I have to do it the hard way so it's taking a while.</div><div><br></div><div><div>Wow, I just clicked on the UCL link and it appears all the formatting has disappeared for the license.  I can fix that if someone tells me whom to send an update to...you'll have to trust me on what is says. :)</div></div><div><br></div><div><p style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;color:rgb(68,68,68);background-color:rgb(252,252,252)"><span style="-webkit-font-kerning: none;">Here is section 1c that was changed:</span></p><p style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;color:rgb(68,68,68);background-color:rgb(252,252,252)"><span style="-webkit-font-kerning: none;"><br></span></p></div></div></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><p style="margin:0px;font-stretch:normal;font-size:14px;line-height:normal;font-family:Helvetica;color:rgb(68,68,68);background-color:rgb(252,252,252)"><span style="-webkit-font-kerning: none;">c) to distribute or communicate copies of the Original Work and Derivative Works to the public, with the proviso that copies of Original Work You distribute or communicate shall be licensed under this Upstream Compatibility License and <b>all Derivative Work You distribute or communicate shall be licensed under</b> <b>both this Upstream Compatibility License and the Apache License 2.0 or later</b>;</span></p></div></div></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Forking isn't impacted at all other than you can probably safely use any changes in those forks.  I say probably because there isn't any guarantee that any forked project licensed everything correctly...but bug fixes and the like are (probably) safe even if the changes exceed the de minims threshold since you can pick Apache for those changes.</div><div><br></div><div>I am not a lawyer and I'm speaking just for myself.  Do these disclaimers really do anything?  It's kind of like a cargo cult law ritual...</div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 2, 2018 at 3:39 PM Rick Moen <<a href="mailto:rick@linuxmafia.com">rick@linuxmafia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quoting Elmar Stellnberger (<a href="mailto:estellnb@elstel.org" target="_blank">estellnb@elstel.org</a>):<br>
<br>
> A contributor license agreement will work for large industry scale<br>
> applications with many programmers. It will not work for a private<br>
> project of mine because people would either ignore any contributor<br>
> license agreement in my name or even rather wildly develop different<br>
> forks without a mainline/upstream project.<br>
<br>
Wildly developed different forks are always inherently permitted by <br>
open source licensing (OSD #3).  Given that you apparently wish to<br>
prevent forks you disapprove of, I would suggest that you basically<br>
prefer proprietary development.<br>
<br>
If you really do understand, and are OK with, the basic realities of<br>
open source such as permitting no impediments to the right to fork, I<br>
would suggest you seek competent legal help when drafting software<br>
licences.  The problems in C-FSL 1.1 are IMO so vast one scarce knows<br>
where to begin -- perhaps with its many odd, convoluted, and poorly<br>
defined turns of phrase.  As a copyeditor, I was so struck with the need<br>
to  red-pencil (among many others) the section 5 phrase 'there only<br>
needs to be one marker by the party which is at the end of the chain as<br>
long as that chain remains to be documented in some place where it is<br>
shipped with your software' that I only barely noticed that the crucial<br>
term 'marker' is completely unclear, even though the preceding sentence<br>
purports to define it.<br>
<br>
<br>
<br>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>