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
>



-- 
------------------------
Guillaume Nodet

Reply via email to