<div dir="ltr"><div dir="ltr"><div>Hi Pam,</div><div><br></div><div>A second comment:<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 2, 2019 at 12:55 PM Pamela Chestek <<a href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.com</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"><br>
As to "where in the OSD," I disagree with your framing that every<br>
license must be approved unless we can point to a specific rule broken.<br>
"Out of scope" is a valid reason; that is one reason why the human<br>
rights licenses are rejected. Some things are just not appropriate<br>
subject matter for trying to fix in an open source license.<br></blockquote><div><br></div><div>I don't intrinsically disagree with this, but in my head I have various "canons of construction" related to the OSD, and the specific one here is that I had always accepted that an OSD-compliant license must act only through the grant of permissions or conditions on the software itself (as well as being consistent with other elements of the OSD). Thus, "Do no evil" or "do not work more than 40 hours in a week" were appropriately out of scope for an open source license. But in the specific case of the CAL, I had drawn the data portability aspects carefully to only include permissions or conditions on the software itself, thus keeping it in scope for the OSD.</div><div><br></div><div>I think it would be useful, both in this case, and generally, to elaborate on some of these implicit canons of construction. I think it is valid to say that something is "out of scope," but I would suggest that this is a good case to use to develop an articulable rule for what that means.</div><div><br></div><div>Similarly, there may be something to the international applicability of a license that could be fertile ground for a canon of construction.<br></div><div><br></div><div>Thanks,<br>Van<br></div><div> </div></div></div>