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
- RE: [bdbje] [Licensing] Open Source verses Commercial Use Michael A. Olson
-