On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler <rgard...@opendirective.com> wrote: > On 13 January 2012 00:23, Rob Weir <robw...@apache.org> wrote: >> On Thu, Jan 12, 2012 at 7:13 PM, Ross Gardler >> <rgard...@opendirective.com> wrote: >>> On 13 January 2012 00:09, Rob Weir <robw...@apache.org> wrote: >>>> On Thu, Jan 12, 2012 at 7:05 PM, Ross Gardler >>>> <rgard...@opendirective.com> wrote: >>>>> On 12 January 2012 23:50, Rob Weir <robw...@apache.org> wrote: >>>>>> On Thu, Jan 12, 2012 at 6:42 PM, Ross Gardler >>>>>> <rgard...@opendirective.com> wrote: >>>>>>> On 12 January 2012 19:28, Rob Weir <robw...@apache.org> wrote: >>>>>>> >>>>>>> ... >>>>>>> >>>>>>>> You were looking for an opinion for Apache Legal. Robert is a member >>>>>>>> of Apache Legal Affairs, not Ross. >>>>>>> >>>>>>> This is not correct. Neither of us is a member of the committee. We >>>>>>> are both on the legal lists (I'm not sure if Robert is on the internal >>>>>>> one, but he is certainly on the discuss list where this kind of thing >>>>>>> would be). >>>>>>> >>>>>>> As I stated in that thread I believve Robert is mistaken, but since I >>>>>>> am not a part of the legal affairs committee, only an observer, I >>>>>>> cannot be certain. >>>>>>> >>>>>> >>>>>> If you can point to any policy statement to back your belief, I'd love >>>>>> to have a link, for the record. Or, a even a cogent argument for why >>>>>> this should not be allowed, given the stated goals of the license >>>>>> policies. >>>>> >>>>> See the reply I just posted pointing to a conversation you instigated >>>>> on this very issue on legal-discuss. That thread is certainly not a >>>>> "no", but it is certainly not a "yes" either. The conversation needs >>>>> finishing. >>>>> >>>> >>>> The thread went much further than what you quoted there, Ross, >>>> including the quote I gave where it was stated that this was OK. >>> >>> Really? Then markmail is not showing the full thread. Can you provide >>> a direct link to that mail, all I am seeing is at >>> http://markmail.org/thread/6odbj2isrq3jqg6g there is no OK in there. >>> >>> I don't see anything else in the ASF archves either, the start of the >>> thread is at http://s.apache.org/B1L >>> >>> What am I missing? >>> >> >> What I said in my earlier note -- the thread was partially on >> legal-discuss and partially on ooo-dev. Robert came over to ooo-dev >> to continue the discussion directly with the project. Probably the >> best way to get it in coherent form, if your mail client doesn't piece >> cross-list threads together, is to search MarkMail for "Clarification >> on treatment of "weak copyleft" components" > > OK, thanks. > > I've read the thread that this search returns, but I don't see an "OK". > > I see some comments from Rob, which I do not agree with. Rob does not > speak for the Legal Affairs committee, he speaks, as I do, as a well > intentioned advisor. Even so I don't see him saying it is OK, I see > things like: > > "Archiving the compressed source of weak copyleft dependencies in some > sort of repository[1] is something that Apache will need to become > comfortable with sometime soon" > > Note the future tense here - this is not currently something the ASF > is comfortable with. Roberts personal opinion on whether this is > necessary or not is irrelevant. 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. I don't believe the underlying issue in that exchange was where the MPL code lived. The issues was whether were were engaging in the development of MPL code at Apache. If anything, Same is adamant about saying the location of the code is not the fundamental issue. If that were the case we'd just create a bunch of fictitious shell projects on Google Code, put the code there, and voila, we have no category-b in our project. But byte for byte, a release built on that model would be identical to one where the components were stored in SVN. And the rights and obligations of users and downstream consumers would be identical. You might check out this thread for another angle on the subject, also from Sam, dealing with dev tools: http://markmail.org/message/jnuec5saca7wjoue > Robert went on to say "But developing downstream derivative works of > weak copyleft dependencies is likely to be a major issue" (I'm not > clear if this is relevant here or not, so feel free to ignore if it is > not) > > If there is an "OK" in there I can't see it. > > I'm afraid I still support Pedro's concerns. This is a grey area and > we need clarification from legal-discuss. We need the above thread to > be completed. > >> And if you can give me a link to the relevant Apache policy on this, >> I'd much appreciate that as well. > > 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. I'm very familiar with the link you've give above, and I see no problem there, not explicit, and not implicit in the basic overriding guidelines they give for the policies. Maybe I missed something? If so, I'd love to understand what it is, especially since a release built in external MPL components would be bit-for-bit identical to one build on MPL components stored in SVN. >> It is rather hard to ask for a >> policy to be changed, or ask for an exception to a policy, or even to >> ask for a policy to be explained, if no one can actually find it. > > Well you did OK in October, it's just that the issue was never > resolved by the legal-discuss list. > >> Saying "we've never done that before" is not an argument from policy. > > Rob, nobody has said that. What is being said, in Sam Ruby's words (VP > legal Affairs) is: > > "That normally is highly discouraged / not allowed." > > Note the word "normally" and note Sams requests for more info so he > can consider whether this is an appropriate edge case. > Note the word "this" and what was being discussed. >> It is an argument from inexperience. > > Rob, I have been active in the ASF for over 10 years, I've been a > Member for the vast majority of that time. Furthermore I have spent a > significant amount of my *personal* time looking in the archives to > see if this specific issue has been addressed before. I did this > *before* posting here. > Yes, yes, yes. But I wasn't saying you were not experienced. That was not a personal attack. I'm saying that an argument "we've never done it that way before" is an argument based on inexperience, not one based on policy. > I've pointed to a thread in which the VP Legal Affairs has essentially > said, (and I paraphrase) "not normally - but lets look at the options > and decide if this is a special case". You have claimed that the same > thread says it is OK - I don't see that. Please quote it for me, it is > way past my bedtime and I am tired. > > Pedro may be more or less experienced than me, I don't know. That is > irrelevant, he has merit here and his opinion needs to be respected. > He cannot be expected to withdraw his objection unless evidence is > provided. So far the only evidence I see is that the VP Legal affairs > said (and I paraphrase) "not normally - but lets look at the options > and decide if this is a special case". > > With that I'm going to bed and will leave space for others to comment > and tell me I've got it all wrong and should sleep more. > Fine. And if Pedro or anyone else wants to go hunting for this policy that may or may not exist, I think you've provided some good leads for where last you heard it rustling in the bushes. Once such policy is found, we'll have a better idea of whether we want to request a variance or modification. But it is not really worth my time to go in search of things that have not a bit's impact on what is in a release. > Ross > > -- > Ross Gardler (@rgardler) > Programme Leader (Open Development) > OpenDirective http://opendirective.com
