2017-01-20 14:49 GMT+01:00 Richard S. Hall <he...@ungoverned.org>: > 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.
Yes, thx for the confirmation. That was the conclusion I reached too when I realized the API code is available from maven central under plain ASL2 license, even though the OSGi web site is certainly not clear about that, as there's no difference made between the documents and the code. I thought the OSGi Alliance would mandate that the API is not changed, but that does not appear to be the case, which for an organization publishing standards, is a bit weird imho. However, you talked earlier about IP tracking, so from the ASF pov, it clearly helps if everything is developed in house. But if the code from the ASF is taken by the OSGi Alliance, IP clearance is not so clear from an OSGi Alliance pov, but that's definitely not the ASF problem. > > > -> 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 >>>> >>> >>> >> > -- ------------------------ Guillaume Nodet
