felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Implementation of unreleased spec and community
Date Fri, 20 Jan 2017 13:49:16 GMT
On 1/20/17 05:42 , Guillaume Nodet wrote:
> 2017-01-20 11:26 GMT+01:00 Neil Bartlett <njbartlett@gmail.com>:
>>> On 20 Jan 2017, at 10:12, Guillaume Nodet <gnodet@apache.org> wrote:
>>> 2017-01-20 10:58 GMT+01:00 Guillaume Nodet <gnodet@apache.org <mailto:
>> gnodet@apache.org>>:
>>>> 2017-01-19 19:36 GMT+01:00 Timothy Ward <timothyjward@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
>>>>> 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 <osgi@leangen.net>
>>>>>>>> Ray has listed a number of things that have been implemented
>>>>> 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
>>>>>>> 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
>> 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
>> right
>>>>> to complain.
>>>>>> Just my 2¥.
>>>>>> Cheers,
>>>>>> =David
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>> --
>>> ------------------------
>>> Guillaume Nodet

View raw message