You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Nodet <gn...@apache.org> on 2017/01/23 09:19:31 UTC
[DISCUSS] [POLICY] IP tracking for OSGi APIs
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+z48dynumpg@mail.gmail.com%3e
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Christian Schneider <ch...@die-schneider.net>.
That is fine. If the OSGi alliance does not change their policy about
publishing the specs early we can live with that.
I just wanted to state that I think there would be good reasons to change
the policy.
The OSGi alliance would benefit of better and earlier feedback and we would
benefit of a clear IP process and early access to the specs.
Christian
2017-01-23 22:28 GMT+01:00 Carsten Ziegeler <cz...@apache.org>:
>
>
> 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+z48dynumpg@mail.gmail.com%3e
> >
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Carsten Ziegeler <cz...@apache.org>.
Guillaume Nodet wrote
> My point is that there is a source identified, preferably public if
> possible, private if not.
>
> Of course if the API is not public, we can refer to the private commit so
> that PMC members which are not OSGi members can be confident about the IP
> tracking.
> I think it depends on what stage the API is. For example, consider the
> work Ray is working on for CDI, I don't think the API is in the OSGi git
> repo yet, so either the API is committed there first, or the commit can
> refer to Ray's github repo directly. If a spec has been published
> officially by the OSGi Alliance, we can refer to a public source too.
> Given the API code becomes public at the time it's given to the ASF, I
> didn't thought that would be a problem to have it in a public repo in the
> first place, but if you're saying it is... I'm fine with that.
>
> So what about:
> "All commits that includes API code from the OSGi Alliance are done in
> separate commit and include a reference to the public (preferably) or
> private (if not public) source where the code comes from."
>
> Does that look better to you ?
>
Absolutely
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Carsten Ziegeler <cz...@apache.org>.
Guillaume Nodet wrote
> My point is that there is a source identified, preferably public if
> possible, private if not.
>
> Of course if the API is not public, we can refer to the private commit so
> that PMC members which are not OSGi members can be confident about the IP
> tracking.
> I think it depends on what stage the API is. For example, consider the
> work Ray is working on for CDI, I don't think the API is in the OSGi git
> repo yet, so either the API is committed there first, or the commit can
> refer to Ray's github repo directly. If a spec has been published
> officially by the OSGi Alliance, we can refer to a public source too.
> Given the API code becomes public at the time it's given to the ASF, I
> didn't thought that would be a problem to have it in a public repo in the
> first place, but if you're saying it is... I'm fine with that.
>
> So what about:
> "All commits that includes API code from the OSGi Alliance are done in
> separate commit and include a reference to the public (preferably) or
> private (if not public) source where the code comes from."
>
> Does that look better to you ?
>
Absolutely
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Guillaume Nodet <gn...@apache.org>.
My point is that there is a source identified, preferably public if
possible, private if not.
Of course if the API is not public, we can refer to the private commit so
that PMC members which are not OSGi members can be confident about the IP
tracking.
I think it depends on what stage the API is. For example, consider the
work Ray is working on for CDI, I don't think the API is in the OSGi git
repo yet, so either the API is committed there first, or the commit can
refer to Ray's github repo directly. If a spec has been published
officially by the OSGi Alliance, we can refer to a public source too.
Given the API code becomes public at the time it's given to the ASF, I
didn't thought that would be a problem to have it in a public repo in the
first place, but if you're saying it is... I'm fine with that.
So what about:
"All commits that includes API code from the OSGi Alliance are done in
separate commit and include a reference to the public (preferably) or
private (if not public) source where the code comes from."
Does that look better to you ?
2017-01-24 11:42 GMT+01:00 Carsten Ziegeler <cz...@apache.org>:
> Guillaume Nodet wrote
> > 2017-01-24 0:02 GMT+01:00 Carsten Ziegeler <cz...@apache.org>:
> >
> >> Guillaume Nodet wrote
> >>> 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.
> >>>
> >> As said, it must be option #2, always and I'm not aware of any case
> >> where it hasn't.
> >>
> >
> > Cool. Then it should be very easy to simply add the source of the api in
> > the commit log, is it ?
> > David just did it yesterday, it does not seem very complicated:
> >
> > https://github.com/apache/felix/commit/94b4ca9a58ab15f70eead73736d801
> 83688a6325
> > Where's the problem ? I really don't understand.
> >
> What David did is exactly what I said is the way to do it. But still the
> OSGi API is
> not available in public, so unless you have access to the private OSGi
> git repo,
> you can't check whether the reference given there is correct or not.
> But you had exactly this requirement in your original proposal.
>
> As Felix proposed, let's extend our policy with what we can do and we're
> all happy.
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Guillaume Nodet <gn...@apache.org>.
My point is that there is a source identified, preferably public if
possible, private if not.
Of course if the API is not public, we can refer to the private commit so
that PMC members which are not OSGi members can be confident about the IP
tracking.
I think it depends on what stage the API is. For example, consider the
work Ray is working on for CDI, I don't think the API is in the OSGi git
repo yet, so either the API is committed there first, or the commit can
refer to Ray's github repo directly. If a spec has been published
officially by the OSGi Alliance, we can refer to a public source too.
Given the API code becomes public at the time it's given to the ASF, I
didn't thought that would be a problem to have it in a public repo in the
first place, but if you're saying it is... I'm fine with that.
So what about:
"All commits that includes API code from the OSGi Alliance are done in
separate commit and include a reference to the public (preferably) or
private (if not public) source where the code comes from."
Does that look better to you ?
2017-01-24 11:42 GMT+01:00 Carsten Ziegeler <cz...@apache.org>:
> Guillaume Nodet wrote
> > 2017-01-24 0:02 GMT+01:00 Carsten Ziegeler <cz...@apache.org>:
> >
> >> Guillaume Nodet wrote
> >>> 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.
> >>>
> >> As said, it must be option #2, always and I'm not aware of any case
> >> where it hasn't.
> >>
> >
> > Cool. Then it should be very easy to simply add the source of the api in
> > the commit log, is it ?
> > David just did it yesterday, it does not seem very complicated:
> >
> > https://github.com/apache/felix/commit/94b4ca9a58ab15f70eead73736d801
> 83688a6325
> > Where's the problem ? I really don't understand.
> >
> What David did is exactly what I said is the way to do it. But still the
> OSGi API is
> not available in public, so unless you have access to the private OSGi
> git repo,
> you can't check whether the reference given there is correct or not.
> But you had exactly this requirement in your original proposal.
>
> As Felix proposed, let's extend our policy with what we can do and we're
> all happy.
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Carsten Ziegeler <cz...@apache.org>.
Guillaume Nodet wrote
> 2017-01-24 0:02 GMT+01:00 Carsten Ziegeler <cz...@apache.org>:
>
>> Guillaume Nodet wrote
>>> 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.
>>>
>> As said, it must be option #2, always and I'm not aware of any case
>> where it hasn't.
>>
>
> Cool. Then it should be very easy to simply add the source of the api in
> the commit log, is it ?
> David just did it yesterday, it does not seem very complicated:
>
> https://github.com/apache/felix/commit/94b4ca9a58ab15f70eead73736d80183688a6325
> Where's the problem ? I really don't understand.
>
What David did is exactly what I said is the way to do it. But still the
OSGi API is
not available in public, so unless you have access to the private OSGi
git repo,
you can't check whether the reference given there is correct or not.
But you had exactly this requirement in your original proposal.
As Felix proposed, let's extend our policy with what we can do and we're
all happy.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Carsten Ziegeler <cz...@apache.org>.
Guillaume Nodet wrote
> 2017-01-24 0:02 GMT+01:00 Carsten Ziegeler <cz...@apache.org>:
>
>> Guillaume Nodet wrote
>>> 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.
>>>
>> As said, it must be option #2, always and I'm not aware of any case
>> where it hasn't.
>>
>
> Cool. Then it should be very easy to simply add the source of the api in
> the commit log, is it ?
> David just did it yesterday, it does not seem very complicated:
>
> https://github.com/apache/felix/commit/94b4ca9a58ab15f70eead73736d80183688a6325
> Where's the problem ? I really don't understand.
>
What David did is exactly what I said is the way to do it. But still the
OSGi API is
not available in public, so unless you have access to the private OSGi
git repo,
you can't check whether the reference given there is correct or not.
But you had exactly this requirement in your original proposal.
As Felix proposed, let's extend our policy with what we can do and we're
all happy.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Guillaume Nodet <gn...@apache.org>.
2017-01-24 0:02 GMT+01:00 Carsten Ziegeler <cz...@apache.org>:
> Guillaume Nodet wrote
> > 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.
> >
> As said, it must be option #2, always and I'm not aware of any case
> where it hasn't.
>
Cool. Then it should be very easy to simply add the source of the api in
the commit log, is it ?
David just did it yesterday, it does not seem very complicated:
https://github.com/apache/felix/commit/94b4ca9a58ab15f70eead73736d80183688a6325
Where's the problem ? I really don't understand.
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Guillaume Nodet <gn...@apache.org>.
2017-01-24 0:02 GMT+01:00 Carsten Ziegeler <cz...@apache.org>:
> Guillaume Nodet wrote
> > 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.
> >
> As said, it must be option #2, always and I'm not aware of any case
> where it hasn't.
>
Cool. Then it should be very easy to simply add the source of the api in
the commit log, is it ?
David just did it yesterday, it does not seem very complicated:
https://github.com/apache/felix/commit/94b4ca9a58ab15f70eead73736d80183688a6325
Where's the problem ? I really don't understand.
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Carsten Ziegeler <cz...@apache.org>.
Guillaume Nodet wrote
> 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.
>
As said, it must be option #2, always and I'm not aware of any case
where it hasn't.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Felix Meschberger <fm...@adobe.com>.
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 <gn...@apache.org>>:
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 <cz...@apache.org>>:
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 <cz...@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+z48dynumpg@mail.gmail.com<ma...@mail.gmail.com>%3e
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org<ma...@apache.org>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org<ma...@apache.org>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Carsten Ziegeler <cz...@apache.org>.
Guillaume Nodet wrote
> 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.
>
As said, it must be option #2, always and I'm not aware of any case
where it hasn't.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Felix Meschberger <fm...@adobe.com>.
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 <gn...@apache.org>>:
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 <cz...@apache.org>>:
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 <cz...@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+z48dynumpg@mail.gmail.com<ma...@mail.gmail.com>%3e
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org<ma...@apache.org>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org<ma...@apache.org>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Guillaume Nodet <gn...@apache.org>.
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 <cz...@apache.org>:
> 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 <cz...@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+z48dynumpg@mail.gmail.com%3e
> >>>
> >>
> >>
> >>
> >>
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziegeler@apache.org
> >>
> >
> >
> >
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Guillaume Nodet <gn...@apache.org>.
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 <cz...@apache.org>:
> 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 <cz...@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+z48dynumpg@mail.gmail.com%3e
> >>>
> >>
> >>
> >>
> >>
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziegeler@apache.org
> >>
> >
> >
> >
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cz...@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+z48dynumpg@mail.gmail.com%3e
>>>
>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
>
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cz...@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+z48dynumpg@mail.gmail.com%3e
>>>
>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
>
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Guillaume Nodet <gn...@apache.org>.
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 <cz...@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+z48dynumpg@mail.gmail.com%3e
> >
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Guillaume Nodet <gn...@apache.org>.
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 <cz...@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+z48dynumpg@mail.gmail.com%3e
> >
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Carsten Ziegeler <cz...@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+z48dynumpg@mail.gmail.com%3e
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Guillaume Nodet <gn...@apache.org>.
Well, another alternative is to remove the copyright to the OSGi Alliance
if they have been written from scratch, which would be even better
actually. That's what Geronimo does, the specs are all rewritten.
Le lun. 23 janv. 2017 à 13:54, Timothy Ward <ti...@apache.org> a
écrit :
> I agree. Additionally we should try to get the OSGi alliance to regularly
> build and publish snapshots on their own.
>
> Not having the APIs in apache source would be the best solution.
>
>
>
> Note that this would prevent implementing the API for any OSGi Util
> specifications, which include implementation types in the API (e.g.
> Promises, Tracker) nor will it work for Felix, (the OSGi API contains
> Filter and FrameworkUtil).
>
>
>
> This is also not what other Apache projects do. Geronimo, for example,
> provides Java EE spec APIs.
>
>
>
>
> Regards,
>
>
>
> Tim
>
>
>
> Sent from my iPhone
>
>
>
> On 23 Jan 2017, at 01:28, Christian Schneider <chris@die-schneider.net
> <ma...@die-schneider.net>> wrote:
>
>
>
> I agree. Additionally we should try to get the OSGi alliance to regularly
> build and publish snapshots on their own.
>
> Not having the APIs in apache source would be the best solution.
>
>
>
> Christian
>
>
>
> On 23.01.2017 10:19, 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+z48dynumpg@mail.gmail.com%3e
>
>
>
>
>
>
>
> --
>
> Christian Schneider
>
> http://www.liquid-reality.de
>
>
>
> Open Source Architect
>
> http://www.talend.com
>
>
>
>
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Timothy Ward <ti...@apache.org>.
I’ve just noticed that the formatting screwed up on that previous email. I was attempting to point out that Christian’s stated desire to not have the APIs in Apache Source Control may not be workable in all cases. Apologies for any confusion introduced by the lack of quote indent.
Regards,
Tim
> On 23 Jan 2017, at 04:54, Timothy Ward <ti...@apache.org> wrote:
>
> I agree. Additionally we should try to get the OSGi alliance to regularly build and publish snapshots on their own.
> Not having the APIs in apache source would be the best solution.
>
> Note that this would prevent implementing the API for any OSGi Util specifications, which include implementation types in the API (e.g. Promises, Tracker) nor will it work for Felix, (the OSGi API contains Filter and FrameworkUtil).
>
> This is also not what other Apache projects do. Geronimo, for example, provides Java EE spec APIs.
>
> Regards,
>
> Tim
>
> Sent from my iPhone
>
> On 23 Jan 2017, at 01:28, Christian Schneider <ch...@die-schneider.net>> wrote:
>
> I agree. Additionally we should try to get the OSGi alliance to regularly build and publish snapshots on their own.
> Not having the APIs in apache source would be the best solution.
>
> Christian
>
> On 23.01.2017 10:19, 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+z48dynumpg@mail.gmail.com%3e
>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Guillaume Nodet <gn...@apache.org>.
2017-01-23 13:54 GMT+01:00 Timothy Ward <ti...@apache.org>:
> I agree. Additionally we should try to get the OSGi alliance to regularly
> build and publish snapshots on their own.
> Not having the APIs in apache source would be the best solution.
>
> Note that this would prevent implementing the API for any OSGi Util
> specifications, which include implementation types in the API (e.g.
> Promises, Tracker) nor will it work for Felix, (the OSGi API contains
> Filter and FrameworkUtil).
>
I don't see why not having the API code in the svn tree prohibits the use
of implementation types. I think that Christian was saying that if the
APIs are consumed from a jar from a maven repository, it's very clear that
the code come from the OSGi Alliance, so there's no IP ambiguity anymore.
Also, I don't think there's any problem with actually publishing jars which
embed the API, even the source code, as it's ASL, the problem is really the
IP.
>
> This is also not what other Apache projects do. Geronimo, for example,
> provides Java EE spec APIs.
>
> Regards,
>
> Tim
>
> Sent from my iPhone
>
> On 23 Jan 2017, at 01:28, Christian Schneider <chris@die-schneider.net<
> mailto:chris@die-schneider.net>> wrote:
>
> I agree. Additionally we should try to get the OSGi alliance to regularly
> build and publish snapshots on their own.
> Not having the APIs in apache source would be the best solution.
>
> Christian
>
> On 23.01.2017 10:19, 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+z48dynumpg@mail.gmail.com%3e
>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Timothy Ward <ti...@apache.org>.
I agree. Additionally we should try to get the OSGi alliance to regularly build and publish snapshots on their own.
Not having the APIs in apache source would be the best solution.
Note that this would prevent implementing the API for any OSGi Util specifications, which include implementation types in the API (e.g. Promises, Tracker) nor will it work for Felix, (the OSGi API contains Filter and FrameworkUtil).
This is also not what other Apache projects do. Geronimo, for example, provides Java EE spec APIs.
Regards,
Tim
Sent from my iPhone
On 23 Jan 2017, at 01:28, Christian Schneider <ch...@die-schneider.net>> wrote:
I agree. Additionally we should try to get the OSGi alliance to regularly build and publish snapshots on their own.
Not having the APIs in apache source would be the best solution.
Christian
On 23.01.2017 10:19, 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+z48dynumpg@mail.gmail.com%3e
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Christian Schneider <ch...@die-schneider.net>.
I agree. Additionally we should try to get the OSGi alliance to
regularly build and publish snapshots on their own.
Not having the APIs in apache source would be the best solution.
Christian
On 23.01.2017 10:19, 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+z48dynumpg@mail.gmail.com%3e
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs
Posted by Carsten Ziegeler <cz...@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+z48dynumpg@mail.gmail.com%3e
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org