Re: [HACKERS] Packaging of postgresql-jdbc - Mailing list pgsql-jdbc

Hi Matteo,

On Wednesday 17 of February 2016 10:39:43 Matteo Melli wrote:
> I am in the process of creating package torodb (
> https://github.com/torodb/torodb) for Fedora (
> https://bugzilla.redhat.com/show_bug.cgi?id=1302156). postgresql-jdbc is a
> torodb's dependency and, if possible, our goal is to include it in Fedora
> 22 and above. Actually we are trying to add the postgresql jdbc driver
> latest version as a bundle in our package but, as Pavel Raiskup told us,
> the right way is to have it stand-alone and depend on it. Since we have
> same goal to build the postgresql jdbc driver I decided to kick in and
> share my progresses with the community.

this is certainly an issue and we have already written similar patches
you've proposed.  Thanks for your work!  As this issue is not "just" about
Fedora, but it rather hurts all GNU/Linux distributions - let's discuss
how to do it a consistent way...

> For now I just removed waffle dependency patching code (attached) and
> removing a couple classes from build:
>
> * org/postgresql/sspi/NTDSAPI.java
> * org/postgresql/sspi/NTDSAPIWrapper.java

Yeah, that is something which should be optional.  As this is not easy, we
should patch it out.

> Actually I am looking into the org.osgi.enterprise artifact dependency that
> is missing, as you mentioned, due to incompatible license with Fedora.
> After investigating a bit I found out that org.osgi.enterprise library is
> shipped with an Apache License (Version 2.0, January 2004) so it is not
> clear to me if there are license issues or not. In any case postgresql-jdbc
> package use a single interface (org.osgi.service.jdbc.DataSourceFactory)
> from artifact org.osgi.enterprise. It would be really trivial to generate a
> clean room implementation of the interface and put it in a separate package
> or just use for build without installing.

AFAIU, osgi.enterprise refuses you to modify it's code.  That requirement
makes it incompatible with Fedora and all open source re-distributors
(vendor-lock-in).

I'm not sure what are the issues with GPL license compatibility .. IANAL,
but IMO you can use MIT/BSD libraries from GPL licensed project, but then
you have to distribute your whole work as GPL code -- which is not a
problem per se, but GPL *enforces* you to keep the code modifiable, while
osgi.enterprise refuses this;  this sounds like a clear collision.
However, we agreed this is not an issue for pgjdbc project and thus no
need to complicate upstream maintenance.  There was long discussion .. and
probably nothing more to add.

So -- patching out osgi.enterprise support would work for us similarly to
waffle.  And possibly in future; make the 'osgi.enterprise' support in
separate jar file with clear license clarification would work too..

---

People mostly (including pgjdbc upstream maintainers) suggest us to patch
the unclear stuff out from pgjdbc code .. which is pain to do over and
over again in all distributions.  We are considering a "close" fork of
pgjdbc (say 'pgjdbc-foss').  That fork should allow us all to package the
jdbc plugin "consistent" FOSS way.  There is no point in duplicating the
maintenance effort -- pgjdbc upstream does a good job here -- so we would
be in sync with pgjdbc and concentrating just on the distribution POV;
doing just the necessary changes.

I'm going to write a separate mail into new trhead to this list (with CC
to package maintainers in other distros) with ideas, requirements, etc.
But any idea from anyone here is welcome.

Thanks, Pavel