Re: How other package pgjdbc - Mailing list pgsql-jdbc
| From | Dave Cramer |
|---|---|
| Subject | Re: How other package pgjdbc |
| Date | |
| Msg-id | CADK3HHKa+oCg-FMDWe+hTQX9-PPzqeeyjxfi9vQML7m_adMp5Q@mail.gmail.com Whole thread Raw |
| In response to | Re: How other package pgjdbc (Pavel Raiskup <praiskup@redhat.com>) |
| Responses |
Re: How other package pgjdbc
|
| List | pgsql-jdbc |
On 26 January 2016 at 08:20, Pavel Raiskup <praiskup@redhat.com> wrote:
On Tuesday 26 of January 2016 07:18:27 Dave Cramer wrote:
> On 26 January 2016 at 02:13, Pavel Raiskup <praiskup@redhat.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.
Pavel
pgsql-jdbc by date: