Re: How other package pgjdbc

On 26 January 2016 at 08:20, Pavel Raiskup <praiskup(at)redhat(dot)com> wrote:

> On Tuesday 26 of January 2016 07:18:27 Dave Cramer wrote:
> > On 26 January 2016 at 02:13, Pavel Raiskup <praiskup(at)redhat(dot)com> wrote:
> >
> > > On Tuesday 26 of January 2016 03:34:00 Vitalii Tymchyshyn wrote:
> > > > Well, first of all you dont need to package osgi classes. Those are
> the
> > > > apis and as soon as you run in the osgi container, they are provided
> by
> > > > container. But you need those to build the driver. And af far as I
> > > > understand, there are certain licensing problems to do this, ain't
> they?
> > > I
> > > > dont think it's pure packaging problem, e.g. see
> > > >
> https://lists.fedoraproject.org/pipermail/legal/2012-July/001930.html.
> > >
> > > Thanks, I was not aware of that. This makes clear why people probably
> > > want OSGi enterprise, but it can not live in open source distribution.
> > >
> > > I'm not sure, is it safe to depend on it in upstream?
> > >
> >
> > The only reason it is bad is that it forbids modification which if you
> > think about it's purpose makes sense.
>
> This never makes sense in open source world - disagreement here :(. Any
> open project could say it makes sense to "protect you" from bad changes.
>
> It is basically ugly closed-source -- because "good" open source licenses
> try to protect you users from vendor lock-in -- and osgi.enterprise
> basically is vendor lock-in:
>
> consider that you are not able to build osgi.enterprise because java
> changes a bit (system dep changes a bit), etc. -- then you are locked
> in state of waiting for new upstream release or reimplement
>
> This is not acceptable, unfortunately.
>
> > It is attempting to provide an agreed upon way to include services into
> > an enterprise. If everyone modified it how would it work
>
> The license is not good tool to guarantee this.
>
> > I don't see the difference between this and JDBC for instance
>
> IANAL, but to me this makes it incompatible with other free licenses that
> *requires* you to keeping the source modifiable?
>
> My point is that you would not change the JDBC API, even if it was freebsd
licensed as your code would immediately become useless

Same with OSGI, it is meant as a common interface for everyone to be able
to discover services. Breaking the contract by changing the code makes the
code useless IMO

So we are in a bit of a quandry here. I do not think it is the JDBC's
mandate to be acceptable to distros. It is my understanding that much of
the packaging work involves changing projects to that they are compatible
with the distro. Even that is somewhat of a problem since a user would
expect all of the functionality that the JDBC project provides. If the
distro decides to cut pieces out of it the user is going to find that their
code works on X and not on Y environment.

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

> Pavel
>
>