<br><br><div><span class="gmail_quote">On 10/10/07, <b class="gmail_sendername">Chris Travers</b> <<a href="mailto:chris.travers@gmail.com">chris.travers@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In response to a number of people in the community (including Rick<br>Moen) and on the OSI board (including Michael Tiemann) who have<br>publically stated that products must use OSI-approved licenses in<br>order to call themselves "open source," I have decided to officially
<br>submit PostgreSQL's license to the OSI for approval.</blockquote><div><br>Thank you. <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 do so in the hope that the OSI will use the opportunity to decide on<br>a unified and resonable statement about what is or is not "open<br>source" and how this impacts concerns over license proliferation.</blockquote>
<div><br>I think we have done that already: if the license is properly approved by the OSI then the whole community (which includes press and analysts) can confidently say that the software is open source.  If the license has not been approved, people can argue that the license is OSD-conformant, but it's just their untested word.
<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;">My preferred outcome would be for the OSI to drop the pretense that<br>OSI approved licenses are the only open source licenses available in
<br>an unambiguous statement, as I feel that this would best serve<br>anti-license-proliferation efforts, and then reject this license on<br>antiproliferation grounds.  However, as an alternative, I would accept<br>seeing it approved.  Either way, I do not want there to be any doubt
<br>in any public statements whether this particular project is open<br>source or not.</blockquote><div><br>I don't see how the approval of a license would produce such an outcome.  I am more than game to follow what our process states, which is to discuss and recommend to the board the approval, rejection, or further discussion of a license.  But the submission of *this* license is unlikely for the OSI to drop its /position/ (not a mere pretense) that the definition of open source itself is based on peer review.
<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;">For those not aware of PostgreSQL, it is a mature, open source RDBMS<br>which came out of UC Berkeley.  The license was thus written by the
<br>University of California and conforms without question to the OSD.</blockquote><div><br>Indeed, the same University that brought us the BSD which, not unsurprisingly, it resembles.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[...]<br><br>I do not believe that this license offers anything new to the world of<br>permissive software licenses.  Personally I cannot think of any<br>instance where it would be functionally different from the X.Org<br>
license, and this may or may not be functionally different from the<br>MIT license (the only meaningful difference between those licenses is<br>that the MIT license explicitly grants a sublicense right, while the<br><a href="http://X.org">
X.org</a> license does not).<br><br>The license is slightly different from the ISC license in that it<br>extends to the documentation as well as the software and the<br>disclaimer section is different.  It is quite different from the "new
<br>BSD" license on <a href="http://opensource.org">opensource.org</a> in structure and organization, and I<br>believe it is clearer as the requirement that the pemrission grant is<br>reproduced as a condition of inclusion of code
<br><br>The text of the license template here is included:<br><br>[Program name]<br><br>[Portions] Copyright (c) [years] [authors]<br>...<br><br>Permission to use, copy, modify, and distribute this software and its<br>documentation for any purpose, without fee, and without a written agreement
<br>is hereby granted, provided that the above copyright notice and this<br>paragraph and the following two paragraphs appear in all copies.<br><br>IN NO EVENT SHALL [INITIAL CONTRIBUTOR] BE LIABLE TO ANY PARTY FOR<br>DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
<br>LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS<br>DOCUMENTATION, EVEN IF [INITIAL CONTRIBUTOR] HAS BEEN ADVISED OF THE<br>POSSIBILITY OF SUCH DAMAGE.<br><br>THE [INITIAL CONTRIBUTOR] SPECIFICALLY DISCLAIMS ANY WARRANTIES,
<br>INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY<br>AND FITNESS FOR A PARTICULAR PURPOSE.  THE SOFTWARE PROVIDED HEREUNDER IS<br>ON AN "AS IS" BASIS, AND [INITIAL CONTRIBUTOR] HAS NO OBLIGATIONS TO
<br>PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.<br></blockquote></div><br><br>I would like this list, and the board, to consider the proposition that we could define a trivial compatibility licensing cohort, namely, any licenses that permit either relicensing under substantially similar terms (such as SimPL does for the GPL) or permits arbitrary copying, modification, and redistribution along with any other licenses (subject to a limitation of warranty for the initial contributor(s)) and is subject to no further restrictions be treated as a member of the cohort license group.
<br><br>It does require folks to obtain legal advice to see whether such inclusion is proper for their jurisdiction and proposed combinations, but it should not require a lawyer from the other side to negotitate such rights.  Moreover, licensors who are willing to specifically agree that their license is, in fact, if member of a permissive cohort take the step of permitting relicensing under other licenses (perhaps with the limitation that reference to the initial license be maintained so that credit goes where credit is due), the cohort would collapse to a single quantum licensing state, making the proliferation question moot.
<br><br>Licenses like the GPL (versions 2 and 3) are cohort sinks: they permit others to relicense under their terms, but not to be relicensed under other terms (except by decision of the author(s)).  Our license proliferation work attempted to identify logical (if not legal) base equivalencies, and to the extent we have, it's up to those who choose substantially similar terms to agree that via some mechanism of preserving licensing history (a form of attribution!) they can agree to consolidate around the popular ones (or a neutrally-named cohort class).
<br><br>Thoughts?<br><br>