No, not at all, and I hope my actions are not taken against any one either. I had to mention you explicitly in order to make things more clear, sorry about that. Though I really do want to make sure the process more straight and make sure it's done fairly and by the rules.
2017-01-20 14:20 GMT+01:00 Raymond Auge <raymond.a...@liferay.com>: > Apparently I've severely offended you Guillaume. If so I sincerely > apologize. That was never my intention. > > Sincerely, > - Ray > > On Jan 20, 2017 5:42 AM, "Guillaume Nodet" <gno...@apache.org> 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. > > > > > > > > > > > > > >> > > >> > > >>> > > >>> 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 > > > > > > > -- > ------------------------ > Guillaume Nodet > -- ------------------------ Guillaume Nodet
