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 <cziege...@apache.org>: > >> 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%3e >>> >> >> >> >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org >> > > > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
