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-a
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 t
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 ty
+1
Sorry, it seems I forgot to give a few things.
Yes, "Blueprint Spring Support" (org.apache.aries.blueprint.spring) need
be released too.
Regards
Anton
20.01.2017 20:05, Guillaume Nodet пишет:
Sorry, it seems I forgot to give a few things.
The repository is available at:
https://rep
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 a
écrit :
> I agree. Additionally we should
2017-01-23 13:54 GMT+01:00 Timothy Ward :
> 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 Ut
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
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 cho
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
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 :
> As discussed already it's always #2
>
> Carsten
>
> Guillaume Nod
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'
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 cle
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
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 t
14 matches
Mail list logo
