On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler <rgard...@opendirective.com> wrote: > On 13 January 2012 01:31, Rob Weir <robw...@apache.org> wrote: >> On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler >> <rgard...@opendirective.com> wrote: >>> It was said in reply to the VP Legal >>> affairs saying "That [holding MPL code in SVN] normally is highly >>> discouraged / not allowed." >>> >> >> You are putting words in Sam's mouth. The topic there was about >> forking MPL components, i.e., having an Apache project act as a >> maintainer of a fork of MPL and doing MPL development. > > If I am putting words in Sams mouth then I apologise. However, the > goal posts appear to be moving here. I thought I was safe quoting from > that thread since you referred to it yourself, indicating that it gave > approval for what you want to do. It can't be relevant in your defence > and not in mine. > > Are we talking at cross-purposes? >
I'm trying to develop understanding. To me it appears (and this is my personal opinion only) that you are cobbling together quotes out of context to support an undocumented position. So yes, we are talking at cross-purposes. It might be worth going back to the IPMC discussion from December on "concerns about high overhead in Apache incubator releases". There were a lot of good comments, along the lines of: "there aren't that many rules so before assuming something really is a rule try to find where its document that it is, and if no one can find that doc then its not a rule. Also, rules are only defined on policy pages so just because some "guide" type page says something doesn't make it true." or "Not everything was written in docs, and still not. Not everything needs to be, as lots is common sense. The email archives are "documents". Once one understands the principles of why the ASF as a foundation needs to do certain things, then the so-called rules are obvious consequences." and "Enumerate these principles and demonstrate the logical entailment of source releases." That is why it would be particularly useful if you could articulate some reasoning behind your statements, rather than just say something not-very-useful like "I am the policy book" and claiming some unwritten policy without even defining what that unwritten policy is. If you explain the reasoning, then this and other things should amount to "common sense". > ... > >> You might check out this thread for another angle on the subject, also >> from Sam, dealing with dev tools: >> >> http://markmail.org/message/jnuec5saca7wjoue > > It's interesting that you should refer to that thread. Notice that it > is me who started that thread. I spent my personal time on the > legal-discuss thread because my position [1] as a mentor was not > accepted as being correct by the community. Funny how I find myself in > exactly the same position again and again. > <snip> > > I'm really not sure why Rob thinks this thread supports the position > that no policy of "no copyleft in our servers". I'm sure I must be > missing something. I therefore looked back at Pedro's original > objection and realise that he his objecting to both a release and > graduation. Perhaps this is the point of confusion. > You are getting lost in the weeds. The point about that thread, or at least what I hoped would catch your eye, was Sam's statement, which he says in several other threads, so I'd consider it to be something worth understanding as a general rule, is that technical workarounds to ASF policy are not acceptable. Specifically, if something is out of policy for a release, then moving it to another host does not solve the problem. You need to distinguish what the essential problem is, and for that it is unavoidable (IMHO) to go back to the basic questions of what is in a release and what obligations and restrictions does that put on Apache and consumers of our releases. So Pedro's proposal to simply move MPL code to Google Code or whatever solve nothing. And any interpretation of ASF policy that thinks that something real is solved by shuffling code around with not a a single bit's different to the actual releases, is ministerial at best. > My support is for Pedro is limited to the graduation point. AOO can do > a release from the incubator in this way, but in order to graduate it > needs to either get approval for hosting of copyleft code or it needs > to remove it. > In other words, you agree with me, that this is not a problem for our release. I realize there are additional graduation requirements. There were shorter ways of saying this. >>> As we've said many times before the ASF is not a place where every >>> rule is written down. This has its advantages and its disadvantages. >>> The nearest I can provide is the one you linked to in your mail in the >>> above discussed thread. It can be found at >>> http://www.apache.org/legal/resolved.html#category-b >>> >> >> I understand that. That's why I asked if you could not point to a >> policy, whether you could make a cogent argument for why something >> like this would be problematic. > > If you understand that not everything is written down then you should > also understand that as a mentor I *am* the policy book. I'm certainly > an imperfect one, that's why there are other mentors and why we refer > to others where necessary. > The problem, of course, is that everything that is *not* ASF policy is also not written down. > I grow tired of arguing about policy, every other ASF podling I work > with spends time understanding why policy exists and then finds ways > to either work within it or ask for changes. Why is that not the case > here? > I'd love to understand 1) What the policy actually is here, and 2) Why it exists. That is why I've asked several times if you could explain it, even if you could not point to it, > ... > >> Fine. And if Pedro or anyone else wants to go hunting for this policy >> that may or may not exist, > > The policy *does* exist. It is being expressed here by a mentor. It is > also expressed in the very threads you link to. If the policy needs to > change then make the case to those able to make those changes (the > larger ASF Legal board committee). > So what is the policy? > Pedro does not need to put effort into supporting his objection to > graduation without approval because I support his position based on > the evidence before me at this time. It is the PPMCs collective > responsibility to work to remove that objection. Each individual in > the PPMC therefore has a choice: > > a) work within the policy > b) get approval for exceptions to the policy > c) ignore it and hope someone else resolves the problem before graduation > d) demonstrate to the community that the objection is not valid > > I think Rob is working towards d), but either I am fundamentally > misunderstanding something or I am unconvinced. Since the last bit of > evidence is a thread I started in order to clarify the situation the > last time this arose I have nothing more to say, and hope that if > others can see my mistake they will point it out so that I may change > my opinion. > If you, as a mentor and IPMC member, can articulate the policy and the reason behind the policy, then who knows, maybe I'd agree that it is fine. It seems you now agree that the policy is not an impediment to podling releases. In any case, I can't argue for a change if you won't state what the policy is. > In the meantime I see different people starting to work with Pedro to > explore the options around a) and b) (thank you). > Again, we really need to internalize what Sam is saying about technical workarounds. And maybe even Robert's emphasis on working backwards from what is an a release and what that means for users of our releases. Trying to turn ASF policy into an exercise in quote collection, absent any discussion of the context and principles behind them, leads only to a rigid formalism that helps no one. > Ross > > [1] http://markmail.org/message/xerohd43bh7giipk
