* Andrew Dunstan (andrew@dunslane.net) wrote:
> I suspect most postgres developers and companies would like to keep
> things as BSDish as possible. Dealing with a multitude of licenses might
> be fun for some, but many of us find it a pain in the neck.
It'd be great if PostgreSQL could use an SSL library with the same
license as PostgreSQL itself has. That'd certainly work for me.
Unfortunately, I'm not sure one exists (if anyone knows of one, please
mention it...). I don't like having to deal with lots of licenses
either but it's pretty much a fact of life in today's OSS world. I hope
you don't think I've gotten any enjoyment out of this, it's just a very
frustrating quagmire that I have to deal with.
> Also, do we really want to import the NSPR into Postgres? I suspect not.
> Of course, the only thing that people are tripping over license-wise is
> libpq. But I think we would want to keep that as lean and mean as
> possible, too.
erm, I'm not really sure what you're saying here but perhaps I can
clarify: I wasn't suggesting to add any serious amount of source code
to PostgreSQL - NSS would be used just as OpenSSL is today, and as
GNUTLS support was proposed, a seperate library which is distributed
independently of PostgreSQL but can be compiled against. I don't know
about the memory footprint of NSS, though if we care about that terribly
much it's my understanding that GNUTLS has a smaller footprint than
OpenSSL...
While somehow changing libpq to remove the issue it's unfortunately not
the only case. There are GPL'd PostgreSQL server extensions
(specifically PostGIS, at least) which are also affected.
Thanks,
Stephen
