Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs

[Felix Meschberger]

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 
mailto:gno...@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 
mailto:cziege...@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-/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 
mailto: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




--

Guillaume Nodet

Re: [VOTE] Release Apache Felix DS Web Console Plugin 2.0.6

[Carsten Ziegeler]

Anyone else, we're missing one binding +1 vote

Thanks
Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs

[Carsten Ziegeler]

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
cziege...@apache.org

Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs

[Guillaume Nodet]

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 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-/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 :
> >
> >> 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
>



-- 

Guillaume Nodet

Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs

[Carsten Ziegeler]

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-/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 :
> 
>> 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

Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs

[Guillaume Nodet]

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-/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 :

> 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

Re: [DISCUSS] [POLICY] IP tracking for OSGi APIs

[Carsten Ziegeler]

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

[GitHub] felix pull request #85: Implement sourceAsDTO() and targetAsDTO()

[dleangen]

Github user dleangen closed the pull request at:

https://github.com/apache/felix/pull/85


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] felix pull request #87: [FELIX-5184] Add alias for Windows Server 2012

[tobias--]

GitHub user tobias-- opened a pull request:

https://github.com/apache/felix/pull/87

[FELIX-5184] Add alias for Windows Server 2012

default.properties were missing alias for Windows Server 2012. 

See [FELIX-5184:](https://issues.apache.org/jira/browse/FELIX-5184)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tobias--/felix add-windows-2012-alias

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/87.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #87


commit 452e611daee4975f222c1e5c25ba4d2120470ae5
Author: tobias-- 
Date:   2017-01-23T15:46:09Z

Add alias for Windows Server 2012




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (FELIX-5184) Regression: Native JNA bundle cannot be installed on Windows Server 2012

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15834781#comment-15834781
 ] 

ASF GitHub Bot commented on FELIX-5184:
---

GitHub user tobias-- opened a pull request:

https://github.com/apache/felix/pull/87

[FELIX-5184] Add alias for Windows Server 2012

default.properties were missing alias for Windows Server 2012. 

See [FELIX-5184:](https://issues.apache.org/jira/browse/FELIX-5184)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tobias--/felix add-windows-2012-alias

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/87.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #87


commit 452e611daee4975f222c1e5c25ba4d2120470ae5
Author: tobias-- 
Date:   2017-01-23T15:46:09Z

Add alias for Windows Server 2012




> Regression: Native JNA bundle cannot be installed on Windows Server 2012
> 
>
> Key: FELIX-5184
> URL: https://issues.apache.org/jira/browse/FELIX-5184
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.4.0
> Environment: Windows 2012
>Reporter: Stuart McCulloch
>
> The alias for Windows 2012 seems to have been lost when the "osname" aliases 
> were moved to framework/src/main/resources/default.properties (in 
> https://github.com/apache/felix/commit/c2b87c099bf3b5efc535cc80abc0d78fe9a7c2c0)
> The following line should be added to 
> framework/src/main/resources/default.properties:
> {code}
> felix.native.osname.alias.windowsserver2012=windows server 2012,win32
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5483) It's impossible to stop bundle using symbolic name if some installed bundle does not have symbolic name

[Karl Pauls (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15834680#comment-15834680
 ] 

Karl Pauls commented on FELIX-5483:
---

No, that is not the case. If you install a jar that doesn't have a: 
bundle-manifestversion 2 header in its manifest that jar will be treated as an 
R3 bundle. In that case it doesn't have a symbolic name as that only exists 
since OSGi R4 (older versions didn't have a symbolic name). Note that for this 
reason, the javadoc on getSymbolicName does say: "The symbolic name of this 
bundle or null if this bundle does not have a symbolic name".


> It's impossible to stop bundle using symbolic name if some installed bundle 
> does not have symbolic name
> ---
>
> Key: FELIX-5483
> URL: https://issues.apache.org/jira/browse/FELIX-5483
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Reporter: Alexandra Vasilyeva
>  Labels: patch-available
> Attachments: ifSymbolicNameNull.diff
>
>
> If some installed bundle does not have symbolic name, it's impossible to stop 
> any bundle by symbolic name: error "gogo: IllegalArgumentException: Cannot 
> coerce stop(String) to any of [(boolean, Bundle[])]" is shown in console and 
> bundle still in active state.
> Provided patch checks bundle symbolic name for null equality while searching 
> needed bundle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5483) It's impossible to stop bundle using symbolic name if some installed bundle does not have symbolic name

[David Bosschaert (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15834530#comment-15834530
 ] 

David Bosschaert commented on FELIX-5483:
-

The patch seems ok to me but AFAIK a bundle must always have a symbolic name, 
so I'm a little curious when you ever encounter one without it?

> It's impossible to stop bundle using symbolic name if some installed bundle 
> does not have symbolic name
> ---
>
> Key: FELIX-5483
> URL: https://issues.apache.org/jira/browse/FELIX-5483
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Reporter: Alexandra Vasilyeva
>  Labels: patch-available
> Attachments: ifSymbolicNameNull.diff
>
>
> If some installed bundle does not have symbolic name, it's impossible to stop 
> any bundle by symbolic name: error "gogo: IllegalArgumentException: Cannot 
> coerce stop(String) to any of [(boolean, Bundle[])]" is shown in console and 
> bundle still in active state.
> Provided patch checks bundle symbolic name for null equality while searching 
> needed bundle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Request to review patch for FELIX-5483

[Alexandra Vassilieva]

Hi all,

I would like to ask someone to review my small patch attached to
https://issues.apache.org/jira/browse/FELIX-5483

Best Regards,
Alexandra

[DISCUSS] [POLICY] IP tracking for OSGi APIs

[Guillaume Nodet]

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