On 13 January 2012 12:31, Rob Weir <robw...@apache.org> wrote: > 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.
... > That is why it would be particularly useful if you could articulate > some reasoning behind your statements OK. The ASF chooses a very permissive licence so as to enable downstream developers of the code to do whatever they want with it. We have strong IP policies to prevent that licence being inadvertently contaminated with more restrictive licenses. One of those policies is to only distribute weak-copyleft in binary form This insistence on weak copyleft is to remove the possibility of an ASF project containing modified code with more restrictive terms. The inclusion of source code in a ASF products is counter to this long held ASF policy. The policy is documented under "How should so-called "Weak Copyleft" Licenses be handled?" at http://www.apache.org/legal/resolved.html The question then arises as to whether holding source tarballs in SVN and distributing only binaries with AOO releases is counter to this policy or not. In my opinion it is. I have confirmed this, to my own satisfaction, and provided references to discussions on the topic in this thread. Some argue that this is not the case, or at least is too restrictive for the project. Fine - then go and ask if the policy applies in this case. The advice of your mentor is that it does apply. > >> ... >> >>> 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. I am not arguing against that point. I'm not sure why you think I am. I make it clear below what my argument is. ... >> 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 do. > I realize there are additional graduation requirements. Good. > There were shorter ways of saying this. Ho Hum... Ross
