[License-review] International Licenses: Québec Free and Open-Source Licence (LiLiQ)

[Simon Phipps]

Many thanks for your replies, which largely address my concerns. A few
clarifications below.

On Sun, Oct 4, 2015 at 10:58 PM, <Simon.Johnson-Begin at cspq.gouv.qc.ca>
wrote:

>
>
> Hi Simon,
>
> Thank you very much for your thoughtful comments. Below are our responses
> to them.
>
> >- I am concerned by the similarity of the names of the licenses. While
> >the language in all three is common, they are different in effect, yet the
> >names can be readily confused. Would it be better to pick more distinct
> >names for them?
> The names are similar, but it is by purpose. The keywords permissive,
> reciprocity and strong reciprocity is what makes them distinct in effect.
>

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

Permissive Quebec License
Partially Reciprocal Quebec License
Fully Reciprocal Quebec License



>
> *LiLiQ-P*
>
> >1. In section 3, what is the intent of the limitation of license grant
> >"for all practical purposes"?
> 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.
>

Unless others see a flaw, I think that would be good, yes.


>
> >2. In section 3, does "a form allowing it to be modified" include the
> >build files and/or other elements of the build environment?
> 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.
>

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.


>
> >3. In section 3, the prohibition on commercial use implied by "without
> >additional charges other than reasonable charges for delivery" seems
> >problematic and potentially violates OSD-1
> 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.
>

Perhaps you should say "without additional charges other than reasonable
charges for delivery OF THE SOURCE CODE"


>
> >4. In the same clause, the word "distribution" as defined in the
> >recitals does not appear to give certainty.
> 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.
>

OK. I was suggesting setting a new standard of clarity!


>
> >5. In section 4, would the requirement in (2) be satisfied by the author
> >of the modification adding their own copyright to the file?
> Yes.
>
> >I tend to agree with other comments that this requirement tends to be
> ignored in other
> >places it exists and you may prefer to make it a "should" rather than a
> "must"
> We are very open to that suggestion.
>
> >6. In section 5, if there is a separate agreement, why is the clause
> >necessary?
> For cases where there is no such agreements.
>

Perhaps that should be clarified so there's no question over which takes
precedence?


>
> >7. In section 9, termination should probably be on notification of the
> >failure rather than on discovery.
> Would you care to explain your reasoning on this one?
>

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.


>
> >8. In section 9 the use of the word "may" on restoration limits
> >certainty.
> 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.
>
> >9. In section 11, the requirement not to mention you in modified
> >versions should probably allow mention that the license is derived from
> >this license.
> We will make the appropriate changes.
>
> *LiLiQ-R*
>
> >1. In section 4.2, I suggest you also add CDDL as explicitly compatible
> 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.
>

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.


> >2. In section 4.2, the maintenance of this list concerns me, I wonder if
> >you should for example add a clause saying that you will also publish a
> >list of other compatible licenses on your web site?
> 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.
>

OK, I have heard that in other contexts as well.


>
> 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.
>

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.


>
> >3. In section 4.2, why not also allow the licenses in R+ to also be
> >considered compatible? MPLv2 does this, and there are license (such as
> EPL)
> >which are arguably in this middle level of reciprocity as well.
> 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”.
>

Having R+ and R be one-way compatible is probably desirable all the same.


> 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.
>

I believe I have heard Eclipse officials express a similar view, yes.

S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20151012/fbe4b7f3/attachment.html>