On 1/20/17 05:42 , Guillaume Nodet wrote:
2017-01-20 11:26 GMT+01:00 Neil Bartlett <njbartl...@gmail.com>:
On 20 Jan 2017, at 10:12, Guillaume Nodet <gno...@apache.org> wrote:
2017-01-20 10:58 GMT+01:00 Guillaume Nodet <gno...@apache.org <mailto:
gno...@apache.org>>:
2017-01-19 19:36 GMT+01:00 Timothy Ward <timothyjw...@apache.org>:
At this point I’d also like to re-affirm that the OSGi RFC documents
are
public, and that there is a public feedback mechanism for RFC bugs. As
the
holder of the pen for Transaction Control, the JAX-RS whiteboard, and
the
JPA service updates I can truthfully say that community discussion and
feedback has influenced the direction of those RFCs/specifications, not
just the converter.
As David says below, you can gain increased control over the direction
of
things anywhere by becoming a member/committer/employee. Committers in
Apache Aries have ample opportunity to review and discuss the many
implementations built there, just as they do in Felix. This right
applies
both before and after the release of the specification. What Apache
Committers can’t do is make changes to an OSGi RFC/spec, for that they
need
to lobby an OSGi member.
I have no problems with the above.
This is exactly the same for a committer in Eclipse, on Github, or in a
private company, so it leaves Apache committers just as equal as
everyone
else.
I don't care about how Eclipse or Github project are operated. We're
talking about Apache projects and there are rules. One of them is that
committers are considered equal.
The main difference here is that there are a lot of OSGi members who
believe in Apache, and therefore contribute as committers. Are we
really
saying that those committers should be disallowed because they are OSGi
members and therefore have “more power”?
Not disallowed, but yes, they should not do something within the ASF
that
other committers who are not OSGi members can't do.
So to be clear: if any committer want to work on an implementation of an
RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
members or not.
If an OSGi member want to work on spec design within the ASF bounds, I
think that's not fine. In particular, if someone propose to develop
some
code to implement an RFC when the API from the developped and later
introduced back into the RFC document, I think that's definitely spec
work,
and should not be done within the RFC.
To be crystal clear, I have a problem with Ray willing to bring code for
implementing rfc-193 in Aries, when the code that he wants to bring
contains lots of things that are not reflected in the RFC document and
the
opposite. Ray and David explained that the RFC document will be
updated in
the coming weeks to reflect those changes. This is definitely spec
work,
and that's fine, but I don't think it should happen at Apache. Again,
it's
a timing problem wrt to changes in the document and changes in the code
:
if the code is changes first by the spec lead, and later validated on
during OSGi meetings and later integrated into the spec document and
made
public, I definitely see that as spec work, not as building an
implementation, and imho this is unfair to other committers because it
does
not follow the ASF rules. It's certainly open source, but not the
Apache
way.
And btw, even from a legal ASF pov, I'm not sure how things hold. People
are writing code copyrighted to the OSGi Alliance directly in the ASF…
And when *you* write code in the ASF, you own the copyright to that code.
Apache does not require or expect that copyright ownership of the code is
transferred to the ASF, only that it is licensed under the terms of the
ASL. The fact that OSGi Alliance may be the copyright holder of some code
does not present any problems.
Though maybe you shouldn’t seek legal advice on a developer mailing list
;-)
Well, the code does not seem to comply to the ASF rules at leat:
https://www.apache.org/legal/src-headers.html
1. This section refers only to works submitted directly to the ASF by
the copyright owner or owner's agent.
2. This section refers only to works submitted directly to the ASF by
the copyright owner or owner's agent.
3. If the source file is submitted with a copyright notice included in
it, the copyright owner (or owner's agent) must either:
1. remove such notices, or
2. move them to the NOTICE file associated with each applicable
project release, or
3. provide written permission for the ASF to make such removal or
relocation of the notices.
4. Each source file should include the following license header -- note
that there should be no copyright notice in the header:
Committers do sign an ICLA or CCLA. In both cases, there's a Grant of
Copyright License whereby the owner gives to the ASF "a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright
license to reproduce, prepare derivative works of, publicly display,
publicly perform, sublicense, and distribute Your Contributions and such
derivative works." I suppose that would be different if the code would
be written elsewhere and later imported in the ASF.
Afaik, the OSGi rfc / spec work is covered by the Distribution and Feedback
License whereby "The OSGi Alliance hereby grants you a limited copyright
license to copy and display this document (the “Distribution”) in any
medium without fee or royalty. This Distribution license is exclusively for
the purpose of reviewing and providing feedback to the OSGi Alliance. "
I'm definitely no lawyer, but again, not sure how everything holds together.
But you're right, given I'm no layer, I'll ask legal about that.
Just an FYI:
The license of which you speak is for the RFC document itself, not the
API which is AL. This is no different than a completed OSGi spec, which
is also not AL, but the APIs are AL.
-> richard
Finally, there are a lot of projects and/or components in Open Source
(including Apache) that are written by a single committer, typically
the
person with the itch to scratch. Only If that committer tries to
prevent
discussion about, or changes to, that code is there a problem for the
community. To my knowledge this does not apply to any of the
components in
Apache Aries or Apache Felix.
A piece of code being developed by a single person is definitely not a
good thing within the ASF. Again, the ASF operates with community over
code mantra and requires diversity within a project to avoid
dictatorship
and to ensure that the code development is overseen and can be
maintained
if one people is going away. Having some code being developed by a
single
person certainly does not help. The fact that it has almost always been
the
case for a bunch of subprojects in Felix or Aries does not mean it's
healthy nor good. But this is slightly mitigated by the fact that over
time, people tend to jump and fix things when they need.
Obviously, if that person would try to prevent discussion or code
changes,
that would be definitely a critical problem, but I haven't seen such a
behavior.
Best Regards,
Tim Ward
On 19 Jan 2017, at 17:32, David Leangen <o...@leangen.net> wrote:
Ray has listed a number of things that have been implemented during
the
past few months. All of them have been written by a single
committer
who
also happen to be the one modifying the spec document.
This is factually incorrect at least for the Converter implementation
at
Felix. Just look at the commit history for commits done on behalf of
community members and also check the mailing list for discussions
that
definitely provided great feedback on the work done.
I have been doing a very tiny bit of work on the Converter as a double
outsider (non committer in Felix, and non OSGi member).
I completely rely on others to accept my contributions and
suggestions,
making me a kind of second class citizen. It does work, but I need to
either (i) become a first class citizen either by merit or paying fees,
depending on the organisation, or (ii) accept my dependence on the
goodwill
of others. Currently I have a de facto sponsor who has been very
attentive
to my questions and contributions, so (ii) is working out well enough.
If
it didn’t work out, could always fall back on option (i).
So I can understand the frustrations and agree that there is a bit of
a
grey area, but at the same time I understand that in the end I have the
same opportunities as everybody else. In this case, I am not
willing/able
to “pay the price” for full citizenship, so I don’t feel I have the
right
to complain.
Just my 2¥.
Cheers,
=David
--
------------------------
Guillaume Nodet
--
------------------------
Guillaume Nodet
