On Tuesday 26 of January 2016 08:49:53 Dave Cramer wrote:
> My point is that you would not change the JDBC API, even if it was
> freebsd licensed as your code would immediately become useless
Agreed.
> 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
Agreed. (By that I mean that it makes not sense to change the API, and it
also makes no sense forcing you to use the code as read-only.)
> 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.
No, but you say you are free software (PostgreSQL license under
postgresql.org domain):
| Copyright (c) 1997-2011, PostgreSQL Global Development Group All rights
| reserved.
|
| Redistribution and use in source and binary forms, with or without
| modification, are permitted provided that the following conditions are
^^^^^^^^^^^^
| [skip]
Again, vendor lock-in is really wrong; and *ANY* redistribution of jdbc
now requires software (for build) that is subject of vendor lock-in
issues.
> It is my understanding that much of the packaging work involves changing
> projects to that they are compatible with the distro.
No :(. Not "much of the" packaging work -- usually there are no problems
with packaging (at least as far as I'm concerned in Fedora).
But yes, we do submit patches (or discuss before we submit patches) which
is usually good thing for upstream, too.
> Even that is somewhat of a problem since a user would expect all of the
> functionality that the JDBC project provides.
I am claiming all the time that distro users do not expect that
functionality in question -- and if yes, they always can use maven if they
are OK with that.
That's why I think the "core" functionality should stay FOSS, as it used
to be for very, very long time. OSGi support would be fine to have
optionally as separate jar wrapper (or something like that) -- I do agree
that is useful feature for osgi.enterprise users.
> 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.
This is different question, but yes -- the software is provided supported
for concrete environment usually. But that is normal -- on proprietary OS
you also expect issues if you migrate from version N to version N+1.
Pavel
