<div dir="ltr"><div>Hi Bradley,</div><div><br></div><div>I appreciate your sharing here, especially as I have used the AGPL as both a comparison point and a foil for the CAL. <br></div><div><br></div><div>A few brief points in response.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 28, 2019 at 3:49 PM Bradley M. Kuhn <<a href="mailto:bkuhn@ebb.org">bkuhn@ebb.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Affero GPL was a huge leap and a big change in copyleft policy.  The FSF<br>
authorized a third-party fork for experimentation when the idea was new in<br>
2002 -- precisely because the FSF (as a license steward dedicated to software<br>
freedom) was cautious about expanding copyleft requirements in novel<br>
directions.  That GPL fork (i.e., AGPLv1) was explored in the wild for years<br>
before the FSF made it officially theirs (in 2007) and recommended it. </blockquote><div><br></div><div>There is a big difference between the existence of a license and the adoption of the license as one of a very few officially supported licenses by the FSF. 
Simply put, the FSF is in a different position vis-a-vis software freedom than anyone else in the community. You say it yourself: the AGPL was an authorized fork, and so it presented a new "policy" direction *from the FSF.* That does not apply to any other license or license steward.<br></div><div><br></div><div>While I would be thrilled if the FSF officially supported the CAL, I am under no illusions that such a thing - if it happened - would happen quickly. <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Even once the license became officially GNU, the FSF *still* kept it a fork of the<br>
"main license" (i.e., GPL) because loud voices in the community were still<br>
saying: "This is just too radical to be a 'default' copyleft policy."  As I<br>
said in a post on the MongoDB thread last year: the rules shouldn't change<br>
overnight in any culture (be it FOSS or anything else); that creates chaos.<br>
FSF knows this and is therefore careful and deliberate when proposing new<br>
copyleft requirements.  The many new license stewards that have cropped up in<br>
the last year should follow their well-set example.<br></blockquote><div><br></div><div>This again conflates the FSF with all other possible license stewards. But I would address a subtler, but more meaningful point: The SSPL discussions were launched simultaneously with the license being changed by MongoDB for all customers and all releases going forward. As you say, "the rules shouldn't change overnight," and that was a significant issue.</div><div><br></div><div>In contrast, the CAL had public and private feedback, was launched first on -discuss, moved to -review, and we are now going through this entire process a second time after having made significant changes to respond to feedback. This entire process has been done in the open, ahead of time. There is no chaos, and no one will be disadvantaged in any way by the approval of the CAL. It will become a new option among the others. 
It could be that it achieves success, or it could not. But no one is suddenly being subjected to an overnight rule change. 

</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But new leaps in copyleft policy shouldn't happen quickly, nor (IMO) be driven </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">by companies.  In particular, going from "nascent license with radical new policies" </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">to "OSI-approved" in just a few months is a mistake no matter who wrote the license. <br></blockquote><div><br></div><div>This is unfair. Why shouldn't a company be able to participate, especially if the manner in which they have chosen to do so is explicitly trying to be maximally respectful of the process? <br></div><div><br></div><div>More broadly, though, what you are advocating is bad policy for the OSI - and irrespective of the CAL, I would strongly advise against it. <br></div><div><br></div><div>I am a supporter of the OSI. I think the OSI is important, and that it serves an important function. But I can also see that some people are already choosing to bypass the OSI for various reasons. Having the OSI explicitly take a "wait and see, we won't decide until five years from now, once the license is established" makes it certain that the OSI will not be a participant in any significant licensing discussions. It also removes the possibility of significant discussion and analysis of licenses (such as is happening with the CAL). If the CAL was already widely established, there would be a strong argument that it could not effectively be changed, due to the installed license base.</div><div><br></div><div>Thanks,<br></div><div>Van<br></div><div><br></div><div><br></div><div> </div></div></div>