<div dir="ltr">Many thanks for your replies, which largely address my concerns. A few clarifications below.<div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 4, 2015 at 10:58 PM,  <span dir="ltr"><<a href="mailto:Simon.Johnson-Begin@cspq.gouv.qc.ca" target="_blank">Simon.Johnson-Begin@cspq.gouv.qc.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
Hi Simon,<br>
<br>
Thank you very much for your thoughtful comments. Below are our responses to them.<br>
<br>
>- I am concerned by the similarity of the names of the licenses. While<br>
>the language in all three is common, they are different in effect, yet the<br>
>names can be readily confused. Would it be better to pick more distinct<br>
>names for them?<br>
The names are similar, but it is by purpose. The keywords permissive, reciprocity and strong reciprocity is what makes them distinct in effect.<br></blockquote><div><br></div><div>I still wonder if it would be better for the difference to lead the name so they are distinct in conversation. I have heard people confuse other licenses that use this approach and would rather that didn't happen to yours!  Maybe</div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>Permissive Quebec License</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Partially Reciprocal Quebec License</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Fully Reciprocal Quebec License</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
*LiLiQ-P*<br>
<br>
>1. In section 3, what is the intent of the limitation of license grant<br>
>"for all practical purposes"?<br>
For all practical purposes (in french: à toutes fins utiles) is intended to mean that the grant of rights can be exercised in any ways that is permitted by law and the license. To give more certainty, we agree that it could remove it, since it does not add anything to the rights granted.<br></blockquote><div><br></div><div>Unless others see a flaw, I think that would be good, yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
>2. In section 3, does "a form allowing it to be modified" include the<br>
>build files and/or other elements of the build environment?<br>
This was added to bring a little more certainty. For example, a source file in PDF could not be considered as “form allowing it to be modified”. The intended effect is similar to what can be found in sections 1 of the GPL and Apache licenses wording.<br></blockquote><div><br></div><div>You may want to add an FAQ to your licenses that clarifies potential confusions. In another context I found that using an FAQ to capture clarifications that did not merit changes to the license text was very helpful to developers learning about the impact of the license.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
>3. In section 3, the prohibition on commercial use implied by "without<br>
>additional charges other than reasonable charges for delivery" seems<br>
>problematic and potentially violates OSD-1<br>
This applies only in the cases where the source code wasn't distributed with the software. A licensee can charge anything he wants for the copies that he distributes. If someone wants the source code and it wasn't distributed with the software, the access to the source code must be given, without additional charges other than reasonable charges for delivery.<br></blockquote><div><br></div><div>Perhaps you should say "without additional charges other than reasonable charges for delivery OF THE SOURCE CODE"</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
>4. In the same clause, the word "distribution" as defined in the<br>
>recitals does not appear to give certainty.<br>
This word is not often defined in FOSS licenses. How would you say the proposed definition does not appear to give certainty? That definition, along with the “licensee” definition, was intended to mark the boundaries of the license, “restricting” who can become a licensee.<br></blockquote><div><br></div><div>OK. I was suggesting setting a new standard of clarity!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
>5. In section 4, would the requirement in (2) be satisfied by the author<br>
>of the modification adding their own copyright to the file?<br>
Yes.<br>
<br>
>I tend to agree with other comments that this requirement tends to be ignored in other<br>
>places it exists and you may prefer to make it a "should" rather than a "must"<br>
We are very open to that suggestion.<br>
<br>
>6. In section 5, if there is a separate agreement, why is the clause<br>
>necessary?<br>
For cases where there is no such agreements.<br></blockquote><div><br></div><div>Perhaps that should be clarified so there's no question over which takes precedence?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
>7. In section 9, termination should probably be on notification of the<br>
>failure rather than on discovery.<br>
Would you care to explain your reasoning on this one?<br></blockquote><div><br></div><div>If the termination clock can be started without informing the licensee, there is a strong risk of them facing immediate or even retrospective invalidation of their license. It must be a requirement for invalidation that the breach is advised to the licensee so they can remedy the breach.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
>8. In section 9 the use of the word "may" on restoration limits<br>
>certainty.<br>
The french version does not contain that certainty limit: “la licence est accordée de nouveau.” This means (in my own words): “The license is granted once again”. I will have to see with the translator why the word “may” was used. Thank you for pointing this out.<br>
<br>
>9. In section 11, the requirement not to mention you in modified<br>
>versions should probably allow mention that the license is derived from<br>
>this license.<br>
We will make the appropriate changes.<br>
<br>
*LiLiQ-R*<br>
<br>
>1. In section 4.2, I suggest you also add CDDL as explicitly compatible<br>
I understand that the CDDL is derived from the MPL. Since the MPL is explicitly compatible, we can assume that the CDDL is? On the other hand, we are open to add this license as explicitly compatible, if it can help to determine if other licenses are implicitly compatibles.<br></blockquote><div><br></div><div>While CDDL builds on MPL principles, it is not a derivative. The license is widely used in enterprise Java code and including it in your list is likely to be very helpful to open source Java developers.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
>2. In section 4.2, the maintenance of this list concerns me, I wonder if<br>
>you should for example add a clause saying that you will also publish a<br>
>list of other compatible licenses on your web site?<br>
This would be considered as an external clause. Also, we must remember that (at least, in civil law) the license is a binding contract between two persons. We were not comfortable with the fact that a third party could be able to add terms to a contract in which he is not a party.<br></blockquote><div><br></div><div>OK, I have heard that in other contexts as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The broad and large compatibility clause limits the need for such an external clause (“whose level of reciprocity is comparable to that of this licence, without being less so”). For example, if the MPL 2.0 is compatible, one can assume that an hypothetical MPL 3.0 would also be compatible.<br></blockquote><div><br></div><div>My only observation is that resolving this condition will require a developer gain the permission of another party, and will only become final in a court action. As a result, it's unlikely any developer will be comfortable relying on it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
>3. In section 4.2, why not also allow the licenses in R+ to also be<br>
>considered compatible? MPLv2 does this, and there are license (such as EPL)<br>
>which are arguably in this middle level of reciprocity as well.<br>
We seriously considered the option to allow the R+ to be compatible. In the end, this was rejected, mainly because the explicit compatibility clause act as a kind of gauge of what constitutes a license “whose level of reciprocity is comparable to that of this licence, without being less so”.<br></blockquote><div><br></div><div>Having R+ and R be one-way compatible is probably desirable all the same.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">As for the EPL, the reciprocity level of the LiLiQ-R+ seems to be comparable to the level of the EPL. The threshold of the LiLiQ-R+: modified and derivative softwares. The threshold of the EPL: Separate modules and derivative works.<br></blockquote><div><br></div><div>I believe I have heard Eclipse officials express a similar view, yes.</div><div><br></div><div>S.</div><div><br></div></div></div></div>