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]>: > 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]>: > > > >> 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 > >> [email protected] > >> > > > > > > > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] > -- ------------------------ Guillaume Nodet
