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?
Pavel