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. Regards Felix [1] http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html Am 23.01.2017 um 23:47 schrieb Guillaume Nodet <[email protected]<mailto:[email protected]>>: 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 <[email protected]<mailto:[email protected]>>: As discussed already it's always #2 Carsten 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 even included in the source tree). For spec / rfcs under development, the only thing needed is to commit the api first in an osgi repository. For example: https://github.com/osgi/design/tree/master/rfcs/rfc-xxxx/api and then commit the same code referencing the commit in the above directory. If the above is not practical, it can be any github repo actually, even you 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 track 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 committed 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 <[email protected]<mailto:[email protected]>>: 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. Carsten Guillaume Nodet wrote As discussed on legal@ (see [1]), and in order to be able to track code IP correctly, I propose that all commits that includes API code from the OSGi Alliance are done in separate commit and include a reference to the public source where the code comes from. Thoughts ? Guillaume [1] http://mail-archives.apache.org/mod_mbox/www-legal- discuss/201701.mbox/% 3ccaa66tppc9lp71ak4uoxsnz8qzg+bnutyntzspbt+z48dynu...@mail.gmail.com<mailto:3ccaa66tppc9lp71ak4uoxsnz8qzg+bnutyntzspbt+z48dynu...@mail.gmail.com>%3e -- Carsten Ziegeler Adobe Research Switzerland [email protected]<mailto:[email protected]> -- Carsten Ziegeler Adobe Research Switzerland [email protected]<mailto:[email protected]> -- ------------------------ Guillaume Nodet
