All,

I'm Mike Olson, Sleepycat Software's CEO. I've joined the dev@directory.apache.org mailing list so that I can participate in this discussion usefully, without you having to copy me off-list.

I've read some, but not all, of the traffic to the list on this thread. It appears that the thread archive is updated periodically, and that traffic from the weekend has not yet made it to the archive. Let me recap the discussion as I understand it so far.

Alex Karasulu, one of the Apache DS developers, posted a question on licensing of Sleepycat's Berkeley DB software when it's used in the Apache Directory Server. Rex Wang here at Sleepycat replied with a digest of the requirements that the Sleepycat public license imposes for use and redistribution. Noel Bergman, another Apache foundation member, raised concerns about the compatibility of our public license with the goals of the Apache project. Noel copied Cliff Schmidt, so I'm doing the same here, just to keep everyone in the loop.

Let me begin by pointing out what may be obvious -- there's no issue of compatibility between the Apache License 2.0 and the Sleepycat Public License. The Sleepycat license was designed to be identical in effect with the GPL. We didn't use the GPL for not-very-interesting historical reasons that no longer apply, but it's simpler to stay with the license we have than to switch, at this point. At base, however, there's no problem combining a software package that's composed of software under the Apache License and the Sleepycat Public License.

The only real issue is compatibility between the goals of the ASF, and the terms of Sleepycat's license.

Our license says that if you distribute an application that uses Berkeley DB, that application must be under an open source license. So long as the software is the Apache Directory Server from the Apache Foundation, there's no problem. However, if some third party takes the Apache DS, modifies it, and releases that modified version, the Sleepycat license requires that the modified version must likewise be open source. The Apache License does not make that requirement; it permits closed-source modification and distribution of the licensed software.

Berkeley DB is at the core of other proprietary and open source directory servers. Sun, Openwave, AOL, Critical Path and others use Berkeley DB in their LDAP products. Likewise, OpenLDAP and the Red Hat Directory Server are Berkeley DB-based. Our experience in the open source DS world has been that people really don't make proprietary mods to the open source products. There's just not much point to closed-source changes to infrastructure software of that sort. Everyone wants to stay current with the latest open source versions. Forks are bad, and closed-source forks are a waste of time.

We do allow closed-source apps to use Berkeley DB, but we do that under a commercial, paid license.

To be clear, Sleepycat believes in open source software. We support it with real cash, for developer salaries, and with our time and effort, in supporting open source projects that use Berkeley DB. We don't, however, write software for free, for other people to sell. We don't mind people making money by using Berkeley DB, but we want to participate. We think that's fair.

"Closed source" isn't exactly the same thing as "software that is sold," but the two are strongly correlated.

So, the way to think of Berkeley DB (including Berkeley DB JE) is in the same way you think of GPL'ed components generally. Our license imposes the same restrictions and obligations, in many fewer words.

We'd like to see Berkeley DB stay in Apache projects where it's useful, and where there's no significant practical risk that you'll undermine your mission. As I say, few open source infrastructure projects really get taken proprietary these days. People don't need to do that anymore. It's more work than it is worth.

We're proud of our products. We believe they're excellent, fast, reliable and scalable, and that you can't find anything better for the kind of embedded data management we do. We're glad to see them used widely in open source projects.

If the requirement really is that every component in an Apache licensed project be Apache licensed, then there's not much we can do.

As I say, I'm on the mailing list now, and am glad to continue the discussion by email.

                    mike

Reply via email to