aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <>
Subject Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Date Tue, 24 Jan 2017 07:35:16 GMT
Hi all

I think Guillaume’s idea of defining that provisional,  WIP, interim, temporary OSGi API
commits be isolated and refer to a concrete OSGi Repository commit (URL ideally) makes sense
to me. So that we can track back this source.

In any case, OSGi API will always bei OSGi copyrighted and this is not a problem at Apache
actually. Copyright and License to use are not the same thing, complicated in their own right
and even more complicated in their relation/interaction.

So for this OSGi API we leave the license header and copyright statements as they are. They
present no problem for us: The AL2 grants us the right to use, include, distribute irrespective
of the copyright. Actually the copyright gives the OSGi Alliance the right to license these
use and distribution rights to us.

To settle this down discussion down, I suggest we ammend the Felix „Provisional OSGi API
Policy“ [1] by a section on how to handle these cases:

  * develop in a branch
  * never release (as in Apache Release) provisional API in the OSGi name space (existing)
  * when committing provisional API in the branch, use isolated commit with URL reference
to original source

For Aries, I suggest to refer to the Apache Felix page.

Lets not create an elephant out of this mouse, please.



Am 23.01.2017 um 23:47 schrieb Guillaume Nodet <<>>:

Well maybe it should, but again, I don't think it has always been done
correctly in the past...
Hence this proposal to discuss what options we have to actually correctly
implement it.

2017-01-23 23:30 GMT+01:00 Carsten Ziegeler <<>>:

As discussed already it's always #2


Guillaume Nodet wrote
Right, we discussed that.
My understanding is that we have 2 options:
 * either the API is committed first at Apache, in which case, it can't
really be copyrighted to the OSGi Alliance
 * or it's copyrighted to the OSGi Alliance and it has to pre-exist the
commit in our svn source tree

If we choose #1, that's easy, we just have to remove the copyright on the
APIs headers.

If we go for #2, for specs that have been released, that's not a problem,
they usually come from the released spec jar (and they usually are not
included in the source tree).  For spec / rfcs under development, the
thing needed is to commit the api first in an osgi repository.
For example:
and then commit the same code referencing the commit in the above
If the above is not practical, it can be any github repo actually, even
own repo.  From the moment is has been committed by you somewhere outside
the ASF, the copyright can be granted to the OSGi in a clear way, so that
if the github code / commit is referenced from out svn commit, we can
the IP correctly.  I think an OSGi repository such as the one above would
be better.

The only thing is to avoid committing an API directly to the ASF and
pretending it's copyrighted by the OSGi Alliance, because source
to the ASF is by default supposed to be given a non-exclusive copyright
license grant coming from the ICLA/CCLA.

So I'm not sure what's wrong with the above, nor how that's practically
impossible, not that it would prohibit any kind of development.

2017-01-23 22:28 GMT+01:00 Carsten Ziegeler <<>>:

Well, we discussed this in length last week, and as a matter of fact the
OSGi API which is under development is not available publically. So how
can we define a policy that is practically impossible?

This goes back to what I said several times last week, we can only
change our side (Apache) but we can't change the OSGi Alliance side.

I think having a separate commit for the API and mentioning some
reference like the commit id or similar is a good idea. However, only
developers working for a member company of the OSGi Alliance can verify
this. But in practice, we have a lot of committers here being able to do
so, including Guillaume.


Guillaume Nodet wrote
As discussed on legal@ (see [1]), and in order to be able to track
correctly, I propose that all commits that includes API code from the
Alliance are done in separate commit and include a reference to the
source where the code comes from.

Thoughts ?


Carsten Ziegeler
Adobe Research Switzerland<>

Carsten Ziegeler
Adobe Research Switzerland<>

Guillaume Nodet

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message