BerkeleyDB licensing and inclusion (or exclusion) in a product.

Question

We have a product that uses Berkeley DB.
For the licensing issue, are we allowed to include the appropriate shared libraries and executable BDB binary utilities in our "ship group"? No source code, no headers, no objects.
Or should we just tell them to get the specified BDB version from the download site?
Would prefer to include the shared libs and binaries if possible.
Please, I would like to hear the answer from one of the Berkeley members here.
Yes, I could just go read the licensing documents, but I'm not a lawyer, and just want to do the right thing here.
Thanks,
Jim

Answer 1

Jim,
Again, for the record, IANAL.
I cannot speak for all the open source licenses or their intentions, the GPL in particular, I can only talk about how I view the Sleepycat License in a non-legally binding manner. Please consult a lawyer and understand that I'm just summarizing some history below, nothing else.
The goal of the Sleepycat License is, and has always been, to allow those who build and redistribute open source applications to use Berkeley DB. The license is viral in that it clearly states that if you redistribute an application which uses DB you need to either be a) open source or b) be commercially licensed as a pre-condition to redistribution to 3rd parties. Your product uses DB, or at least it can use DB to add features and functionality when present, you could disable that ability. Your application is redistributed to 3rd parties. This then (IMHO & IANAL) triggers the license requirement that you a) open source your application code (ostensibly under an OSI approved license) and b) make that code readily available to all who seek to find it (place it on a server for easy download and make sure it is easy to find that page using an average search engine or the like) or purchase a commercial license from Oracle. The issue of who downloads, compiles, installs Berkeley DB is irrelevant, or at least it was never intended to be at issue (DB is found on most NIX systems by default and is easily installed using automated package managers as a dependency of some other application such as OpenLDAP).  Rather IMHO it is the redistributed application using DB, the one compiled against the db.h header and linked with libdb (dynamically or statically), that is at question wrt "redistribution".  Your application fits this case as it is redistributed to 3rd parties, it has the ability to use DB, yet it is not open source.  This is in conflict with the spirit* of the license, but IANAL (or a representative of Oracle's Legal team or representing their position on this matter) so I cannot defend the legalities involved in the terms of the license itself.
In my (non-legal, non-Oracle representative, non-binding) opinion it comes down to this, Berkeley DB is valuable to you and to us. The Sleepycat License has always been intended to support the open source community while allowing us to make a living selling commercial licenses. You make money from your code because it is valuable to your customers, we want to do the same for the same reasons (which only seems fair). What you're doing may be legal (I don't know because again, IANAL), and I can't fault you for trying to find a ways to cut costs for you and/or your customers, but how would you feel if you were on the other side of this conversation?
In the end, if your application requires Berkeley DB, but you do not ship Berkeley DB to your customer, you should consult with your company's legal counsel to determine whether or not you are in compliance with the terms of the public (Sleepycat) license for Berkeley DB.
-greg