* Andrew Dunstan ([EMAIL PROTECTED]) 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
Description: Digital signature