<br>On 8/23/07, <b class="gmail_sendername">Michael R. Bernstein</b> <<a href="mailto:michael@fandomhome.com">michael@fandomhome.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Speaking for myself, I am not so much concerned with any particular<br>incompatibility arising from different sets of permissions or<br>requirements (although those can be unfortunate). It is generally fine<br>with me that the submitted licenses are incompatible with the GPL or any
<br>other individual license.<br><br>What bugs me is that these licenses are incompatible with *every* other<br>approved license, even the BSD license. That took special effort.<br><br>No, let me amend that: It bothers me that these licenses are
<br>incompatible with the entire universe of all other theoretically<br>possible licenses, including future ones, regardless of their terms.<br>IANAL, but it seems to me they are even incompatible with licenses that<br>are word-for-word identical except for a name change.
<br><br>Is this true of any other OSI-approved license?<br><br>It also bothers me that this incompatibility extends not just to code<br>mixing and sublicensing, but also to multiple licensing. Multiple<br>licensing, like forking, is an unfortunate and infrequent necessity that
<br>I don't think should be given up lightly.</blockquote><div><br>Very well said!  I was having difficulty understanding the extraordinary distaste that some were expressing about the compatibility problem, and if your characterization is correct, it certainly makes the criticism very easy to understand.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think we need to add OSD #11 to disallow this kind of gratuitous and<br>discriminatory license incompatibility. Call it the principle of
<br>licensing neutrality: no provision of a license should explicitly<br>disallow combination with code under other licenses if the license terms<br>are otherwise compatible.</blockquote><div><br>While I'm not yet ready to seriously consider OSD#11 as you propose, you also provide an excellent way to frame an aspect of the license proliferation problem.  Today in San Francisco, several OSI folks are meeting to talk about a License Wizard--a program designed to identify licenses compatible with specific criteria, although the scope may also expand to identifying compatible/incompatible licensing combinations.  (I'm not there right now and I'm not running the agenda.)  But certainly you raise an interesting point: if the principle objective feature of the license (other than OSD compatibilty) is license *incompatibility*, perhaps there should be a special category and perhaps we should recognize it as such.
<br><br>A second comment reinforcing your argument, and your earlier appeal to the BSD license is this: any license that cannot be mixed with BSD presents a special case.  Granted, the OSD sets objective criteria and "BSD compatibility" is not one of the criteria.  But the many arguments I've heard from the copy-left and the copy-center folks come down to a basic disagreement on whether freedom is something that should be transitively preserved (copy-left) or something that should be exerciseable at the point of distribution (even the freedom to take code proprietary, which is what the copy-center people endorse).  Though I personally prefer and often advocate for the copyleft position, I hear the copy-center position, and in particular I respect the desire of copy-centrists to occupy the space of maximal compatibility, even if it means being compatible at the point of exit from open source.  That said, a license submitted to the OSI that is not compatible with the one license that attempts to be maximally compatible, and which many in the community believe to be The One Compatible License (well, MIT could claim that, too), such approval would be disruptive to that copy-center position.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Or perhaps this: A license may not discriminate against other licenses<br>or groups of licenses.
<br><br>Just to re-iterate: In my opinion incompatibility with other individual<br>licenses is NOT objectionable in and of itself. I do not think that<br>incompatibility per-se is non-neutral or discriminatory.</blockquote>
<div><br>I agree with you on that, too.  In many past discussions the arguments of license-discuss and the personal appeals of OSI board members have prevailed upon many license submitters to change their licenses so as to minimize the harm those licenses do to the overall open source ecosystem (as best we understand it).  I think that this is a case where the proper next step is to take Microsoft up on their offer to discuss these points and see if we cannot address this particular case of license incompatibility.  Again, I agree that license incompatibility per se is not evil, but total incompatibility with any other possible OSI-approved license is not a feature that fosters the benefits of open source as I understand them.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- Michael R. Bernstein<br>  <a href="http://michaelbernstein.com">michaelbernstein.com
</a><br><br></blockquote></div><br>Thanks for your contribution!<br><br>M<br>