felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Proposal for slight amendment to Felix provisional OSGi API policy
Date Tue, 03 Jan 2017 17:21:50 GMT

On 1/3/17 11:59 , David Bosschaert wrote:
> Hi Felix and Richard,
> On 3 January 2017 at 16:40, Richard S. Hall <heavy@ungoverned.org> wrote:
>> On 1/3/17 11:21 , Felix Meschberger wrote:
>>> Hi
>>> Upfront I like the amended proposal of using a version < 1 and a
>>> mandatory attribute „provisional“ with value „felix“. As Neil said, BND
>>> will solve this for imports be it the bndtools or the maven bundle plugin.
>>> Not declaring a version and thus using 0.0.0 will have BND generate a
>>> version-less import, which essentially means „any version“, which really
>>> bad. All exports always should have an export version.
>>> Now, to Richard’s point: I think this is very valid and we better take
>>> good care here. If we include OSGi API in our releases it is a re-release
>>> of AL2 licensed bits. Key is re-release. If we release provisional OSGi API
>>> in the OSGi name space which has not been released by OSGi yet, we are
>>> essentially first-party releasing it.
>>> So before we go this route, I would like to have the OSGi Alliance make a
>>> statement on this topic. In fact, it would make sense for the alliance to
>>> make an official statement not only to the benefit of the Felix project but
>>> to the benefit of all OSGi-related projects at Apache and elsewhere.
>>> WDYT ?
>> Yes, this is exactly the point that made us arrive at our policy in the
>> first place. We do not have permission or release provision API from the
>> OSGi Alliance. If I recall correctly, we are only granted permissions to
>> provide _compliant_ implementations of released API.
>> We have no way to achieve that requirement, which puts us in a gray area.
>> Thus, we arrived at 1) only doing snapshots or 2) changing the package name.
>> As Felix M. suggests, one way to remedy this is to get additional explicit
>> permission from the OSGI Alliance that we are allowed to create official
>> releases containing provisional API. However, this means we could get into
>> situations where the OSGi Alliance kills something (e.g., Gogo) that we
>> want to continue and we have created legacy in the OSGi package namespace.
>> It sucks, but that is the reality of the situation.
>> -> richard
> The OSGi Alliance has never released API with version <1 and I think it
> never will. This means that any API with version <1 that would be in Felix
> provisional release would never clash with a released OSGi API.

That's irrelevant. The issue at hand is the the org.osgi package namespace.

> AFAIK OSGi has never made a statement about the Felix release policy but I
> guess it might be possible to try and get a statement from OSGi that it
> will never release versions <1 and that implementation projects are allowed
> to use versions 0.x during the initial creation of an implementation of a
> new, previously unreleased spec.
> I can take this up to the OSGi folks and see if I can get a statement like
> that...

I'm not sure why you are fixated on the version, since that seems 
immaterial to me. The OSGi Alliance has never made any statement about 
Felix release policy, but they did have general words in place saying 
what the requirements were for being allowed to use their IP.

I'm fairly certain that the OSGi Alliance is not interested in losing 
their tight control over the org.osgi package namespace (nor should they 
be). Further, some statement saying "yeah, it's ok" doesn't really cut 
it if there still exists wording on requirements on who/how we can use 
their IP, since they could change their mind and then what? It would 
need to be explicit change of terms.

It's been a while, so who knows, maybe the terms have been loosened up 
at this point and it would be possible to do it differently, but it 
wasn't possible previously without entering a gray area with IP which is 
one of the main things that the Apache release process tries to 
eliminate confusion over.

-> richard

> Cheers,
> David

View raw message