My analysis is that it doesn't place any requirements that the GPL itself
doesn't place, and yet at the same time isn't incompatible with the
BSD-based license SVN has. For commercial redistributors, the issue is
really going to come down to the definition of "use" in "software that
uses the DB software" - is that in the "same address space", as the GPL
defines? What about soft loading? Or calling over another network API
(will a DAV client "using" the subversion server also be indirectly
"using" DB), etc.
Knowing that SC's aim is the embedded-DB space, and judging from that
clause, I'd say that this probably only applies to apps that directly call
DB's apis, so "in the same process space" is probably what applies. If I
were releasing a commercial version of subversion, it would mean that I'd
make sure I had the process that sat on top of the DB did as little as
possible and talked through IPC to whereever I had my proprietary
"smarts" I didn't want to have to reveal the source code to.
If anyone thinks that is too onerous, they are welcome to build an
interface to another more freely licenseable DB library, or a true
versioning filesystem for that matter. =) The license on SVN will stay
BSD so this opportunity is not lost.
Brian
On Sun, 4 Mar 2001, Mo DeJong wrote:
> It seems like using sleepycat's modified Berkely DB is
> going to throw a wrench in the ability for anyone to
> create a proprietary product derived from svn. I am
> not saying that is a bad thing, I like the GPL. I
> am also not trying to start a flame war or anything.
> I just want to make sure that someone has considered
> this issue since the sleepycat terms seem more
> restrictive than the apache and collabnet terms.
>
> Mo DeJong
> Red Hat Inc
>
Received on Sat Oct 21 14:36:25 2006