Re: Berkeley DB license (was Re: Points of order on this WG)
On Fri, Jun 26, 2009 at 5:36 PM, Maciej Stachowiakm...@apple.com wrote: On Jun 26, 2009, at 3:46 PM, Nikunj R. Mehta wrote: FWIW, I came across two pieces about Oracle's open source licensing of Berkeley DB that might help clear the air around the licensing issues. First, Oracle's license [1] is word-for-word identical to the erstwhile SleepyCat license [2]. Secondly, SleepyCat license qualifies as a free software license, and is compatible with the GNU General Public License. [3]. Thirdly, the license is OSI approved [4]. I am not sure if this resolves issues. It would help if you had comments on the above so that I can keep that in my context while discussing with our legal staff. The issue I see with using Berkeley DB for implementation (which I think is only a side issue to design of the spec itself) is as follows: Clause 3 of the first license (the one with the Oracle copyright notice) appears to have stricter source release requirements than LGPL. It's not clear to me what exactly the scope of the requirement is, but it doesn't seem to have the dynamic linking or relinkable object file exceptions of LGPL. That would be a problem for projects like WebKit or Gecko that don't want to impost any constraints that go beyond the LGPL in their license terms. Probably speaking out of turn, but on the larger point that there are non-BDB implementations that are well suited for the browser environment. For example, Tokyo Cabinet is a C library for B-tree databases, licensed under the LGPL. http://tokyocabinet.sourceforge.net/spex-en.html TC is far from the only clearly licensed storage-engine with lots of users. Any of them (including BDB) would make a good foundation for implementing a CouchDB-like replication system in JavaScript. As a web-developer I would really get a lot out of serious native B-tree API. The nice thing is that a B-tree API is so simple it'd be easy for vendors to use any number of engines and still achieve the same spec. Chris I don't want to start a huge debate over this, I just wanted to clarify the issue I see. Regards, Maciej -- Chris Anderson http://jchrisa.net http://couch.io
Re: Berkeley DB license (was Re: Points of order on this WG)
On Friday 2009-06-26 15:27 -0700, Nikunj R. Mehta wrote: I understand the interest in using Berkeley DB in browsers provided appropriate licensing freedom were available. I am beginning to understand your concerns vis-à-vis Berkeley DB's license. To be clear, I wasn't expressing any interest (or disinterest); I was just commenting on the licensing issues. I don't have any opinion on whether we'd want to use it if there weren't licensing issues (nor would I be the right person to do so). (I'm just sending this clarification to avoid anyone being under the incorrect impression that if the license were changed the software would promptly be incorporated into browsers. There's still the issue of convincing browser makers that doing so is important enough that they'd be willing to support it.) -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: Berkeley DB license (was Re: Points of order on this WG)
On Fri, Jun 26, 2009 at 3:46 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: FWIW, I came across two pieces about Oracle's open source licensing of Berkeley DB that might help clear the air around the licensing issues. First, Oracle's license [1] is word-for-word identical to the erstwhile SleepyCat license [2]. Secondly, SleepyCat license qualifies as a free software license, and is compatible with the GNU General Public License. [3]. Thirdly, the license is OSI approved [4]. I am not sure if this resolves issues. It would help if you had comments on the above so that I can keep that in my context while discussing with our legal staff. Unfortunately this does not resolve the issue. OSI approved is entirely different from compatible with any specific license (GPL, LGPL, MPL or anything else). Also, I'm not sure it's entirely fair to simply exclude non open-source browsers. We want the browser space to be competative, both for open source browsers and for proprietary browsers. If the API we come up with is prohibitively complex to implement without either releasing the browser as open source, or by licensing software from Oracle or any other party, then I think we haven't designed a good API. / Jonas
Re: Berkeley DB license (was Re: Points of order on this WG)
On Jun 26, 2009, at 3:40 PM, L. David Baron wrote: On Friday 2009-06-26 15:27 -0700, Nikunj R. Mehta wrote: I understand the interest in using Berkeley DB in browsers provided appropriate licensing freedom were available. I am beginning to understand your concerns vis-à-vis Berkeley DB's license. To be clear, I wasn't expressing any interest (or disinterest); I was just commenting on the licensing issues. I don't have any opinion on whether we'd want to use it if there weren't licensing issues (nor would I be the right person to do so). (I'm just sending this clarification to avoid anyone being under the incorrect impression that if the license were changed the software would promptly be incorporated into browsers. There's still the issue of convincing browser makers that doing so is important enough that they'd be willing to support it.) That's roughly our position for WebKit as well. I did not mean to raise the license issue as a showstopper, merely to point out the following: - If we propose an API modeled on Berkeley DB, it likely could not be implemented by the popular open source browser engines using Berkeley DB itself. - If we propose an API modeled on Berkeley DB, it likely could not be implemented by proprietary browser engines using Berkeley DB itself, unless the developers paid licensing fees to oracle. - Therefore, if we design such an API, we need to be clear and detailed enough that it can be implemented interoperably from scratch. - We also need to be clear that the implementation cost for any browser will likely involve implementation from scratch, not just plugging in an existing library. (If Oracle changed the license terms, things would be different, but I'm not asking for that and I don't think it's appropriate to ask at this early stage.) Regards, Maciej
Re: Berkeley DB license (was Re: Points of order on this WG)
On Jun 26, 2009, at 4:06 PM, Maciej Stachowiak wrote: On Jun 26, 2009, at 3:40 PM, L. David Baron wrote: On Friday 2009-06-26 15:27 -0700, Nikunj R. Mehta wrote: I understand the interest in using Berkeley DB in browsers provided appropriate licensing freedom were available. I am beginning to understand your concerns vis-à-vis Berkeley DB's license. To be clear, I wasn't expressing any interest (or disinterest); I was just commenting on the licensing issues. I don't have any opinion on whether we'd want to use it if there weren't licensing issues (nor would I be the right person to do so). (I'm just sending this clarification to avoid anyone being under the incorrect impression that if the license were changed the software would promptly be incorporated into browsers. There's still the issue of convincing browser makers that doing so is important enough that they'd be willing to support it.) That's roughly our position for WebKit as well. I did not mean to raise the license issue as a showstopper, merely to point out the following: I agree with Maciej - we have gotten far ahead of ourselves here on licensing terms. - If we propose an API modeled on Berkeley DB, it likely could not be implemented by the popular open source browser engines using Berkeley DB itself. I don't buy this but... - If we propose an API modeled on Berkeley DB, it likely could not be implemented by proprietary browser engines using Berkeley DB itself, unless the developers paid licensing fees to oracle. there is no free lunch for commercial browsers, at least not one that's catered by Oracle, - Therefore, if we design such an API, we need to be clear and detailed enough that it can be implemented interoperably from scratch. and, regardless of Berkeley DB, this should be the design goal. We have all been burned by SQLite and SQL storage, and I am not going to lead another train down the same path. I was quite clear in my very first message on this topic that we are talking about a B-tree based database and not a W3C stamp of approval for Berkeley DB to be embedded in browsers. - We also need to be clear that the implementation cost for any browser will likely involve implementation from scratch, not just plugging in an existing library. This is not correct. You and I can disagree, but really we should let our lawyers examine the matter. (If Oracle changed the license terms, things would be different, but I'm not asking for that and I don't think it's appropriate to ask at this early stage.) Regards, Maciej
Re: Berkeley DB license (was Re: Points of order on this WG)
On Jun 26, 2009, at 3:46 PM, Nikunj R. Mehta wrote: FWIW, I came across two pieces about Oracle's open source licensing of Berkeley DB that might help clear the air around the licensing issues. First, Oracle's license [1] is word-for-word identical to the erstwhile SleepyCat license [2]. Secondly, SleepyCat license qualifies as a free software license, and is compatible with the GNU General Public License. [3]. Thirdly, the license is OSI approved [4]. I am not sure if this resolves issues. It would help if you had comments on the above so that I can keep that in my context while discussing with our legal staff. The issue I see with using Berkeley DB for implementation (which I think is only a side issue to design of the spec itself) is as follows: Clause 3 of the first license (the one with the Oracle copyright notice) appears to have stricter source release requirements than LGPL. It's not clear to me what exactly the scope of the requirement is, but it doesn't seem to have the dynamic linking or relinkable object file exceptions of LGPL. That would be a problem for projects like WebKit or Gecko that don't want to impost any constraints that go beyond the LGPL in their license terms. I don't want to start a huge debate over this, I just wanted to clarify the issue I see. Regards, Maciej
