You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Pedro Giffuni <pf...@apache.org> on 2012/01/12 19:12:18 UTC
Category-B tarballs in SVN (was Re: External libraries)
--- Gio 12/1/12, Rob Weir <ro...@apache.org> ha scritto:
...
> >
> > I hate to make developer's life difficult but, from
> > what is known, no Apache Project seems to be carrying
> > Category B software in their repositories (feel free
> > to prove me wrong). Not that it's a new problem, just
> > something we will have to think about.
> >
>
> It is a service to downstream consumers. Just as we
> aggregate licenses and notices to make it easier for
> them, we also aggregate the optional category-b code
> tarballs.
>
It is actually a disservice. Some of those tarballs are
obsolete and carry known security risks.
> Also, the MPL license requires that we make our modified
> files available electronically for 12 months.
Thank you for pointing this out.
This sounds pretty much unacceptable for Apache policies
and a good reason to avoid carrying such code in our
repository.
>
> So I don't see a problem here, so long as we:
>
I do see a problem and unless some higher power from
legal@ OKs it, my vote for a release or project
graduation will be -1 (binding), on the basis that
if we do this once we will likely be perpetuating
such practice in all releases.
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Pedro Giffuni <pf...@apache.org>.
Hi,
--- Gio 12/1/12, Andrea Pescetti <pe...@apache.org> ha scritto:
...
> Pedro Giffuni wrote:
> > --- Gio 12/1/12, Rob Weir ha scritto:
> >> Also, the MPL license requires that we make our
> modified
> >> files available electronically for 12 months.
> > Thank you for pointing this out.
> > This sounds pretty much unacceptable for Apache
> policies
>
> Anyway this could be solved by the MPL 2.0 if it is really
> problematic: section 6 of MPL 1.1 allows to upgrade to MPL
> 2.0 and with MPL 2.0 "rather than exactly specifying the
> amount of time source code must be available, the source
> code must simply be made available when the executable is
> made available".
>
> At least that is my reading of
> http://www.mozilla.org/MPL/2.0/Revision-FAQ.html
>
The MPL 2 is indeed much better than MPL 1.1 but it still
pretty much in Category B: I am wondering if they reinvented
the CDDL ;).
I am not sure the update is automatic.. I think the Rhino
project (which happens to be the only thing in that category
we have updated) hasn't decided if it will switch: but I
really don't know if or why they wouldn't do it.
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Andrea Pescetti <pe...@apache.org>.
Pedro Giffuni wrote:
> --- Gio 12/1/12, Rob Weir ha scritto:
>> Also, the MPL license requires that we make our modified
>> files available electronically for 12 months.
> Thank you for pointing this out.
> This sounds pretty much unacceptable for Apache policies
Anyway this could be solved by the MPL 2.0 if it is really problematic:
section 6 of MPL 1.1 allows to upgrade to MPL 2.0 and with MPL 2.0
"rather than exactly specifying the amount of time source code must be
available, the source code must simply be made available when the
executable is made available".
At least that is my reading of
http://www.mozilla.org/MPL/2.0/Revision-FAQ.html
Regards,
Andrea.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Ven 13/1/12, Jürgen Schmidt <jo...@googlemail.com> ha scritto:
>
> that is a very important point and we should keep the
> practical relevance in mind.
>
> I normally build with --with-dmake-url to test this because
> it is currently very important for people who wants to start
> building AOO on their own. As long as we haven't switched
> completely to gnu make.
>
> I think it was on Wednesday or so where stumbled over the
> problem that the mentioned Url to Apache extras was not
> reachable for a day or at least several hours. That was not
> really satisfying from a user
> perspective :-(
>
Network outrages are unfortunate and can happen anywhere.
FreeBSD is currently mirroring the files and Debian
mirrors carry an older version that works well enough.
Pedro.
> Juergen
>
> >
> > Another way to think of it is this: the rights and
> obligations of a
> > downstream consumer are invariant over the choice of
> where the
> > category-b code is downloaded
> from. Would you agree with that much?
> > If so, I don't see any basis for a
> policy distinction purely based on
> > the location of the downloaded code.
> >
> >> Pedro.
> >>
>
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 1/12/12 9:29 PM, Rob Weir wrote:
> On Thu, Jan 12, 2012 at 2:59 PM, Pedro Giffuni<pf...@apache.org> wrote:
>>
>> --- Gio 12/1/12, Rob Weir<ro...@apache.org> ha scritto:
>> ...
>>>
>>> If you look carefully, you'll see that SVN, via the website
>>> stuff that is now there, has tons of content now that is in
>>> incompatible licenses, in the form of GPL and other licensed
>>> documentation. Ditto for the wiki. Ditto for extensions site.
>>> These are all hosted by the Apache, on behalf of the project,
>>> but they are not part of our releases. Are you saying SVN
>>> must be cleaned of all of that, even if it is not part of our
>>> releases?
>>>
>>
>> I certainly had understood the policy for website, Wiki and
>> even the extensions site is that we shouldn't be hosting
>> copyleft content. There might be a transitory situation during
>> incubation and some things are still to be decided but even you
>> have clearly stood in the position where any new content in the
>> Wiki, etc should be under AL2.
>>
>
> My point about website content being ALv2 was to give us the
> flexibility of including website content in a future release. Even
> online documentation might have a role if it could be bundled in a
> release, since that would allow downstream consumers to modify that
> documentation website and reuse it for their products. But it still
> comes down to the question of what is in a release.
>
>>>
>>> I'm happy to have someone review the issue, if you can
>>> state what the policy issue is. I simply don't see any
>>> problem here. We're not including category-b source code
>>> in our release, period.
>>>
>>
>> I am really not going into this discussion with you again.
>>
>> I think the issue is very easy to resolve: drop the
>> tarballs from SVN and provide sufficient instructions so
>> that the people doing the builds can download the tarballs
>> themselves: we even have nice "fetch_tarball.sh" script to
>> do just that.
>>
>
> The advice we've received in the past is that no policy issue related
> to a release is resolved simply by moving code. Back up and look at
> the downstream consumer, the person receiving a release. How do we
> feature AL as the default? How are we ensuring that category-b is
> included only by their explicit choice, rather than automatically?
> How are we ensuring that the downstream consumer has proper notice of
> the licenses and notices relevant to the code that they are
> downloading in our releases? How are we avoiding forking MPL
> components or doing further development work on them? How are we
> making an effort to push patches upstream? Those are the things we
> should be careful about. But in an automated script, whether it
> downloads MPL tarballs from an Apache server or an Apache Extras, I
> simply don't see any policy concern one way or another there.
>
> On the other hand, I do see relevant technical issues, including how
> do we ensure that we can maintain prior releases, including via
> security patches, if our binary releases are based on code that is
> scattered all over the web and which could disappear tomorrow based on
> the whim of other less stable OSS maintainers, or based on
> corporations merging or existing the business. I think the only
> prudent thing we can do is maintain a copy of all of our dependencies.
that is a very important point and we should keep the practical
relevance in mind.
I normally build with --with-dmake-url to test this because it is
currently very important for people who wants to start building AOO on
their own. As long as we haven't switched completely to gnu make.
I think it was on Wednesday or so where stumbled over the problem that
the mentioned Url to Apache extras was not reachable for a day or at
least several hours. That was not really satisfying from a user
perspective :-(
Juergen
>
> Another way to think of it is this: the rights and obligations of a
> downstream consumer are invariant over the choice of where the
> category-b code is downloaded from. Would you agree with that much?
> If so, I don't see any basis for a policy distinction purely based on
> the location of the downloaded code.
>
>> Pedro.
>>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 12, 2012 at 2:59 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
> --- Gio 12/1/12, Rob Weir <ro...@apache.org> ha scritto:
> ...
>>
>> If you look carefully, you'll see that SVN, via the website
>> stuff that is now there, has tons of content now that is in
>> incompatible licenses, in the form of GPL and other licensed
>> documentation. Ditto for the wiki. Ditto for extensions site.
>> These are all hosted by the Apache, on behalf of the project,
>> but they are not part of our releases. Are you saying SVN
>> must be cleaned of all of that, even if it is not part of our
>> releases?
>>
>
> I certainly had understood the policy for website, Wiki and
> even the extensions site is that we shouldn't be hosting
> copyleft content. There might be a transitory situation during
> incubation and some things are still to be decided but even you
> have clearly stood in the position where any new content in the
> Wiki, etc should be under AL2.
>
My point about website content being ALv2 was to give us the
flexibility of including website content in a future release. Even
online documentation might have a role if it could be bundled in a
release, since that would allow downstream consumers to modify that
documentation website and reuse it for their products. But it still
comes down to the question of what is in a release.
>>
>> I'm happy to have someone review the issue, if you can
>> state what the policy issue is. I simply don't see any
>> problem here. We're not including category-b source code
>> in our release, period.
>>
>
> I am really not going into this discussion with you again.
>
> I think the issue is very easy to resolve: drop the
> tarballs from SVN and provide sufficient instructions so
> that the people doing the builds can download the tarballs
> themselves: we even have nice "fetch_tarball.sh" script to
> do just that.
>
The advice we've received in the past is that no policy issue related
to a release is resolved simply by moving code. Back up and look at
the downstream consumer, the person receiving a release. How do we
feature AL as the default? How are we ensuring that category-b is
included only by their explicit choice, rather than automatically?
How are we ensuring that the downstream consumer has proper notice of
the licenses and notices relevant to the code that they are
downloading in our releases? How are we avoiding forking MPL
components or doing further development work on them? How are we
making an effort to push patches upstream? Those are the things we
should be careful about. But in an automated script, whether it
downloads MPL tarballs from an Apache server or an Apache Extras, I
simply don't see any policy concern one way or another there.
On the other hand, I do see relevant technical issues, including how
do we ensure that we can maintain prior releases, including via
security patches, if our binary releases are based on code that is
scattered all over the web and which could disappear tomorrow based on
the whim of other less stable OSS maintainers, or based on
corporations merging or existing the business. I think the only
prudent thing we can do is maintain a copy of all of our dependencies.
Another way to think of it is this: the rights and obligations of a
downstream consumer are invariant over the choice of where the
category-b code is downloaded from. Would you agree with that much?
If so, I don't see any basis for a policy distinction purely based on
the location of the downloaded code.
> Pedro.
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 12 January 2012 19:59, Pedro Giffuni <pf...@apache.org> wrote:
>
> --- Gio 12/1/12, Rob Weir <ro...@apache.org> ha scritto:
> ...
...
>> I'm happy to have someone review the issue, if you can
>> state what the policy issue is. I simply don't see any
>> problem here. We're not including category-b source code
>> in our release, period.
>>
>
> I am really not going into this discussion with you again.
I seem to have dropped into this thread in the middle as my name was
mentioned, if I have misunderstood some important context I apologise.
Rob, didn't you already discuss this on the legal-discuss list? Didn't
you already get answers to the issues that Pedro raises?
See http://markmail.org/thread/6odbj2isrq3jqg6g
Note that in this thread you asked if the intention of the policy was:
"4) Downstream consumer would need to make extra effort to retrieve and
modify the source of the MPL components, since we're not including the
source."
To which Sam Ruby (VP Legal Affairs) said "Yup."
You went on to ask:
"Now, for our SVN, we need to host the actual source of the MPL
components, since we need to build the binaries on the platforms that
we support. And in several cases we have patches the original source.
Is this a problem?"
Sam responded "That normally is highly discouraged / not allowed. Why can't the
patches be contributed back to the original projects?"
You suggested using apache-extras instead of our SVN, Sam responded:
"Apache-Extras was not intended as a means to bypass Apache policies."
You asked:
"(Or back to an earlier note, is there any problem with having the
build script automatically download such 3rd party dependencies?)"
Sam replied "Automatically is typically the hang-up in discussions
such as these,
but a specific exemption for well-disclosed sources to despondencies
which are distributed with the project could be discussed."
In this exchange Sam asked for some clarifications so that he could
consider whether an exemption to policy would be granted. The thread
never really reached a conclusion.
At this point in time it is my opinion that Pedro is correct in
raising this issue. Either the PPMC needs to complete the discussion
Rob started on legal-discuss or the solution Pedro is suggesting
should be implemented.
Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 12, 2012 at 6:42 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 12 January 2012 19:28, Rob Weir <ro...@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 want an official statement from legal you have to ask
> legal-discuss@ about the specific case in hand.
>
Should mention that the thread I quoted before was from a thread on
legal-discuss. ooo-dev was cc'ed, and at some point legal-discuss was
dropped from the thread. But we did exactly what you suggest, and we
did it back in October.
Again, if anyone feels like a repeat, then go for it.
> Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Andre Fischer <af...@a-w-f.de>.
On 13.01.2012 13:31, Rob Weir wrote:
> On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 13 January 2012 01:31, Rob Weir<ro...@apache.org> wrote:
>>> On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler
>>> <rg...@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".
+1
-Andre
>[...]
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Joe Schaefer <jo...@yahoo.com>.
>________________________________
> From: Andre Fischer <af...@a-w-f.de>
>To: ooo-dev@incubator.apache.org
>Sent: Friday, January 13, 2012 11:09 AM
>Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
>
>
>
>On 13.01.2012 15:59, Pedro Giffuni wrote:
>>
>> --- Ven 13/1/12, Ross Gardler<rg...@opendirective.com> ha scritto:
>> ...
>>>
>>> Can someone please explain why it is necessary to have the
>>> code here
>>> at all? Why is it not pulled from the upstream project?
>>>
>>
>> It is there only for convenience: to make it easier to fetch
>> and maintain.
>
>Agreed.
>
>>
>> I think it's pretty clear we don't strictly need it under
>> version control. At SUN/Oracle it was kept in another
>> repository.
>
>Yes, in fact there are technical reasons for not putting it under SVN:
>- its mostly binary code for which SVN can not provide diffs
>- it does not change very frequently
>- if it does we do not need the old versions any more.
>
>But, as I have read many times now, it does not matter much where the
>tar balls are placed, as long as it is an Apache Server.
>As long as that is true I opt for the convenience of putting them into
>ext_sources/
I'm not sure the IPMC will be sympathetic to the idea that this is done
solely for the sake of convenience. ASF's buildbot for instance is capable
of downloading source dependencies prior to building the software,
and you could even make it part of the build scripts to download
Category-B sources before building them as part of AOO builds.
The IPMC tends to want compliance with what it considers best practice
for its podlings, and if that's not able to be met, clear and compelling
reasons for an alternative solution will be expected.
But you're on the right track in first determining what the actual consensus
of the PPMC is. Please continue...
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Andre Fischer <af...@a-w-f.de>.
On 13.01.2012 15:59, Pedro Giffuni wrote:
>
> --- Ven 13/1/12, Ross Gardler<rg...@opendirective.com> ha scritto:
> ...
>>
>> Can someone please explain why it is necessary to have the
>> code here
>> at all? Why is it not pulled from the upstream project?
>>
>
> It is there only for convenience: to make it easier to fetch
> and maintain.
Agreed.
>
> I think it's pretty clear we don't strictly need it under
> version control. At SUN/Oracle it was kept in another
> repository.
Yes, in fact there are technical reasons for not putting it under SVN:
- its mostly binary code for which SVN can not provide diffs
- it does not change very frequently
- if it does we do not need the old versions any more.
But, as I have read many times now, it does not matter much where the
tar balls are placed, as long as it is an Apache Server.
As long as that is true I opt for the convenience of putting them into
ext_sources/
-Andre
>
> Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Ven 13/1/12, Ross Gardler <rg...@opendirective.com> ha scritto:
...
>
> Can someone please explain why it is necessary to have the
> code here
> at all? Why is it not pulled from the upstream project?
>
It is there only for convenience: to make it easier to fetch
and maintain.
I think it's pretty clear we don't strictly need it under
version control. At SUN/Oracle it was kept in another
repository.
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jan 13, 2012 at 9:50 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 13 January 2012 14:43, Rob Weir <ro...@apache.org> wrote:
>
> ...
>
>> If I were on the IPMC, and AOO came up for graduation, I wouldn't be
>> too concerned out the MPL license category being in SVN, so long as
>> the releases were in policy and so long as the PPMC could demonstrate
>> how they are addressing good practices related to code segregation,
>> etc.
>
> Can someone please explain why it is necessary to have the code here
> at all? Why is it not pulled from the upstream project?
>
The particular reasons why this is necessary would be on a
case-by-case basis. But here is the general reason why it is a good
idea for any 3rd party component:
A fundamental principle of software design: Never depend on a
component less stable than you. URL's change. Projects fold.
Corporations divest from open source projects. Websites get hacked and
source code changed. If we really want to be able to reliably build
and maintain AOO, and allow downstream providers to do the same, then
we need to have archival copies of all 3rd party components we depend
on (or at least the major ones), and to keep then versioned and
associated with our release branches.
This is the same reason Apache has its own mailing list archive and
its own URL shortener. Having control over these assets, from an
archival standpoint, is critical. This does not mean that we should
be developing such software at Apache. It just means that the ability
to maintain this software is only as reliable as our ability to
retrieve any third party components it relies on, regardless of
license.
I don't think the above is a policy question, but a technical one that
each PMC should be evaluating on its own. OpenOffice, an 11 year old
project, with many years ahead of it, has relevant experience in this
area. We've already outlived at least one upstream component.
> Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 13 January 2012 14:43, Rob Weir <ro...@apache.org> wrote:
...
> If I were on the IPMC, and AOO came up for graduation, I wouldn't be
> too concerned out the MPL license category being in SVN, so long as
> the releases were in policy and so long as the PPMC could demonstrate
> how they are addressing good practices related to code segregation,
> etc.
Can someone please explain why it is necessary to have the code here
at all? Why is it not pulled from the upstream project?
Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jan 13, 2012 at 8:17 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 13 January 2012 12:31, Rob Weir <ro...@apache.org> wrote:
>> On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> On 13 January 2012 01:31, Rob Weir <ro...@apache.org> wrote:
>>>> On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler
>>>> <rg...@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.
>
It is worth considering how storing the source in tarballs with MD5
hashes, as opposed to individual files in a directory tree, and
clearly segregating them into a directory that is separate and
distinct from the products core ALv2-licenced code, both prevents us
from easily modifying that source code and causing such problems. And
by not including them in releases, we ensure downstream consumers are
not confused either.
I'll suggest a few other policy considerations that are at play here as well.
One is the desire to be a good community participant, in the larger
open source community. Regardless of license, a podling that takes
code from another OSS project and maintains a separate fork of it has
some explaining to do. Why is it necessary to fork? Why aren't
patches being upstreamed? This should be an IPMC concern even if the
forked code was category-a. This is not necessarily forbidden, but it
should be explained, since things generally work better if we don't
unnecessarily divide efforts. A PPMC that does not have good
relations with its component providers (upstream components) may have
other difficulties with the larger ecosystem. I'm not saying this is
the case with AOO, but this should be treated as a general policy
consideration, "How Apache projects interact with upstream component
projects and communities"
Also, Apache projects do their development work under the Apache
license. So regardless of license category, it would odd if an Apache
project was carrying out development work on a component under a
different license. This would be a concern even if the license were
category-a. For example, if we forked an MIT-licensed component and
maintained our fork under the MIT license, this would be a deviation
from policy.
As you can see, both of the above are independent of license. The
threshold questions are: 1) Are we actively working with upstream
supplies of components to ensure that they have our patches? and 2)
Are we, as a project, developing software under non-Apache licenses?
The "solution" of moving our MPL code outside of Apache to Google Code
does nothing at all to remove these concerns. It is just changing
appearances, not addressing the fundamental orientation of the project
to 3rd party components.
If I were on the IPMC, and AOO came up for graduation, I wouldn't be
too concerned out the MPL license category being in SVN, so long as
the releases were in policy and so long as the PPMC could demonstrate
how they are addressing good practices related to code segregation,
etc. I'd also want to see a demonstrated effort to upstream patches
made to 3rd party components regardless of license, and attempts made,
over time, to reduce the need for such patches. I'd also want to be
sure that in the case of category-b components, that patches were done
only where necessary, for things like security patches, to resolve
library incompatibilities or similar, and that no active "feature
development" was being done in those components at Apache.
> 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
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Ross Gardler <rg...@opendirective.com>
> To: ooo-dev@incubator.apache.org
> Cc:
> Sent: Friday, January 13, 2012 11:15 AM
> Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
>
> Sent from my mobile device, please forgive errors and brevity.
> On Jan 13, 2012 4:02 PM, "Andre Fischer" <af...@a-w-f.de> wrote:
>>
>>
>> On 13.01.2012 16:25, Ross Gardler wrote:
>>>
>>> For what it is worth, I agree with Joe here. The question is whether
> there
>>> is a valid reason to keep them here.
>>
>>
>> I don't know if the reasons are valid. We are trying to find a
> pragmatical solution that is a good compromise for the different
> requirements of the ASF, the OpenOffice developers/community, and the
> OpenOffice users:
>>
>> - For the ASF we use no code under category X license and try to use as
> little code under category B license.
>>
>> - For the users we want to retain as many features as possible.
>>
>> - For the developers we want to make development as accessible as
> possible.
>>
>
> Why is it necessary to include source rather than just binaries?
The likely reason is that binaries aren't readily downloadable for all
the specific platforms AOO intends to support.
Re: PROPOSAL (was Re: Category-B tarballs in SVN )
Posted by Ross Gardler <rg...@opendirective.com>.
As I have asserted before, in order to graduate AOO will need to discuss
this with legal@
My recommendation is to minimise the need to host category B source
wherever possible. Where it is not possible local policy needs to prevent
inadvertent contamination from copyleft provisions. I imagine permission
well be given in such circumstances. Where it is merely a convenience I am
less sure and thus legal@ guidance is required.
Clearly there is disagreement about when it is necessary and until someone
at legal@ examines this specific case we are at an impasse.
As a mentor I want to see this resolved before graduation. In the meantime
a release is allowable as-is.
Ross
Sent from my mobile device, please forgive errors and brevity.
On Jan 18, 2012 2:26 AM, "Pedro Giffuni" <pf...@apache.org> wrote:
>
> --- Lun 16/1/12, Rob Weir ha scritto:
> ...
> > > the the Apache licensing policies:
> > >
> > > http://www.apache.org/legal/3party.html
> > >
> >
> > That URL is for an earlier draft of the policy. You
> > really should be
> > referencing the latest version of the policy here:
> >
> > http://www.apache.org/legal/resolved.html#category-b
> >
>
> I have looked at this and indeed this appears to be
> the definitive policy (the previous one was being
> revised every 6 months and gave lighter provisions
> for podlings). The definitive policy is much less
> clear than the draft but certainly doesn't seem
> to contradict it.
>
> Still there is no distinction between source packages
> and binary packages and it seems the principles in the
> draft still apply.
>
> Pedro.
>
>
Re: PROPOSAL (was Re: Category-B tarballs in SVN )
Posted by Pedro Giffuni <pf...@apache.org>.
--- Lun 16/1/12, Rob Weir ha scritto:
...
> > the the Apache licensing policies:
> >
> > http://www.apache.org/legal/3party.html
> >
>
> That URL is for an earlier draft of the policy. You
> really should be
> referencing the latest version of the policy here:
>
> http://www.apache.org/legal/resolved.html#category-b
>
I have looked at this and indeed this appears to be
the definitive policy (the previous one was being
revised every 6 months and gave lighter provisions
for podlings). The definitive policy is much less
clear than the draft but certainly doesn't seem
to contradict it.
Still there is no distinction between source packages
and binary packages and it seems the principles in the
draft still apply.
Pedro.
Re: PROPOSAL (was Re: Category-B tarballs in SVN )
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 16, 2012 at 11:17 AM, Pedro Giffuni <pf...@apache.org> wrote:
> Hi Rob;
>
> I specifically avoided answering to this on Sunday because
> in my religious beliefs it is a day to rest and I didn't
> really want to spend time on this.
>
> Since the time this was posted I think I have seen the light
> (TM) and I am willing to share it with you if you have the
> patience.
>
> The comments that follow are NOT meant for the faint of
> heart if you are likely to have strong feelings about this
> please STOP READING NOW.
>
> Also, if you are still here, remember ... don't kill
> $MESSENGER.
>
> --- Sab 14/1/12, Rob Weir <ro...@apache.org> ha scritto:
>
>>
>> OK, though this is solving a problem we don't really have,
>> right?
>> Although we have not yet built a script to produce a source
>> package per Apache rules, when we do it will not include
>> any of the /ext-src modules, correct? It won't include
>> the category-a and it will not include the category-b
>> either? What would be the point, since the
>> build script brings down what it needs via the bootstrap,
>> per the configuration flags used? So if we really want to
>> give proper notice to the person downloading our source
>> release, this needs to be done:
>
> We do have to include Category-A in the release or the
> release wont build. Separation has to happen.
>
I was talking about source packages. They are not required to include
everything that needed to produce the binary package. For example, we
don't include Visual C++ or gcc or a copy of Microsoft Windows.
Generally, tools and libraries that are commonly available we treat as
a pre-requisite.
With category-a source code, I think from a policy perspective, we
could include the source in our release, we could require the user to
download manually as a per-requisite, or we could have the build
scripts do this automatically, from an external server or an Apache
server.
> Here is the first big flaw in your reasoning: there is no
> such thing as a source release or a binary release, there
> is simply a release.
>
> Let me explain it this way: long, long ago, before the
<snipping a long historical digression>
Yes, I believe we all know and understand this. That is why I've been
using the terms "source package" and "binary package". An Apache
"release" would include at least the source package. The current plan
for AOO is to have both.
>
>
>>
>> I have no objections if you want to shuffle things around
>> in the directory structure, and update bootstrap logic
>> accordingly.
>
> "shuffling" things is not a problem but I don't think
> updating the bootstrap logic was mandatory. Our releases
> have to build on their own and as you note the sources for
> Category B stuff are not included anyways, but let me point
> out the second big failure in your reasoning.
>
> As I said before there is no such thing as "source releases"
> or "binary releases" and such terms don't appear anywhere in
> the the Apache licensing policies:
>
> http://www.apache.org/legal/3party.html
>
That URL is for an earlier draft of the policy. You really should be
referencing the latest version of the policy here:
http://www.apache.org/legal/resolved.html#category-b
> Now, this phrase concerning Category-B has received a particular
> wrong reading:
>
> "Code that is more substantial, more volatile, or not directly
> consumed at runtime in source form may only be distributed in
> binary form."
>
That sentence does not exist in the actual policy. That is only in the draft.
> We, and particularly you, have read this as a prohibition to
Oh, I didn't read it it all, since that is in the draft version only.
> include MPL'd code in "source release" but the truth is that
> it is a prohibition to distribute Category-B software *at
> all*. Distribution certainly includes subversion.
>
http://www.apache.org/legal/resolved.html#category-b
> The point is further clarified:
> "In addition, C-based projects may have difficulty using works
> under these licenses since they would have to deal with
> platform-specific binaries, rather than just distributing
> source that can be built on most any platform."
>
Again, this is not in the real policy.
> This last clarification has an upside: we can include in
> our releases (and therefore in SVN) platform independent files
> like Java bytecode and fonts under a Category-B license.
>
In any case, I think we've found one source of the confusion here.
Take a look at the live version of the policy (it does get updated
from time to time) and let me know if you still see policy concerns
with including category-b in binary form, in the binary packages of
our releases:
http://www.apache.org/legal/resolved.html#category-b
Regards,
-Rob
> Pedro.
>
> PS. My proposal was a step in the right direction but
> given that it's already insufficient I hereby withdraw
> it.
>
Re: PROPOSAL (was Re: Category-B tarballs in SVN )
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 16, 2012 at 6:07 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 15 January 2012 03:29, Rob Weir <ro...@apache.org> wrote:
>> On Fri, Jan 13, 2012 at 3:27 PM, Pedro Giffuni <pf...@apache.org> wrote:
>>> Hello fellow indians; ;)
>>>
>>> I think there is consensus that this is (at least)
>>> a gray area so I have the following proposal, which
>>> shouldn't get in the way of having this properly
>>> solved by legal but which I think should solve at
>>> least temporarily the issues that we have. It's
>>> actually very simple but who knows, maybe it's even
>>> acceptable as a general incubator policy at the ASF.
>>>
>>> The ext_source in shall be divided, according to
>>> the categories of the licenses, into two
>>> directories in SVN, namely:
>>>
>>> ext_source_A
>>> ext_source_B
>>>
>>
>> This is assuming all 3rd party modules are pure, under a single
>> license. I don't believe this is always the case.
>
> Then can /should they be put in the most restrictive category?
>
They certainly could. But the categories are really an creature of
Apache policy. They are not necessarily relevant to downstream
consumers, whose policies could be quite different than ours. That's
why it is good that we give the complete details in the LICENSE file
rather than some Apache-centric view of the world. That's why I think
it would be far more useful to summarize exactly what license applies.
We could even make a nice HTML table of this: component, version,
original URL, license, etc.
>> Why not treat it the way we treat 3rd party modules in releases, e.g.,
>> with a LICENSE and NOTICE file? We could put a LICENSE file in
>> /ext-src. That would make it clear to anyone who browses that
>> directory.
>
> +1
>
> On one of the projects I work on we require libraries to have a
> corresponding licences/FOOBAR_license.txt file This then allows some
> simple machine processing to check the license is correctly recorded
> against all libraries included. This is built into the build system
> and automatically flags when something seems to be missing.
>
That could work.
>>> - Ext_source_B shall have a prominent text note that warns
>>> users that the code there is made available only for
>>> builder convenience but that the code is in general
>>> not acceptable for inclusion in Apache source code
>>> releases.
>>>
>>
>> OK, though this is solving a problem we don't really have, right?
>
> I think the point is that it clearly separates out stuff that is OK to
> stay and stuff that needs to be carefully managed. It's a step towards
> satisfying those who are concerned about including this source whilst
> avoiding the need to remove the convenience for developers of having
> the source available.
>
We already do that. All of these third party modules are already
segregated from the main SVN tree. This is true regardless of
license. The legacy project didn't have them under version control.
They just stored them on a web server, totally separated from the
source code for OOo. That option did not appear to be available to
us at Apache, so we stick them in the ext-src directory in SVN.
> This separation will make it easier for people to evaluate the impact
> of these files when it comes to graduation and will serve to signal
> that there is a process in place for the management of these
> dependencies (or that there needs to be a process).
>
Or we could document exactly what we're doing now, the precautions
we're already taking. It seems that it would be hard to say whether
what we're doing already is inadequate if you don't know what exactly
we're already doing. Not you specifically, but in general.
>> So if we really want to give proper notice
>> to the person downloading our source release, this needs to be done:
>> 1) In the LICENSE and NOTICE files
>
> That has to happen anyway (for cat b licenses).
>
Category-b doesn't go out in released source packages. And for binary
packages we're already include the required licenses and
notifications.
>> Putting extra verbiage in the SVN tree that is not included in the
>> releases -- I don't see the point. Is this to protect casual browsers
>> of our SVN tree?
>
> For me the point is not about casual browers it is about developers
> like me who don't download source tars but instead checkout from SVN.
> We can't assume that all such developers will understand the nuances
> of license compatibility or even bother to check.
>
That maybe is the piece of the puzzle that may not be clear unless you
are a developer building AOO. You do not need to checkout the
category-b source bundles from SVN. In fact you should not. You
would only be wasting harddrive space. Our build doc doesn't call for
these modules to be checked-out. Someone would need to go out of
their way to check them out of SVN explicitly. The whole idea is that
these are downloaded via the build script, based on the configure
options chosen by the builder. If they want to build the default
binaries, with no category-b code, then of course, none of these
modules are downloaded. And if they want to enable the optional
category-b stuff, then they override the configure settings and the
bootstrap script downloads the additional components, according to the
user's platform. I believe this is done via http requests, not even
via an automated svn co.
We can't prevent someone from modifying the MPL code. But they would
need to go far out of their way to do this.
> Ross
Re: PROPOSAL (was Re: Category-B tarballs in SVN )
Posted by Andre Fischer <af...@a-w-f.de>.
On 16.01.2012 12:07, Ross Gardler wrote:
> On 15 January 2012 03:29, Rob Weir<ro...@apache.org> wrote:
[...]
>> Putting extra verbiage in the SVN tree that is not included in the
>> releases -- I don't see the point. Is this to protect casual browsers
>> of our SVN tree?
>
> For me the point is not about casual browers it is about developers
> like me who don't download source tars but instead checkout from SVN.
> We can't assume that all such developers will understand the nuances
> of license compatibility or even bother to check.
Maybe the ability of SVN to include/reference an external SVN repository
from another SVN repository can help (see [1]).
We could put the cat B tar-balls into an SVN repo, that is or is not
located on an Apache Server, and reference that repo from our OpenOffice
repository.
The developer, who checks out the source code, can then decide whether
to automatically checkout the cat B tar-balls together with the rest of
the code or to just check out the OpenOffice source.
One downside of this approach is the wrong default behavior on checkout:
the command "svn checkout" checks out all referenced external
repositories. In order to not include the cat B tar balls you have to
add the "--ignore-externals" option. But with a little bit of
documentation and by adding this option to the Source Control wiki page
[2] that is maybe OK.
-Andre
[1] http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html
[2] http://incubator.apache.org/openofficeorg/source.html
[...]
Re: PROPOSAL (was Re: Category-B tarballs in SVN )
Posted by Ross Gardler <rg...@opendirective.com>.
On 15 January 2012 03:29, Rob Weir <ro...@apache.org> wrote:
> On Fri, Jan 13, 2012 at 3:27 PM, Pedro Giffuni <pf...@apache.org> wrote:
>> Hello fellow indians; ;)
>>
>> I think there is consensus that this is (at least)
>> a gray area so I have the following proposal, which
>> shouldn't get in the way of having this properly
>> solved by legal but which I think should solve at
>> least temporarily the issues that we have. It's
>> actually very simple but who knows, maybe it's even
>> acceptable as a general incubator policy at the ASF.
>>
>> The ext_source in shall be divided, according to
>> the categories of the licenses, into two
>> directories in SVN, namely:
>>
>> ext_source_A
>> ext_source_B
>>
>
> This is assuming all 3rd party modules are pure, under a single
> license. I don't believe this is always the case.
Then can /should they be put in the most restrictive category?
> Why not treat it the way we treat 3rd party modules in releases, e.g.,
> with a LICENSE and NOTICE file? We could put a LICENSE file in
> /ext-src. That would make it clear to anyone who browses that
> directory.
+1
On one of the projects I work on we require libraries to have a
corresponding licences/FOOBAR_license.txt file This then allows some
simple machine processing to check the license is correctly recorded
against all libraries included. This is built into the build system
and automatically flags when something seems to be missing.
>> - Ext_source_B shall have a prominent text note that warns
>> users that the code there is made available only for
>> builder convenience but that the code is in general
>> not acceptable for inclusion in Apache source code
>> releases.
>>
>
> OK, though this is solving a problem we don't really have, right?
I think the point is that it clearly separates out stuff that is OK to
stay and stuff that needs to be carefully managed. It's a step towards
satisfying those who are concerned about including this source whilst
avoiding the need to remove the convenience for developers of having
the source available.
This separation will make it easier for people to evaluate the impact
of these files when it comes to graduation and will serve to signal
that there is a process in place for the management of these
dependencies (or that there needs to be a process).
> So if we really want to give proper notice
> to the person downloading our source release, this needs to be done:
> 1) In the LICENSE and NOTICE files
That has to happen anyway (for cat b licenses).
> Putting extra verbiage in the SVN tree that is not included in the
> releases -- I don't see the point. Is this to protect casual browsers
> of our SVN tree?
For me the point is not about casual browers it is about developers
like me who don't download source tars but instead checkout from SVN.
We can't assume that all such developers will understand the nuances
of license compatibility or even bother to check.
Ross
Re: PROPOSAL (was Re: Category-B tarballs in SVN )
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Rob;
I specifically avoided answering to this on Sunday because
in my religious beliefs it is a day to rest and I didn't
really want to spend time on this.
Since the time this was posted I think I have seen the light
(TM) and I am willing to share it with you if you have the
patience.
The comments that follow are NOT meant for the faint of
heart if you are likely to have strong feelings about this
please STOP READING NOW.
Also, if you are still here, remember ... don't kill
$MESSENGER.
--- Sab 14/1/12, Rob Weir <ro...@apache.org> ha scritto:
>
> OK, though this is solving a problem we don't really have,
> right?
> Although we have not yet built a script to produce a source
> package per Apache rules, when we do it will not include
> any of the /ext-src modules, correct? It won't include
> the category-a and it will not include the category-b
> either? What would be the point, since the
> build script brings down what it needs via the bootstrap,
> per the configuration flags used? So if we really want to
> give proper notice to the person downloading our source
> release, this needs to be done:
We do have to include Category-A in the release or the
release wont build. Separation has to happen.
Here is the first big flaw in your reasoning: there is no
such thing as a source release or a binary release, there
is simply a release.
Let me explain it this way: long, long ago, before the
Internet ever was, release engineers would talk about
preparing the distribution stuff they could put into
specific media as a Release. The media then was usually
tapes, later floppies, then CDs, and with the advent of
the Internet new forms of media appeared and new formats
corresponded to those distribution, ZIP files, .tar.gz
archives, you get the idea.
Eventually, new releases and updates were made available
by electronic means without dealing directly with tarballs
or zipfiles and the tendency is indeed to use such modern
methods when possible. One of such methods is called
"subversion" (SVN) and it has been very popular in the
advent of Opensource software, where the source code is
sometimes more important than the accidental binaries.
And the point here is: a release is not just what is
included in a source tarball or a zipfile it is
what is tagged and branched in SVN. Also, if you
check the documentation on how tags and branches
are created you will notice we have to clearly separate
what belongs to the release to what doesn't.
>
> I have no objections if you want to shuffle things around
> in the directory structure, and update bootstrap logic
> accordingly.
"shuffling" things is not a problem but I don't think
updating the bootstrap logic was mandatory. Our releases
have to build on their own and as you note the sources for
Category B stuff are not included anyways, but let me point
out the second big failure in your reasoning.
As I said before there is no such thing as "source releases"
or "binary releases" and such terms don't appear anywhere in
the the Apache licensing policies:
http://www.apache.org/legal/3party.html
Now, this phrase concerning Category-B has received a particular
wrong reading:
"Code that is more substantial, more volatile, or not directly
consumed at runtime in source form may only be distributed in
binary form."
We, and particularly you, have read this as a prohibition to
include MPL'd code in "source release" but the truth is that
it is a prohibition to distribute Category-B software *at
all*. Distribution certainly includes subversion.
The point is further clarified:
"In addition, C-based projects may have difficulty using works
under these licenses since they would have to deal with
platform-specific binaries, rather than just distributing
source that can be built on most any platform."
This last clarification has an upside: we can include in
our releases (and therefore in SVN) platform independent files
like Java bytecode and fonts under a Category-B license.
Pedro.
PS. My proposal was a step in the right direction but
given that it's already insufficient I hereby withdraw
it.
Re: PROPOSAL (was Re: Category-B tarballs in SVN )
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jan 13, 2012 at 3:27 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Hello fellow indians; ;)
>
> I think there is consensus that this is (at least)
> a gray area so I have the following proposal, which
> shouldn't get in the way of having this properly
> solved by legal but which I think should solve at
> least temporarily the issues that we have. It's
> actually very simple but who knows, maybe it's even
> acceptable as a general incubator policy at the ASF.
>
> The ext_source in shall be divided, according to
> the categories of the licenses, into two
> directories in SVN, namely:
>
> ext_source_A
> ext_source_B
>
This is assuming all 3rd party modules are pure, under a single
license. I don't believe this is always the case.
Why not treat it the way we treat 3rd party modules in releases, e.g.,
with a LICENSE and NOTICE file? We could put a LICENSE file in
/ext-src. That would make it clear to anyone who browses that
directory.
> - Ext_source_B shall have a prominent text note that warns
> users that the code there is made available only for
> builder convenience but that the code is in general
> not acceptable for inclusion in Apache source code
> releases.
>
OK, though this is solving a problem we don't really have, right?
Although we have not yet built a script to produce a source package
per Apache rules, when we do it will not include any of the /ext-src
modules, correct? It won't include the category-a and it will not
include the category-b either? What would be the point, since the
build script brings down what it needs via the bootstrap, per the
configuration flags used? So if we really want to give proper notice
to the person downloading our source release, this needs to be done:
1) In the LICENSE and NOTICE files. and 2) In the build instructions.
Putting extra verbiage in the SVN tree that is not included in the
releases -- I don't see the point. Is this to protect casual browsers
of our SVN tree?
I have no objections if you want to shuffle things around in the
directory structure, and update bootstrap logic accordingly. It is
your time. But given that these files are not included in our
releases, I don't think this solves the problem you originally set out
to solve.
> - It is understood that ext_source_B is a quarantine
> area. The idea is that the code we have there will
> only shrink with time. The code there can be updated
> for security reasons but in general no new code should
> be brought in without specific consensus (voting, checking
> with the PPMC, etc, but not lazy consensus).
>
> NOTE: Consensus for replacing standard OOo 3.4
> functionality like the CoinMP solver code is a given
> (particularly as the licensing is being worked on) but
> we don't want this to be a loophole to bring in MPL'd
> code into AOO.
>
> Of course we still have to comply with the standard
> Apache policies concerning Category-B : "Code that is
> more substantial, more volatile, or not directly consumed
> at runtime in source form may only be distributed in
> binary form." but at least now it should be pretty clear
> and easy for everyone downloading the code from SVN where
> they can expect licensing issues.
>
> Pedro.
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
Jeez Rob,
I'm tired of this. I am trying to put a full stop at the end of this.
I say again.
> What I, and I guess many other ASF Members, will want to avoid is to
> make it easier to modify code and archive it here as a fork than it is
> to work at getting the patches committed upstream.
> Where the AOO project feels this approach is unworkable I believe that
> a case for hosting source tarballs should be made to the legal team as
> I have tried to communicate earlier in this thread.
My mail acknowledged that I understand people here feel that a case can be
made. I am not arguing fire our against the case. I am communicating
*again* that this is an edge case with respect to existing ASF policy and I
am not the person to make a final decision on this.
Why you are still trying to argue with me? Either make the case our get on
with an interim solution. There is nothing more that can be productively
discussed about policy here.
Sent from my mobile device, please forgive errors and brevity.
On Jan 15, 2012 3:20 AM, "Rob Weir" <ro...@apache.org> wrote:
> On Sat, Jan 14, 2012 at 9:01 PM, Ross Gardler
> <rg...@opendirective.com> wrote:
> > On 13 January 2012 18:36, Rob Weir <ro...@apache.org> wrote:
> >> On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler
> >> <rg...@opendirective.com> wrote:
> >>> On 13 January 2012 17:38, Rob Weir <ro...@apache.org> wrote:
> >>>
> >>>> You are trying to argue the necessity point.
> >>>
> >>> I'm not arguing any point. I'm asking questions so that I might
> >>> understand what the sticking point is.
> >>>
> >>
> >> OK. You'll understand this better if you think of it as a
> >> configuration management question rather than a question of necessity.
> >
> > Thank you Rob. Of course this is well understood in a general context.
> > However, earlier in this thread I was informed that we were not
> > talking about situations where the code had been modified. I'm not
> > clear whether we are talking about hypothetical or real situations
> > here. There seems to be many contradictions in this thread.
> >
>
> The point Pedro brought up, and the point you are trying to argue
> against, is storage of MPL modules in SVN. That is what I am arguing
> for.
>
> > To be absolutely clear about my own position in the general context:
> >
> > If the third party code is available elsewhere then there is no need
> > to hold it here in AOO (if there is reason to believe the third party
> > host is at risk that is an edge case).
> >
>
> You say, "no need". I say "engineering prudence". This is not a
> policy question.
>
> > If third party code needs modification and those modifications have
> > been contributed to the upstream project but not yet included there
> > then those patches need to be stored here.
> >
>
> So you are arguing that there may be reasons for storing MPL code in SVN?
>
> > I realise that some want to store the full code here, I don't see the
> > need myself. In the past I've always maintained change sets and
> > checked out source and applied patches in the build scripts. I've
> > found that this encourages people to work upstream to get the patches
> > included. There is some short term pain for this, but in my experience
> > it is for long term gain. However, I do accept that this doesn't
> > always work out.
> >
>
> You say, "no need". I say "engineering prudence". This is not a
> policy question.
>
> > Where the AOO project feels this approach is unworkable I believe that
> > a case for hosting source tarballs should be made to the legal team as
> > I have tried to communicate earlier in this thread.
> >
>
> You say, "unworkable". I say "engineering prudence". This is not a
> policy question.
>
> > What I, and I guess many other ASF Members, will want to avoid is to
> > make it easier to modify code and archive it here as a fork than it is
> > to work at getting the patches committed upstream.
> >
>
> We avoid changing this code in other ways. Maybe this was not
> clear,or you did not read what was said previously. We do not store
> individual source files in SVN, as we would the core AOO code. We
> store tarballs, i.e., archived bundles of the complete module, with a
> name that includes an MD5 hash of the source code. This prevents
> anyone on this project from changing that modules without breaking the
> hash. We're doing only as little as is necessary to ensure the the
> 3rd party module is properly archived, as a service to the continuity
> of this project and to downstream consumers.
>
> Perhaps you underestimate the importance of this? This might be from
> lack of experience with software products of comparable size and
> complexity. AOO is unlike anything else you have at Apache, in terms
> of size and number of modules we integrate with. This is because
> unlike almost every other project, we are an end-user GUI application
> and need to integrate broadly with the platform at many levels, from
> install/uninstall, to address books, to crypto, to clipboard, to
> platform specific UI libraries, etc. The typical Apache product does
> only a small percentage of this.
>
> > In the meantime Pedro has made a suggestion that he feels will allow
> > the project to move forwards.
> >
> > Ross
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Sat, Jan 14, 2012 at 9:01 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 13 January 2012 18:36, Rob Weir <ro...@apache.org> wrote:
>> On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> On 13 January 2012 17:38, Rob Weir <ro...@apache.org> wrote:
>>>
>>>> You are trying to argue the necessity point.
>>>
>>> I'm not arguing any point. I'm asking questions so that I might
>>> understand what the sticking point is.
>>>
>>
>> OK. You'll understand this better if you think of it as a
>> configuration management question rather than a question of necessity.
>
> Thank you Rob. Of course this is well understood in a general context.
> However, earlier in this thread I was informed that we were not
> talking about situations where the code had been modified. I'm not
> clear whether we are talking about hypothetical or real situations
> here. There seems to be many contradictions in this thread.
>
The point Pedro brought up, and the point you are trying to argue
against, is storage of MPL modules in SVN. That is what I am arguing
for.
> To be absolutely clear about my own position in the general context:
>
> If the third party code is available elsewhere then there is no need
> to hold it here in AOO (if there is reason to believe the third party
> host is at risk that is an edge case).
>
You say, "no need". I say "engineering prudence". This is not a
policy question.
> If third party code needs modification and those modifications have
> been contributed to the upstream project but not yet included there
> then those patches need to be stored here.
>
So you are arguing that there may be reasons for storing MPL code in SVN?
> I realise that some want to store the full code here, I don't see the
> need myself. In the past I've always maintained change sets and
> checked out source and applied patches in the build scripts. I've
> found that this encourages people to work upstream to get the patches
> included. There is some short term pain for this, but in my experience
> it is for long term gain. However, I do accept that this doesn't
> always work out.
>
You say, "no need". I say "engineering prudence". This is not a
policy question.
> Where the AOO project feels this approach is unworkable I believe that
> a case for hosting source tarballs should be made to the legal team as
> I have tried to communicate earlier in this thread.
>
You say, "unworkable". I say "engineering prudence". This is not a
policy question.
> What I, and I guess many other ASF Members, will want to avoid is to
> make it easier to modify code and archive it here as a fork than it is
> to work at getting the patches committed upstream.
>
We avoid changing this code in other ways. Maybe this was not
clear,or you did not read what was said previously. We do not store
individual source files in SVN, as we would the core AOO code. We
store tarballs, i.e., archived bundles of the complete module, with a
name that includes an MD5 hash of the source code. This prevents
anyone on this project from changing that modules without breaking the
hash. We're doing only as little as is necessary to ensure the the
3rd party module is properly archived, as a service to the continuity
of this project and to downstream consumers.
Perhaps you underestimate the importance of this? This might be from
lack of experience with software products of comparable size and
complexity. AOO is unlike anything else you have at Apache, in terms
of size and number of modules we integrate with. This is because
unlike almost every other project, we are an end-user GUI application
and need to integrate broadly with the platform at many levels, from
install/uninstall, to address books, to crypto, to clipboard, to
platform specific UI libraries, etc. The typical Apache product does
only a small percentage of this.
> In the meantime Pedro has made a suggestion that he feels will allow
> the project to move forwards.
>
> Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 13 January 2012 18:36, Rob Weir <ro...@apache.org> wrote:
> On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 13 January 2012 17:38, Rob Weir <ro...@apache.org> wrote:
>>
>>> You are trying to argue the necessity point.
>>
>> I'm not arguing any point. I'm asking questions so that I might
>> understand what the sticking point is.
>>
>
> OK. You'll understand this better if you think of it as a
> configuration management question rather than a question of necessity.
Thank you Rob. Of course this is well understood in a general context.
However, earlier in this thread I was informed that we were not
talking about situations where the code had been modified. I'm not
clear whether we are talking about hypothetical or real situations
here. There seems to be many contradictions in this thread.
To be absolutely clear about my own position in the general context:
If the third party code is available elsewhere then there is no need
to hold it here in AOO (if there is reason to believe the third party
host is at risk that is an edge case).
If third party code needs modification and those modifications have
been contributed to the upstream project but not yet included there
then those patches need to be stored here.
I realise that some want to store the full code here, I don't see the
need myself. In the past I've always maintained change sets and
checked out source and applied patches in the build scripts. I've
found that this encourages people to work upstream to get the patches
included. There is some short term pain for this, but in my experience
it is for long term gain. However, I do accept that this doesn't
always work out.
Where the AOO project feels this approach is unworkable I believe that
a case for hosting source tarballs should be made to the legal team as
I have tried to communicate earlier in this thread.
What I, and I guess many other ASF Members, will want to avoid is to
make it easier to modify code and archive it here as a fork than it is
to work at getting the patches committed upstream.
In the meantime Pedro has made a suggestion that he feels will allow
the project to move forwards.
Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Jürgen Schmidt <jo...@googlemail.com>.
Am Freitag, 13. Januar 2012 schrieb Rob Weir <ro...@apache.org>:
> On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 13 January 2012 17:38, Rob Weir <ro...@apache.org> wrote:
>>
>>> You are trying to argue the necessity point.
>>
>> I'm not arguing any point. I'm asking questions so that I might
>> understand what the sticking point is.
>>
>
> OK. You'll understand this better if you think of it as a
> configuration management question rather than a question of necessity.
>
> Consider:
>
> AOO has a dependency on component X. Never mind the license. It
> could be anything. We have a dependency on X, specifically version 1.0
> of X. We, in the role of an integrator, write our code to integrate
> with X, version 1.0.
>
> We then release, it gets widely adopted. Time passes.
>
> The maintainers of X release version 1.1, with minor feature changes.
> Then they release version 1.2 with minor feature changes. AOO has no
> releases in the interim, so we're still dependent on X 1.0.
>
> Many things could go wrong at this point. For example, a critical
> security flaw is found in component X. The X project quickly release
> a new patched version, X 1.2.1 to fix the problem, and releases a
> package for that, source and binaries. For sake of argument say they
> do not patch versions 1.0 and 1.1.
>
> What do we do then?
>
> We could try to upgrade to version 1.2.1 of their component. It might
> be possible. We might hope it is possible. But it might not work.
> It could fail for any number of reasons. Time is ticking. Our users
> are at risk.
>
> What do we do?
>
> Well, obviously, we can apply the patch from 1.2.1 to 1.0 and fix the
> flaw in a way that works with our code and we get that new AOO out to
> users quickly. And at the same time we make available our patched 1.0
> available to the X project if they will host it. If not we make it
> available to downstream consumers, as courtesy, but not as an Apache
> release. And then we make an issue in Bugzilla to investigate more
> thoroughly how to upgrade to 1.2.1 in the future.
>
> It is not pretty, but prettiness is not a necessity either. The whole
> OSS universe does not march lock step on the same release schedule.
> We're not working with Legos. Things don't always just fit. We need
> to deal with the messiness of that reality. And obviously do it
> within policy.
>
> It could easily be every worse than that. Suppose, hypothetically,
> that we could upgrade our code to X 1.2.1, that it was not
> impractical. But we might still have another dependency, on component
> Y that also has its own dependency on X 1.0 and which does not work
> with X 1.2.1.
>
> Being an integrator of 3rd party components, regardless of license, is
> complex. You can get all sorts of interactions like this.
>
> What we need to do is get away from false alternatives, that either we
> have no category-b code in SVN, or we are subverting ASF policy and
> running stealth copyleft development efforts under the noses of the
> IPMC. There is plenty in the middle, including the prudent archiving
> of source code for 3rd party dependencies **regardless of license**
> and using them, in full conformance with Apache release policies, in
> order best to serve our users and downstream consumers.
>
> None of this would be necessary if there was some master OSS source
> code archive that was guaranteed to be as reliable and stable and
> secure and independent as Apache's SVN is. If such an alternative
> server existed, then we'd just use that. But one does not exist.
>
Thanks Rob, that's the mail I needed to finally go in the weekend.
Juergen
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 13 January 2012 17:38, Rob Weir <ro...@apache.org> wrote:
>
>> You are trying to argue the necessity point.
>
> I'm not arguing any point. I'm asking questions so that I might
> understand what the sticking point is.
>
OK. You'll understand this better if you think of it as a
configuration management question rather than a question of necessity.
Consider:
AOO has a dependency on component X. Never mind the license. It
could be anything. We have a dependency on X, specifically version 1.0
of X. We, in the role of an integrator, write our code to integrate
with X, version 1.0.
We then release, it gets widely adopted. Time passes.
The maintainers of X release version 1.1, with minor feature changes.
Then they release version 1.2 with minor feature changes. AOO has no
releases in the interim, so we're still dependent on X 1.0.
Many things could go wrong at this point. For example, a critical
security flaw is found in component X. The X project quickly release
a new patched version, X 1.2.1 to fix the problem, and releases a
package for that, source and binaries. For sake of argument say they
do not patch versions 1.0 and 1.1.
What do we do then?
We could try to upgrade to version 1.2.1 of their component. It might
be possible. We might hope it is possible. But it might not work.
It could fail for any number of reasons. Time is ticking. Our users
are at risk.
What do we do?
Well, obviously, we can apply the patch from 1.2.1 to 1.0 and fix the
flaw in a way that works with our code and we get that new AOO out to
users quickly. And at the same time we make available our patched 1.0
available to the X project if they will host it. If not we make it
available to downstream consumers, as courtesy, but not as an Apache
release. And then we make an issue in Bugzilla to investigate more
thoroughly how to upgrade to 1.2.1 in the future.
It is not pretty, but prettiness is not a necessity either. The whole
OSS universe does not march lock step on the same release schedule.
We're not working with Legos. Things don't always just fit. We need
to deal with the messiness of that reality. And obviously do it
within policy.
It could easily be every worse than that. Suppose, hypothetically,
that we could upgrade our code to X 1.2.1, that it was not
impractical. But we might still have another dependency, on component
Y that also has its own dependency on X 1.0 and which does not work
with X 1.2.1.
Being an integrator of 3rd party components, regardless of license, is
complex. You can get all sorts of interactions like this.
What we need to do is get away from false alternatives, that either we
have no category-b code in SVN, or we are subverting ASF policy and
running stealth copyleft development efforts under the noses of the
IPMC. There is plenty in the middle, including the prudent archiving
of source code for 3rd party dependencies **regardless of license**
and using them, in full conformance with Apache release policies, in
order best to serve our users and downstream consumers.
None of this would be necessary if there was some master OSS source
code archive that was guaranteed to be as reliable and stable and
secure and independent as Apache's SVN is. If such an alternative
server existed, then we'd just use that. But one does not exist.
-Rob
> Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 13 January 2012 17:38, Rob Weir <ro...@apache.org> wrote:
> You are trying to argue the necessity point.
I'm not arguing any point. I'm asking questions so that I might
understand what the sticking point is.
Ross
Re: PROPOSAL (was Re: Category-B tarballs in SVN )
Posted by Andre Fischer <af...@a-w-f.de>.
On 13.01.2012 21:27, Pedro Giffuni wrote:
> Hello fellow indians; ;)
>
> I think there is consensus that this is (at least)
> a gray area so I have the following proposal, which
> shouldn't get in the way of having this properly
> solved by legal but which I think should solve at
> least temporarily the issues that we have. It's
> actually very simple but who knows, maybe it's even
> acceptable as a general incubator policy at the ASF.
>
> The ext_source in shall be divided, according to
> the categories of the licenses, into two
> directories in SVN, namely:
>
> ext_source_A
> ext_source_B
main/ooo.lst already offers a poor-mans version of this. It has to
sections headed with comments
# Libraries with category A license
and
# Libraries with category B license
which reference the tar balls in ext_sources/ that have, surprise,
category A or category B license.
>
> - Ext_source_B shall have a prominent text note that warns
> users that the code there is made available only for
> builder convenience but that the code is in general
> not acceptable for inclusion in Apache source code
> releases.
>
> - It is understood that ext_source_B is a quarantine
> area. The idea is that the code we have there will
> only shrink with time. The code there can be updated
> for security reasons but in general no new code should
> be brought in without specific consensus (voting, checking
> with the PPMC, etc, but not lazy consensus).
This, I think, is an important point. Discourage people from adding more
cat-B tar-balls, and encourage developers to replace the existing ones
with category-A libraries.
We can start a Wiki page for the replacement tasks. I think some time
back you mentioned a possible replacement of rhino with V8.
-Andre
>
> NOTE: Consensus for replacing standard OOo 3.4
> functionality like the CoinMP solver code is a given
> (particularly as the licensing is being worked on) but
> we don't want this to be a loophole to bring in MPL'd
> code into AOO.
>
> Of course we still have to comply with the standard
> Apache policies concerning Category-B : "Code that is
> more substantial, more volatile, or not directly consumed
> at runtime in source form may only be distributed in
> binary form." but at least now it should be pretty clear
> and easy for everyone downloading the code from SVN where
> they can expect licensing issues.
>
> Pedro.
>
PROPOSAL (was Re: Category-B tarballs in SVN )
Posted by Pedro Giffuni <pf...@apache.org>.
Hello fellow indians; ;)
I think there is consensus that this is (at least)
a gray area so I have the following proposal, which
shouldn't get in the way of having this properly
solved by legal but which I think should solve at
least temporarily the issues that we have. It's
actually very simple but who knows, maybe it's even
acceptable as a general incubator policy at the ASF.
The ext_source in shall be divided, according to
the categories of the licenses, into two
directories in SVN, namely:
ext_source_A
ext_source_B
- Ext_source_B shall have a prominent text note that warns
users that the code there is made available only for
builder convenience but that the code is in general
not acceptable for inclusion in Apache source code
releases.
- It is understood that ext_source_B is a quarantine
area. The idea is that the code we have there will
only shrink with time. The code there can be updated
for security reasons but in general no new code should
be brought in without specific consensus (voting, checking
with the PPMC, etc, but not lazy consensus).
NOTE: Consensus for replacing standard OOo 3.4
functionality like the CoinMP solver code is a given
(particularly as the licensing is being worked on) but
we don't want this to be a loophole to bring in MPL'd
code into AOO.
Of course we still have to comply with the standard
Apache policies concerning Category-B : "Code that is
more substantial, more volatile, or not directly consumed
at runtime in source form may only be distributed in
binary form." but at least now it should be pretty clear
and easy for everyone downloading the code from SVN where
they can expect licensing issues.
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jan 13, 2012 at 12:31 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 13 January 2012 16:28, Rob Weir <ro...@apache.org> wrote:
>> On Fri, Jan 13, 2012 at 11:15 AM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> Sent from my mobile device, please forgive errors and brevity.
>>> On Jan 13, 2012 4:02 PM, "Andre Fischer" <af...@a-w-f.de> wrote:
>>>>
>>>>
>>>> On 13.01.2012 16:25, Ross Gardler wrote:
>>>>>
>>>>> For what it is worth, I agree with Joe here. The question is whether
>>> there
>>>>> is a valid reason to keep them here.
>>>>
>>>>
>>>> I don't know if the reasons are valid. We are trying to find a
>>> pragmatical solution that is a good compromise for the different
>>> requirements of the ASF, the OpenOffice developers/community, and the
>>> OpenOffice users:
>>>>
>>>> - For the ASF we use no code under category X license and try to use as
>>> little code under category B license.
>>>>
>>>> - For the users we want to retain as many features as possible.
>>>>
>>>> - For the developers we want to make development as accessible as
>>> possible.
>>>>
>>>
>>> Why is it necessary to include source rather than just binaries?
>>>
>>
>> With C/C++ code, binaries are built from source, and the source has to
>> come from somewhere. If there is a need to fix a security problem, we
>> need ready access to the source. The binaries alone would not be
>> sufficient.
>
> This is a modification of the code, which I was told earlier in this
> thread was not the case we were discussing. Is this a hypothetical or
> an actual situation? Why can't this situation be managed via the
> upstream project?
>
>> Also look at this from the perspective of a downstream consumer who is
>> porting the product to another platform. The binaries would be of
>> zero use to them,since the binaries would not be compiled for their
>> platform. But having the source archives for the dependencies readily
>> available, that is exactly what a porter would need.
>
> Why does the source have to come from AOO?
>
You are trying to argue the necessity point. I'm not. That is a red
herring. There is no necessity that we make things easier for
downstream consumers, that we react quickly to security issues, that
we maintain the code in a way that buffers us from changing URL's,
moving and canceled projects. None of this is required. But I think
it is a very good idea. I'm arguing common sense and engineering
prudence.
Remember, not every other open source project in the world practices
best practices with regards to hosting their source artifacts at
stable URL's, of maintaining prior versions indefinitely, of securing
their servers so no one hacks into them and changes source code, etc.
I'm arguing that this is a good thing, a service to downstream
consumers and is compatible with all Apache policies and the
principles behind them. Arguing whether or not it is necessary in a
cosmic sense is not useful. It is not necessary that this podling
even exist.
> Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 13 January 2012 16:28, Rob Weir <ro...@apache.org> wrote:
> On Fri, Jan 13, 2012 at 11:15 AM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> Sent from my mobile device, please forgive errors and brevity.
>> On Jan 13, 2012 4:02 PM, "Andre Fischer" <af...@a-w-f.de> wrote:
>>>
>>>
>>> On 13.01.2012 16:25, Ross Gardler wrote:
>>>>
>>>> For what it is worth, I agree with Joe here. The question is whether
>> there
>>>> is a valid reason to keep them here.
>>>
>>>
>>> I don't know if the reasons are valid. We are trying to find a
>> pragmatical solution that is a good compromise for the different
>> requirements of the ASF, the OpenOffice developers/community, and the
>> OpenOffice users:
>>>
>>> - For the ASF we use no code under category X license and try to use as
>> little code under category B license.
>>>
>>> - For the users we want to retain as many features as possible.
>>>
>>> - For the developers we want to make development as accessible as
>> possible.
>>>
>>
>> Why is it necessary to include source rather than just binaries?
>>
>
> With C/C++ code, binaries are built from source, and the source has to
> come from somewhere. If there is a need to fix a security problem, we
> need ready access to the source. The binaries alone would not be
> sufficient.
This is a modification of the code, which I was told earlier in this
thread was not the case we were discussing. Is this a hypothetical or
an actual situation? Why can't this situation be managed via the
upstream project?
> Also look at this from the perspective of a downstream consumer who is
> porting the product to another platform. The binaries would be of
> zero use to them,since the binaries would not be compiled for their
> platform. But having the source archives for the dependencies readily
> available, that is exactly what a porter would need.
Why does the source have to come from AOO?
Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jan 13, 2012 at 11:15 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> Sent from my mobile device, please forgive errors and brevity.
> On Jan 13, 2012 4:02 PM, "Andre Fischer" <af...@a-w-f.de> wrote:
>>
>>
>> On 13.01.2012 16:25, Ross Gardler wrote:
>>>
>>> For what it is worth, I agree with Joe here. The question is whether
> there
>>> is a valid reason to keep them here.
>>
>>
>> I don't know if the reasons are valid. We are trying to find a
> pragmatical solution that is a good compromise for the different
> requirements of the ASF, the OpenOffice developers/community, and the
> OpenOffice users:
>>
>> - For the ASF we use no code under category X license and try to use as
> little code under category B license.
>>
>> - For the users we want to retain as many features as possible.
>>
>> - For the developers we want to make development as accessible as
> possible.
>>
>
> Why is it necessary to include source rather than just binaries?
>
With C/C++ code, binaries are built from source, and the source has to
come from somewhere. If there is a need to fix a security problem, we
need ready access to the source. The binaries alone would not be
sufficient.
Also look at this from the perspective of a downstream consumer who is
porting the product to another platform. The binaries would be of
zero use to them,since the binaries would not be compiled for their
platform. But having the source archives for the dependencies readily
available, that is exactly what a porter would need.
> Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
Sent from my mobile device, please forgive errors and brevity.
On Jan 13, 2012 4:02 PM, "Andre Fischer" <af...@a-w-f.de> wrote:
>
>
> On 13.01.2012 16:25, Ross Gardler wrote:
>>
>> For what it is worth, I agree with Joe here. The question is whether
there
>> is a valid reason to keep them here.
>
>
> I don't know if the reasons are valid. We are trying to find a
pragmatical solution that is a good compromise for the different
requirements of the ASF, the OpenOffice developers/community, and the
OpenOffice users:
>
> - For the ASF we use no code under category X license and try to use as
little code under category B license.
>
> - For the users we want to retain as many features as possible.
>
> - For the developers we want to make development as accessible as
possible.
>
Why is it necessary to include source rather than just binaries?
Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Andre Fischer <af...@a-w-f.de>.
On 13.01.2012 16:25, Ross Gardler wrote:
> For what it is worth, I agree with Joe here. The question is whether there
> is a valid reason to keep them here.
I don't know if the reasons are valid. We are trying to find a
pragmatical solution that is a good compromise for the different
requirements of the ASF, the OpenOffice developers/community, and the
OpenOffice users:
- For the ASF we use no code under category X license and try to use as
little code under category B license.
- For the users we want to retain as many features as possible.
- For the developers we want to make development as accessible as possible.
We should also keep in mind that, compared to before the transition from
Oracle to Apache, at the moment there are only a few developers working
on the code:
- Every category B project that is removed will lead to missing features
because we do not have the resources to replace it.
- Loading the cat B tar balls from their home servers
a) is not always possible (eg because the version we use is no longer
available, or the server is not reliable or can not handle the load)
b) will make setting up of a development environment more difficult and
may scare away new developers
c) does not solve the underlying legal problems anyway (as far as I
understand the discussion so far)
>[...]
I think that we should try to work an a pragmatical compromise. We
should also keep our users in mind, which do not have a voice in this
discussion. An who may not be too interested in licenses and policies.
Regards,
Andre
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
For what it is worth, I agree with Joe here. The question is whether there
is a valid reason to keep them here.
Ross
Sent from my mobile device, please forgive errors and brevity.
On Jan 13, 2012 3:13 PM, "Joe Schaefer" <jo...@yahoo.com> wrote:
>
> Perfectly valid answer with one caveat:
> I don't know of any Apache policy that
> directly applies here. I'd bet that
>
> if httpd had what it considered a valid
> reason for including the source of a
> Category-B licensed product in their
> svn tree, nobody, not even the board,
> would have grounds to object, especially
> not if they'd passed the issue off
> to LEGAL and didn't receive a negative
> response.
>
>
>
>
> >________________________________
> > From: Pedro Giffuni <pf...@apache.org>
> >To: ooo-dev@incubator.apache.org; Joe Schaefer <jo...@yahoo.com>
> >Sent: Friday, January 13, 2012 10:08 AM
> >Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
> >
> >If you are asking me (and only me);
> >
> >--- Ven 13/1/12, Joe Schaefer <jo...@yahoo.com> ha scritto:
> >
> >> Why hasn't there been a LEGAL jira
> >> issue
> >> filed about this at this point? As I said
> >> it's a gray area that I'm certain the IPMC
> >> has no existing governing policy on, and I'm also
> >> certain that your mentors will disagree in
> >> the opinions they are providing to you.
> >>
> >
> >I don't like gray areas: I think we should comply
> >crystal clear with Apache policies and solve this
> >beyond doubt.
> >
> >As I said before, the solution is easy: dropping
> >the files from SVN and providing sufficient
> >instructions on where to get them.
> >
> >Pedro.
> >
> >
> >
> >
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Joe Schaefer <jo...@yahoo.com>.
Perfectly valid answer with one caveat:
I don't know of any Apache policy that
directly applies here. I'd bet that
if httpd had what it considered a valid
reason for including the source of a
Category-B licensed product in their
svn tree, nobody, not even the board,
would have grounds to object, especially
not if they'd passed the issue off
to LEGAL and didn't receive a negative
response.
>________________________________
> From: Pedro Giffuni <pf...@apache.org>
>To: ooo-dev@incubator.apache.org; Joe Schaefer <jo...@yahoo.com>
>Sent: Friday, January 13, 2012 10:08 AM
>Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
>
>If you are asking me (and only me);
>
>--- Ven 13/1/12, Joe Schaefer <jo...@yahoo.com> ha scritto:
>
>> Why hasn't there been a LEGAL jira
>> issue
>> filed about this at this point? As I said
>> it's a gray area that I'm certain the IPMC
>> has no existing governing policy on, and I'm also
>> certain that your mentors will disagree in
>> the opinions they are providing to you.
>>
>
>I don't like gray areas: I think we should comply
>crystal clear with Apache policies and solve this
>beyond doubt.
>
>As I said before, the solution is easy: dropping
>the files from SVN and providing sufficient
>instructions on where to get them.
>
>Pedro.
>
>
>
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Pedro Giffuni <pf...@apache.org>.
If you are asking me (and only me);
--- Ven 13/1/12, Joe Schaefer <jo...@yahoo.com> ha scritto:
> Why hasn't there been a LEGAL jira
> issue
> filed about this at this point? As I said
> it's a gray area that I'm certain the IPMC
> has no existing governing policy on, and I'm also
> certain that your mentors will disagree in
> the opinions they are providing to you.
>
I don't like gray areas: I think we should comply
crystal clear with Apache policies and solve this
beyond doubt.
As I said before, the solution is easy: dropping
the files from SVN and providing sufficient
instructions on where to get them.
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Joe Schaefer <jo...@yahoo.com>.
Why hasn't there been a LEGAL jira issue
filed about this at this point? As I said
it's a gray area that I'm certain the IPMC
has no existing governing policy on, and I'm also
certain that your mentors will disagree in
the opinions they are providing to you.
As a practical matter, I doubt the legal team
will express anything other than a preference,
deferring the policy question to the IPMC.
So if you are dissatisfied with their preference,
the nexthoop to jump thru is general@incubator,
where Ross' already-provided opinion is what
I'd bet the majority will agree with.
Good luck.
>________________________________
> From: Pedro Giffuni <pf...@apache.org>
>To: ooo-dev@incubator.apache.org; Joe Schaefer <jo...@yahoo.com>
>Sent: Friday, January 13, 2012 9:52 AM
>Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
>
>Hello;
>
>--- Ven 13/1/12, Joe Schaefer <jo...@yahoo.com> ha scritto:
>
>> It's certainly an edge case, and I'm not completely convinced
>> that I agree with you about it Ross. The ASF's position
>> on svn distributions is that you can put anything in there
>> that you like, provided we have the legal authority to
>> redistribute it. There are no other conditions to my knowledge,
>> which is why we've had GPL code amongst other code in there.
>>
>
>I for one signed an iCLA and considering section 7, I
>wouldn't go ahead and commit copyleft content to SVN
>without discussing it carefully.
>
>Rob has gone unilaterally about declaring what he
>thinks as a known truth and assuming because he wrote
>it on a wiki and no one has complained then it is the
>one true way (TM). In his defense I have to say he did
>ask the right questions but he didn't get concrete answers.
>
>I think Andrea Pescetti has given us a lesson on how things
>are done. Who knows, I think if Rob does a well thought
>proposal to legal@ and we all give our feedback concerning
>the shortcomings or relative virtues of this approach we may
>get to something.
>
>Pedro.
>
>
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 13 January 2012 13:23, Joe Schaefer <jo...@yahoo.com> wrote:
> It's certainly an edge case, and I'm not completely convinced
> that I agree with you about it Ross. The ASF's position on
> svn distributions is that you can put anything in there that
> you like, provided we have the legal authority to redistribute
> it. There are no other conditions to my knowledge, which is
> why we've had GPL code amongst other code in there.
Thanks Joe. It is useful to confirm this is an edge case and thus
needs proper guidance (prior to graduation, not prior to release) from
legal@ as suggested by Pedro.
For the benefit of PPMC understanding there are many factors affecting
whether this would be OK, these include, but are not limited to:
- is the source modified
- is there a good reason not to pull the source from upstream
- is there good reason why we don't make binaries available
(preferably via upstream)
- is the component a required component
In general, it is my understanding that, the ASF prefers not to host
code that the ASF does not own unless it is the only sensible option.
So the question is whether it is the only sensible option.
Ross
>
>
>
> ----- Original Message -----
>> From: Ross Gardler <rg...@opendirective.com>
>> To: ooo-dev@incubator.apache.org
>> Cc:
>> Sent: Friday, January 13, 2012 8:17 AM
>> Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
>>
>> On 13 January 2012 12:31, Rob Weir <ro...@apache.org> wrote:
>>> On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler
>>> <rg...@opendirective.com> wrote:
>>>> On 13 January 2012 01:31, Rob Weir <ro...@apache.org> wrote:
>>>>> On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler
>>>>> <rg...@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
>>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Pedro Giffuni <pf...@apache.org>.
Hello;
--- Ven 13/1/12, Joe Schaefer <jo...@yahoo.com> ha scritto:
> It's certainly an edge case, and I'm not completely convinced
> that I agree with you about it Ross. The ASF's position
> on svn distributions is that you can put anything in there
> that you like, provided we have the legal authority to
> redistribute it. There are no other conditions to my knowledge,
> which is why we've had GPL code amongst other code in there.
>
I for one signed an iCLA and considering section 7, I
wouldn't go ahead and commit copyleft content to SVN
without discussing it carefully.
Rob has gone unilaterally about declaring what he
thinks as a known truth and assuming because he wrote
it on a wiki and no one has complained then it is the
one true way (TM). In his defense I have to say he did
ask the right questions but he didn't get concrete answers.
I think Andrea Pescetti has given us a lesson on how things
are done. Who knows, I think if Rob does a well thought
proposal to legal@ and we all give our feedback concerning
the shortcomings or relative virtues of this approach we may
get to something.
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Joe Schaefer <jo...@yahoo.com>.
It's certainly an edge case, and I'm not completely convinced
that I agree with you about it Ross. The ASF's position on
svn distributions is that you can put anything in there that
you like, provided we have the legal authority to redistribute
it. There are no other conditions to my knowledge, which is
why we've had GPL code amongst other code in there.
----- Original Message -----
> From: Ross Gardler <rg...@opendirective.com>
> To: ooo-dev@incubator.apache.org
> Cc:
> Sent: Friday, January 13, 2012 8:17 AM
> Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
>
> On 13 January 2012 12:31, Rob Weir <ro...@apache.org> wrote:
>> On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> On 13 January 2012 01:31, Rob Weir <ro...@apache.org> wrote:
>>>> On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler
>>>> <rg...@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
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 13 January 2012 12:31, Rob Weir <ro...@apache.org> wrote:
> On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 13 January 2012 01:31, Rob Weir <ro...@apache.org> wrote:
>>> On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler
>>> <rg...@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
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jan 13, 2012 at 6:16 AM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 13 January 2012 01:31, Rob Weir <ro...@apache.org> wrote:
>> On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler
>> <rg...@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
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 13 January 2012 01:31, Rob Weir <ro...@apache.org> wrote:
> On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler
> <rg...@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?
...
> 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.
My original question in that thread was:
"What I'm interested in at this point is getting an authoritative
answer to the specific question of having GPL software in an
incubating projects SVN and, subsequently, in a TLPs SVN. This
information will feed into the wider discussions about whether having
it there is the optimal solution."
Note this is about GPL not about MPL. There are similarities but it
would be wrong to assume the conclusions there necessarily apply here.
However, the policy in question is indeed the same one so some lessons
may be drawn from that thread.
After a few false starts from other commentators Sam said:
"One of the purposes of incubation is IP clearance. What that means is
that in order to exit incubation the distribution must conform to our
policies, which includes not distributing code under the GPL license.
Is it the intent to resolve this prior to exiting incubation?"
Elsewhere in this thread Rob states that the MPL source in question is
not in the distribution. Since the ASF *only* distributes source
releases I don't really see how this can be the case. If it is true
then why is it in our SVN?
Furthermore, in my opinion our SVN is a form of distribution (I'm not
sure if this view is also held by the VP Legal).
Back to the legal-discuss thread. In response to Sams question above I
clarified that this was the root cause of the conflicting advice the
AOO podling was getting:
"This is ultimately the question. One view is that the GPL build tool
dependency would need to be removed in order to graduate (or would be a
separate download from non-ASF hardware). However other advice is that as
long as it is not distributed in a release (source or binary) it is OK to
have a build dependency on GPL code that is stored on ASF hardware."
So, we can see this is a similar issue. It does refer to GPL rather
than MPL, so it can (and should) be argued that it is not the same
issue. Nevertheless since Rob provides this thread as evidence to
support his counter argument to Pedro lets continue...
"My expectations are that this podling would not successfully graduate
with a dependency as you described it." (Sam Ruby)
Some more unimportant distractions and I try to bring things back on
track with a closing statement:
"Jurgen has indicated that there is a plan to move away from this GPL
code before graduation, however on the dev list this plan has not yet
been finalised and my assertion that we do not, as a matter of policy,
have GPL code on our servers has been questioned by the OOo community.
I was seeking a clarification on this specific case as a test case for
other similar issues relating to GPL dependencies that will come up in
the near future (in fact have already emerged on the OOo-dev list).
I now have the clarification that I needed in order to enable the
OOo-dev discussion to proceed (thank you Sam)."
Note how I explicitly state that this issue was taken to the
legal-discuss list as a test case for similar issues. Here we are,
revisiting it with a similar case. It's interesting that the advice
from the legal team was the same advice I gave in the original
contested thread [1].
Finally, for completeness allow me to quote from the part of the
thread Rob links to. I'd hate to appear to be ignoring the specific
evidence provided:
"In the short term, everyone agrees that checking the source of this
into ASF SVN is not acceptable." (Benson)
A statement that was, in my opinion too strong, Sam responded:
"I for one never said that. If there is a demonstrable need coupled
with a credible plan then we could discuss how to address the issue."
Sam concludes with "Automatically installing GPL code on developer's
machines is the issue to be worked. Once the plan is in place to
address that issue, we can
work backwards and see what we can do in the interim. Those
discussions can be held with the larger ASF Legal board committee."
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.
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.
>> 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.
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?
...
> 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).
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.
In the meantime I see different people starting to work with Pedro to
explore the options around a) and b) (thank you).
Ross
[1] http://markmail.org/message/xerohd43bh7giipk
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 12, 2012 at 8:03 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 13 January 2012 00:23, Rob Weir <ro...@apache.org> wrote:
>> On Thu, Jan 12, 2012 at 7:13 PM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> On 13 January 2012 00:09, Rob Weir <ro...@apache.org> wrote:
>>>> On Thu, Jan 12, 2012 at 7:05 PM, Ross Gardler
>>>> <rg...@opendirective.com> wrote:
>>>>> On 12 January 2012 23:50, Rob Weir <ro...@apache.org> wrote:
>>>>>> On Thu, Jan 12, 2012 at 6:42 PM, Ross Gardler
>>>>>> <rg...@opendirective.com> wrote:
>>>>>>> On 12 January 2012 19:28, Rob Weir <ro...@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
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 13 January 2012 00:23, Rob Weir <ro...@apache.org> wrote:
> On Thu, Jan 12, 2012 at 7:13 PM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 13 January 2012 00:09, Rob Weir <ro...@apache.org> wrote:
>>> On Thu, Jan 12, 2012 at 7:05 PM, Ross Gardler
>>> <rg...@opendirective.com> wrote:
>>>> On 12 January 2012 23:50, Rob Weir <ro...@apache.org> wrote:
>>>>> On Thu, Jan 12, 2012 at 6:42 PM, Ross Gardler
>>>>> <rg...@opendirective.com> wrote:
>>>>>> On 12 January 2012 19:28, Rob Weir <ro...@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."
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
> 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.
> 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.
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.
Ross
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 12, 2012 at 7:13 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 13 January 2012 00:09, Rob Weir <ro...@apache.org> wrote:
>> On Thu, Jan 12, 2012 at 7:05 PM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> On 12 January 2012 23:50, Rob Weir <ro...@apache.org> wrote:
>>>> On Thu, Jan 12, 2012 at 6:42 PM, Ross Gardler
>>>> <rg...@opendirective.com> wrote:
>>>>> On 12 January 2012 19:28, Rob Weir <ro...@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"
And if you can give me a link to the relevant Apache policy on this,
I'd much appreciate that as well. 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.
Saying "we've never done that before" is not an argument from policy.
It is an argument from inexperience. If you'll acknowledge that there
is no policy for this, then that would serve to clear the air on that
particular point and then we could ask for some policy parameters in
this area.
> Ross
>
> Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 13 January 2012 00:09, Rob Weir <ro...@apache.org> wrote:
> On Thu, Jan 12, 2012 at 7:05 PM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 12 January 2012 23:50, Rob Weir <ro...@apache.org> wrote:
>>> On Thu, Jan 12, 2012 at 6:42 PM, Ross Gardler
>>> <rg...@opendirective.com> wrote:
>>>> On 12 January 2012 19:28, Rob Weir <ro...@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?
Ross
Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 12, 2012 at 7:05 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 12 January 2012 23:50, Rob Weir <ro...@apache.org> wrote:
>> On Thu, Jan 12, 2012 at 6:42 PM, Ross Gardler
>> <rg...@opendirective.com> wrote:
>>> On 12 January 2012 19:28, Rob Weir <ro...@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.
-Rob
> Ross
>
>
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 12 January 2012 23:50, Rob Weir <ro...@apache.org> wrote:
> On Thu, Jan 12, 2012 at 6:42 PM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 12 January 2012 19:28, Rob Weir <ro...@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.
Ross
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 12, 2012 at 6:42 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 12 January 2012 19:28, Rob Weir <ro...@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.
> If you want an official statement from legal you have to ask
> legal-discuss@ about the specific case in hand.
>
If others have doubt, they are welcome to chase after this.
> Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 12 January 2012 19:28, Rob Weir <ro...@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 want an official statement from legal you have to ask
legal-discuss@ about the specific case in hand.
Ross
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Dave Fisher <da...@comcast.net>.
+1000. I think this thread is actually getting somewhere. The 45 minutes reading it have been better than the 30 minutes yesterday.
Regards,
Dave
Sent from my iPhone
On Jan 13, 2012, at 10:35 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> Please do not step down from the PPMC Pedro,
> you have done good work here and it is very important
> that the PPMC consist of such people going forward.
>
>
> Creating a class of active committers who are not
> on the PPMC will not help move this project closer
> to graduation. Let's please avoid that circumstance
> over what appears to be a simple disagreement.
>
>
> ----- Original Message -----
>> From: Pedro Giffuni <pf...@apache.org>
>> To: ooo-dev@incubator.apache.org
>> Cc:
>> Sent: Friday, January 13, 2012 11:31 AM
>> Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
>>
>> --- Ven 13/1/12, Jürgen Schmidt ha scritto:
>> ...
>>>
>>> well that is a valid point that comes into my mind as well
>>> when I have read the mails and thought a little bit longer.
>>>
>>> If that is the only reason than we can move it besides
>>> trunk. But that is a technical solution only and it doesn't
>>> solve the underlying problem.
>>>
>>> And what is more important we can't exchange everything now
>>> and we can't remove all the features that depends on this
>>> category-b stuff. Otherwise the office is no longer useable
>>> and we can stop here or can kill the project directly.
>>>
>>
>> I am only asking for the technical solution. I think we
>> have discussed sufficiently that replacing this stuff
>> is possible but will take time.
>>
>> I am also not setting any time frame for moving those files.
>> beyond that we should do it somewhen before release.
>>
>>>
>>> The whole discussion is not really motivating for project
>>> members and of course does not really promote the Apache way
>>> or the ASF in general.
>>>
>>
>> I agree it's not very motivating but in my defense it was
>> something that had to be discussed sooner better than later.
>>
>>>
>>> So we always have to take Windows into account and on
>>> Windows you don't have system libraries for this stuff.
>>>
>>
>> We can do packages of this stuff. It will even save time
>> from building over and over again the same stuff.
>>
>>> So please come back to reality.
>>>
>>
>>> Juergen
>>>
>>> PS who will go demotivated into the weekend
>>>
>>
>>
>> OK, this is something I really didn't intend. This was
>> meant to be discussed on a strictly technical level
>> without demotivating developers or calling "bloody
>> murder" on the project.
>>
>> I hereby drop *any* claim that we may not be complying
>> with any relevant policy. Also to give full assurance
>> that I will not be problem to the project I will be
>> stepping down from the PPMC so my vote will not be
>> binding: I am really only interested in technical
>> discussions anyway.
>>
>> Pedro.
>>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Ross Gardler <rg...@opendirective.com>.
On 13 January 2012 16:35, Joe Schaefer <jo...@yahoo.com> wrote:
> Please do not step down from the PPMC Pedro,
> you have done good work here and it is very important
> that the PPMC consist of such people going forward.
+1000
> Creating a class of active committers who are not
> on the PPMC will not help move this project closer
> to graduation. Let's please avoid that circumstance
> over what appears to be a simple disagreement.
+1000 - there are many difficult things to resolve, we need all
perspectives to find the optimal solution.
Ross
>
>
> ----- Original Message -----
>> From: Pedro Giffuni <pf...@apache.org>
>> To: ooo-dev@incubator.apache.org
>> Cc:
>> Sent: Friday, January 13, 2012 11:31 AM
>> Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
>>
>> --- Ven 13/1/12, Jürgen Schmidt ha scritto:
>> ...
>>>
>>> well that is a valid point that comes into my mind as well
>>> when I have read the mails and thought a little bit longer.
>>>
>>> If that is the only reason than we can move it besides
>>> trunk. But that is a technical solution only and it doesn't
>>> solve the underlying problem.
>>>
>>> And what is more important we can't exchange everything now
>>> and we can't remove all the features that depends on this
>>> category-b stuff. Otherwise the office is no longer useable
>>> and we can stop here or can kill the project directly.
>>>
>>
>> I am only asking for the technical solution. I think we
>> have discussed sufficiently that replacing this stuff
>> is possible but will take time.
>>
>> I am also not setting any time frame for moving those files.
>> beyond that we should do it somewhen before release.
>>
>>>
>>> The whole discussion is not really motivating for project
>>> members and of course does not really promote the Apache way
>>> or the ASF in general.
>>>
>>
>> I agree it's not very motivating but in my defense it was
>> something that had to be discussed sooner better than later.
>>
>>>
>>> So we always have to take Windows into account and on
>>> Windows you don't have system libraries for this stuff.
>>>
>>
>> We can do packages of this stuff. It will even save time
>> from building over and over again the same stuff.
>>
>>> So please come back to reality.
>>>
>>
>>> Juergen
>>>
>>> PS who will go demotivated into the weekend
>>>
>>
>>
>> OK, this is something I really didn't intend. This was
>> meant to be discussed on a strictly technical level
>> without demotivating developers or calling "bloody
>> murder" on the project.
>>
>> I hereby drop *any* claim that we may not be complying
>> with any relevant policy. Also to give full assurance
>> that I will not be problem to the project I will be
>> stepping down from the PPMC so my vote will not be
>> binding: I am really only interested in technical
>> discussions anyway.
>>
>> Pedro.
>>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Pedro Giffuni <pf...@apache.org>.
Hello Joe;
--- Ven 13/1/12, Joe Schaefer <jo...@yahoo.com> ha scritto:
> Please do not step down from the PPMC
> Pedro,
> you have done good work here and it is very important
> that the PPMC consist of such people going forward.
>
>
> Creating a class of active committers who are not
> on the PPMC will not help move this project closer
> to graduation. Let's please avoid that circumstance
> over what appears to be a simple disagreement.
>
It is a simple disagreement but I happen to feel exactly
like Juergen about this. There is an interesting, and
rather funny, theory to explain this situation and
technically speaking we are in a region of stupidity:
http://cantrip.org/stupidity.html
At this time it is better to leave such region so I am
willing to drop this discussion entirely.
If things come to vote I do have to be consistent with
what I think and it would probably be better to the
to avoid me causing conflicts, but I will better take
such a decision with a clear head and not now.
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Joe Schaefer <jo...@yahoo.com>.
Please do not step down from the PPMC Pedro,
you have done good work here and it is very important
that the PPMC consist of such people going forward.
Creating a class of active committers who are not
on the PPMC will not help move this project closer
to graduation. Let's please avoid that circumstance
over what appears to be a simple disagreement.
----- Original Message -----
> From: Pedro Giffuni <pf...@apache.org>
> To: ooo-dev@incubator.apache.org
> Cc:
> Sent: Friday, January 13, 2012 11:31 AM
> Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
>
> --- Ven 13/1/12, Jürgen Schmidt ha scritto:
> ...
>>
>> well that is a valid point that comes into my mind as well
>> when I have read the mails and thought a little bit longer.
>>
>> If that is the only reason than we can move it besides
>> trunk. But that is a technical solution only and it doesn't
>> solve the underlying problem.
>>
>> And what is more important we can't exchange everything now
>> and we can't remove all the features that depends on this
>> category-b stuff. Otherwise the office is no longer useable
>> and we can stop here or can kill the project directly.
>>
>
> I am only asking for the technical solution. I think we
> have discussed sufficiently that replacing this stuff
> is possible but will take time.
>
> I am also not setting any time frame for moving those files.
> beyond that we should do it somewhen before release.
>
>>
>> The whole discussion is not really motivating for project
>> members and of course does not really promote the Apache way
>> or the ASF in general.
>>
>
> I agree it's not very motivating but in my defense it was
> something that had to be discussed sooner better than later.
>
>>
>> So we always have to take Windows into account and on
>> Windows you don't have system libraries for this stuff.
>>
>
> We can do packages of this stuff. It will even save time
> from building over and over again the same stuff.
>
>> So please come back to reality.
>>
>
>> Juergen
>>
>> PS who will go demotivated into the weekend
>>
>
>
> OK, this is something I really didn't intend. This was
> meant to be discussed on a strictly technical level
> without demotivating developers or calling "bloody
> murder" on the project.
>
> I hereby drop *any* claim that we may not be complying
> with any relevant policy. Also to give full assurance
> that I will not be problem to the project I will be
> stepping down from the PPMC so my vote will not be
> binding: I am really only interested in technical
> discussions anyway.
>
> Pedro.
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Joe Schaefer <jo...@yahoo.com>.
Your mentors would prefer to treat the
members of this podling as a group of
adults, and if given compelling reasons
to do unusual things in this podling
will often avoid telling you otherwise.
But if people insist on infighting and backbiting
each other about differences of opinions, we'll
just shut up and wait for more intelligent emails
to emerge.
I've given the group my opinion on how to proceed
on this issue if the consensus of the PPMC is to
continue including Category-B sources in its svn
tree. Please don't make me think I've wasted my
time in providing that opinion.
>________________________________
> From: Jürgen Schmidt <jo...@googlemail.com>
>To: ooo-dev@incubator.apache.org
>Sent: Friday, January 13, 2012 10:32 AM
>Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
>
>On 1/13/12 3:42 PM, Pedro Giffuni wrote:
>>
>>
>> --- Ven 13/1/12, Andre Fischer<af...@a-w-f.de> ha scritto:
>> ...
>>>>
>>>> I think the issue is very easy to resolve: drop the
>>>> tarballs from SVN and provide sufficient instructions
>>>> so that the people doing the builds can download the
>>>> tarballs themselves: we even have nice "fetch_tarball.sh"
>>>> script to do just that.
>>>
>>> I am not quite sure that I understand the problem here.
>>
>> Well perhaps I can explain it better as I *am* creating
>> source releases for my own personal use.
>>
>> The normal way to build a source releases is to pull the
>> code from SVN (as described in the web page). This will
>> download category-A and Category-B software. Category-B
>> is not built by default but it is in the same directory
>> with Category-A software so I don't find a clear
>> separation.
>
>well that is a valid point that comes into my mind as well when I have read the mails and thought a little bit longer.
>
>If that is the only reason than we can move it besides trunk. But that is a technical solution only and it doesn't solve the underlying problem.
>
>And what is more important we can't exchange everything now and we can't remove all the features that depends on this category-b stuff. Otherwise the office is no longer useable and we can stop here or can kill the project directly.
>
>Or we take it serious and find compromises and exchange stuff over time when possible.
>
>Apache got for whatever reason the source grant and the trademarks of one of the biggest and most successful open source projects. So far so good. Normally I would expect the organization would be happy and would do everything that this project can continue in the way as before. Yes there are changes necessary and again we are working on it but we can't do everything at once ...
>
>The whole discussion is not really motivating for project members and of course does not really promote the Apache way or the ASF in general.
>
>>
>> Technically, we are indeed forking the mozilla code: we
>> carry the source tarballs and patches, so we indeed have
>> our own distributions here and that is a legal gray area.
>maybe but again we don't have any other chance here right now. We can only work on it in the future and can try to replace it by newer code. But we need somebody who can do that, it's far from trivial.
>
>>
>> FWIW, I use saxon prepackaged already an I will likely be
>> using theprepackaged beanshell so I don't need
>> those tarballs. Seamonkey takes too long to build and
>> nss involves security risks so this just adds bloat
>> to my sources.
>it's your personal opinion and many users simply rely on these features and use it. Your are on FreeBSD a minor platform that has no real relevance for the user base of OpenOffice.
>
>So we always have to take Windows into account and on Windows you don't have system libraries for this stuff.
>
>So please come back to reality.
>
>Juergen
>
>PS who will go demotivated into the weekend
>
>>
>>
>>> Would it be OK to move the category-b tar balls to eg
>>> SourceForge or Google and just adapt the URL in the
>>> ooo.lst file?
>>>
>>
>> I was thinking we should point users directly to the
>> mozilla foundation but I think an external site would
>> effectively solve the Category-B issues.
>>
>> All just IMHO.
>>
>> Pedro.
>>
>
>
>
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Dave Fisher <da...@comcast.net>.
Pedro,
+1000 to your plan. It is another step in the correct direction.
Best Regards,
Dave
Sent from my iPhone
On Jan 13, 2012, at 2:46 PM, Pedro Giffuni <pf...@apache.org> wrote:
> Hi Dennis;
>
> --- Ven 13/1/12, Dennis E. Hamilton <or...@apache.org> ha scritto:
>
>> Pedro,
>>
>> That seems like a silly reason to step down from the
>> PPMC.
>>
>> Nothing discussed here has involved a vote and it is not an
>> ooo-private discussion.
>>
>> There is no obligation to vote on any issue and an
>> abstention can be cast with no need for explanation.
>>
>
> I don't want to abstain and I do feel that it's
> preferable to step down if my position causes grief
> to the community, plus this discussion has taken
> already too much time from doing real development.
>
> I think my recent proposal is very flexible though.
> I still think copyleft tarballs in SVN are not OK,
> but at least this should set straight what our
> plans for those tarballs are.
>
> Pedro.
>
RE: Category-B tarballs in SVN (was Re: External libraries)
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Dennis;
--- Ven 13/1/12, Dennis E. Hamilton <or...@apache.org> ha scritto:
> Pedro,
>
> That seems like a silly reason to step down from the
> PPMC.
>
> Nothing discussed here has involved a vote and it is not an
> ooo-private discussion.
>
> There is no obligation to vote on any issue and an
> abstention can be cast with no need for explanation.
>
I don't want to abstain and I do feel that it's
preferable to step down if my position causes grief
to the community, plus this discussion has taken
already too much time from doing real development.
I think my recent proposal is very flexible though.
I still think copyleft tarballs in SVN are not OK,
but at least this should set straight what our
plans for those tarballs are.
Pedro.
RE: Category-B tarballs in SVN (was Re: External libraries)
Posted by "Dennis E. Hamilton" <or...@apache.org>.
Pedro,
That seems like a silly reason to step down from the PPMC.
Nothing discussed here has involved a vote and it is not an ooo-private discussion.
There is no obligation to vote on any issue and an abstention can be cast with no need for explanation.
On a vote carried out on ooo-dev, you can always cast a non-binding vote (or not vote or abstain), although it would be strange to do it that way.
Since you are not attempting to veto something, the fact that you are a PPMC member is hardly disruptive to this discussion, which calls attention to edge cases that need to be understood and resolved for graduation to occur. It strikes me that you are raising an appropriate concern that is consistent with the responsibilities of the PPMC.
Without expressing a view on deliberation itself, I want to affirm that avoiding a course that may be incompatible with graduation and costly to recover from is an appropriate risk-management consideration.
- Dennis
-----Original Message-----
From: Pedro Giffuni [mailto:pfg@apache.org]
Sent: Friday, January 13, 2012 08:32
To: ooo-dev@incubator.apache.org
Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
--- Ven 13/1/12, Jürgen Schmidt ha scritto:
...
[ ... ]
>
> The whole discussion is not really motivating for project
> members and of course does not really promote the Apache way
> or the ASF in general.
>
I agree it's not very motivating but in my defense it was
something that had to be discussed sooner better than later.
>
> So we always have to take Windows into account and on
> Windows you don't have system libraries for this stuff.
>
We can do packages of this stuff. It will even save time
from building over and over again the same stuff.
> So please come back to reality.
>
> Juergen
>
> PS who will go demotivated into the weekend
>
OK, this is something I really didn't intend. This was
meant to be discussed on a strictly technical level
without demotivating developers or calling "bloody
murder" on the project.
I hereby drop *any* claim that we may not be complying
with any relevant policy. Also to give full assurance
that I will not be problem to the project I will be
stepping down from the PPMC so my vote will not be
binding: I am really only interested in technical
discussions anyway.
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Jürgen Schmidt <jo...@googlemail.com>.
Am Freitag, 13. Januar 2012 schrieb Pedro Giffuni <pf...@apache.org>:
> --- Ven 13/1/12, Jürgen Schmidt ha scritto:
> ...
>>
>> well that is a valid point that comes into my mind as well
>> when I have read the mails and thought a little bit longer.
>>
>> If that is the only reason than we can move it besides
>> trunk. But that is a technical solution only and it doesn't
>> solve the underlying problem.
>>
>> And what is more important we can't exchange everything now
>> and we can't remove all the features that depends on this
>> category-b stuff. Otherwise the office is no longer useable
>> and we can stop here or can kill the project directly.
>>
>
> I am only asking for the technical solution. I think we
> have discussed sufficiently that replacing this stuff
> is possible but will take time.
>
> I am also not setting any time frame for moving those files.
> beyond that we should do it somewhen before release.
>
>>
>> The whole discussion is not really motivating for project
>> members and of course does not really promote the Apache way
>> or the ASF in general.
>>
>
> I agree it's not very motivating but in my defense it was
> something that had to be discussed sooner better than later.
>
>>
>> So we always have to take Windows into account and on
>> Windows you don't have system libraries for this stuff.
>>
>
> We can do packages of this stuff. It will even save time
> from building over and over again the same stuff.
I would prefer to build it where possible.
>
>> So please come back to reality.
>>
>
>> Juergen
>>
>> PS who will go demotivated into the weekend
>>
>
>
> OK, this is something I really didn't intend. This was
> meant to be discussed on a strictly technical level
> without demotivating developers or calling "bloody
> murder" on the project.
I don't have a problem with your mail I simply thought wr had solved this.
At least in a way that is not optimal but aligned with Apache.
What makes me crazy was the style of the discussion. I don't like it to
play with words, phrasing and persnicketiness. As a non native speaker I
can only loose here 😉
>
> I hereby drop *any* claim that we may not be complying
> with any relevant policy. Also to give full assurance
> that I will not be problem to the project I will be
> stepping down from the PPMC so my vote will not be
> binding: I am really only interested in technical
> discussions anyway.
Please don't do that your input is always highly appreciated. But it's
simply hard to follow policies that are not written down exactly.
So again my comment has nothing to do with your person, or the topic you
wanted to address. It's simply the style of the communication.
Juergen.
>
> Pedro.
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Ven 13/1/12, Jürgen Schmidt ha scritto:
...
>
> well that is a valid point that comes into my mind as well
> when I have read the mails and thought a little bit longer.
>
> If that is the only reason than we can move it besides
> trunk. But that is a technical solution only and it doesn't
> solve the underlying problem.
>
> And what is more important we can't exchange everything now
> and we can't remove all the features that depends on this
> category-b stuff. Otherwise the office is no longer useable
> and we can stop here or can kill the project directly.
>
I am only asking for the technical solution. I think we
have discussed sufficiently that replacing this stuff
is possible but will take time.
I am also not setting any time frame for moving those files.
beyond that we should do it somewhen before release.
>
> The whole discussion is not really motivating for project
> members and of course does not really promote the Apache way
> or the ASF in general.
>
I agree it's not very motivating but in my defense it was
something that had to be discussed sooner better than later.
>
> So we always have to take Windows into account and on
> Windows you don't have system libraries for this stuff.
>
We can do packages of this stuff. It will even save time
from building over and over again the same stuff.
> So please come back to reality.
>
> Juergen
>
> PS who will go demotivated into the weekend
>
OK, this is something I really didn't intend. This was
meant to be discussed on a strictly technical level
without demotivating developers or calling "bloody
murder" on the project.
I hereby drop *any* claim that we may not be complying
with any relevant policy. Also to give full assurance
that I will not be problem to the project I will be
stepping down from the PPMC so my vote will not be
binding: I am really only interested in technical
discussions anyway.
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 1/13/12 3:42 PM, Pedro Giffuni wrote:
>
>
> --- Ven 13/1/12, Andre Fischer<af...@a-w-f.de> ha scritto:
> ...
>>>
>>> I think the issue is very easy to resolve: drop the
>>> tarballs from SVN and provide sufficient instructions
>>> so that the people doing the builds can download the
>>> tarballs themselves: we even have nice "fetch_tarball.sh"
>>> script to do just that.
>>
>> I am not quite sure that I understand the problem here.
>
> Well perhaps I can explain it better as I *am* creating
> source releases for my own personal use.
>
> The normal way to build a source releases is to pull the
> code from SVN (as described in the web page). This will
> download category-A and Category-B software. Category-B
> is not built by default but it is in the same directory
> with Category-A software so I don't find a clear
> separation.
well that is a valid point that comes into my mind as well when I have
read the mails and thought a little bit longer.
If that is the only reason than we can move it besides trunk. But that
is a technical solution only and it doesn't solve the underlying problem.
And what is more important we can't exchange everything now and we can't
remove all the features that depends on this category-b stuff. Otherwise
the office is no longer useable and we can stop here or can kill the
project directly.
Or we take it serious and find compromises and exchange stuff over time
when possible.
Apache got for whatever reason the source grant and the trademarks of
one of the biggest and most successful open source projects. So far so
good. Normally I would expect the organization would be happy and would
do everything that this project can continue in the way as before. Yes
there are changes necessary and again we are working on it but we can't
do everything at once ...
The whole discussion is not really motivating for project members and of
course does not really promote the Apache way or the ASF in general.
>
> Technically, we are indeed forking the mozilla code: we
> carry the source tarballs and patches, so we indeed have
> our own distributions here and that is a legal gray area.
maybe but again we don't have any other chance here right now. We can
only work on it in the future and can try to replace it by newer code.
But we need somebody who can do that, it's far from trivial.
>
> FWIW, I use saxon prepackaged already an I will likely be
> using theprepackaged beanshell so I don't need
> those tarballs. Seamonkey takes too long to build and
> nss involves security risks so this just adds bloat
> to my sources.
it's your personal opinion and many users simply rely on these features
and use it. Your are on FreeBSD a minor platform that has no real
relevance for the user base of OpenOffice.
So we always have to take Windows into account and on Windows you don't
have system libraries for this stuff.
So please come back to reality.
Juergen
PS who will go demotivated into the weekend
>
>
>> Would it be OK to move the category-b tar balls to eg
>> SourceForge or Google and just adapt the URL in the
>> ooo.lst file?
>>
>
> I was thinking we should point users directly to the
> mozilla foundation but I think an external site would
> effectively solve the Category-B issues.
>
> All just IMHO.
>
> Pedro.
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Ven 13/1/12, Andre Fischer <af...@a-w-f.de> ha scritto:
...
> >
> > I think the issue is very easy to resolve: drop the
> > tarballs from SVN and provide sufficient instructions
> > so that the people doing the builds can download the
> > tarballs themselves: we even have nice "fetch_tarball.sh"
> > script to do just that.
>
> I am not quite sure that I understand the problem here.
Well perhaps I can explain it better as I *am* creating
source releases for my own personal use.
The normal way to build a source releases is to pull the
code from SVN (as described in the web page). This will
download category-A and Category-B software. Category-B
is not built by default but it is in the same directory
with Category-A software so I don't find a clear
separation.
Technically, we are indeed forking the mozilla code: we
carry the source tarballs and patches, so we indeed have
our own distributions here and that is a legal gray area.
FWIW, I use saxon prepackaged already an I will likely be
using theprepackaged beanshell so I don't need
those tarballs. Seamonkey takes too long to build and
nss involves security risks so this just adds bloat
to my sources.
> Would it be OK to move the category-b tar balls to eg
> SourceForge or Google and just adapt the URL in the
> ooo.lst file?
>
I was thinking we should point users directly to the
mozilla foundation but I think an external site would
effectively solve the Category-B issues.
All just IMHO.
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Andre Fischer <af...@a-w-f.de>.
On 12.01.2012 20:59, Pedro Giffuni wrote:
>
> --- Gio 12/1/12, Rob Weir<ro...@apache.org> ha scritto:
> ...
>>
>> If you look carefully, you'll see that SVN, via the website
>> stuff that is now there, has tons of content now that is in
>> incompatible licenses, in the form of GPL and other licensed
>> documentation. Ditto for the wiki. Ditto for extensions site.
>> These are all hosted by the Apache, on behalf of the project,
>> but they are not part of our releases. Are you saying SVN
>> must be cleaned of all of that, even if it is not part of our
>> releases?
>>
>
> I certainly had understood the policy for website, Wiki and
> even the extensions site is that we shouldn't be hosting
> copyleft content. There might be a transitory situation during
> incubation and some things are still to be decided but even you
> have clearly stood in the position where any new content in the
> Wiki, etc should be under AL2.
>
>>
>> I'm happy to have someone review the issue, if you can
>> state what the policy issue is. I simply don't see any
>> problem here. We're not including category-b source code
>> in our release, period.
>>
>
> I am really not going into this discussion with you again.
>
> I think the issue is very easy to resolve: drop the
> tarballs from SVN and provide sufficient instructions so
> that the people doing the builds can download the tarballs
> themselves: we even have nice "fetch_tarball.sh" script to
> do just that.
I am not quite sure that I understand the problem here.
Would it be OK to move the category-b tar balls to eg SourceForge or
Google and just adapt the URL in the ooo.lst file?
-Andre
>
> Pedro.
>
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Gio 12/1/12, Rob Weir <ro...@apache.org> ha scritto:
...
>
> If you look carefully, you'll see that SVN, via the website
> stuff that is now there, has tons of content now that is in
> incompatible licenses, in the form of GPL and other licensed
> documentation. Ditto for the wiki. Ditto for extensions site.
> These are all hosted by the Apache, on behalf of the project,
> but they are not part of our releases. Are you saying SVN
> must be cleaned of all of that, even if it is not part of our
> releases?
>
I certainly had understood the policy for website, Wiki and
even the extensions site is that we shouldn't be hosting
copyleft content. There might be a transitory situation during
incubation and some things are still to be decided but even you
have clearly stood in the position where any new content in the
Wiki, etc should be under AL2.
>
> I'm happy to have someone review the issue, if you can
> state what the policy issue is. I simply don't see any
> problem here. We're not including category-b source code
> in our release, period.
>
I am really not going into this discussion with you again.
I think the issue is very easy to resolve: drop the
tarballs from SVN and provide sufficient instructions so
that the people doing the builds can download the tarballs
themselves: we even have nice "fetch_tarball.sh" script to
do just that.
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 12, 2012 at 2:15 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
> --- Gio 12/1/12, Rob Weir <ro...@apache.org> ha scritto:
> ...
>>
>> >> Also, the MPL license requires that we make our
>> modified
>> >> files available electronically for 12 months.
>> >
>> > Thank you for pointing this out.
>> > This sounds pretty much unacceptable for Apache
>> > policies and a good reason to avoid carrying such
>> > code in our
>> > repository.
>> >
>>
>> I don't see the issue here. Can you point me to what
>> Apache policy is violated here? Or argue how downstream
>> consumer of our releases will be harmed or confused by this?
>>
>
> We never impose a condition such of "make your modified
> files available electronically for 12 months". I surely
> don't expect anyone doing a SVN checkout to have to do
> that.
>
Again, where is the policy issue? The category-b code is not in our
released source packages. We're not imposing any extra conditions on
downstream consumers. We're ensuring that the product can build and
run without any category-b modules. So show me where the problem is.
Remember, the category-b prohibition is for source packages. SVN is
not our source package. A subset of files in SVN will comprise our
source release.
If you look carefully, you'll see that SVN, via the website stuff that
is now there, has tons of content now that is in incompatible
licenses, in the form of GPL and other licensed documentation. Ditto
for the wiki. Ditto for extensions site. These are all hosted by the
Apache, on behalf of the project, but they are not part of our
releases. Are you saying SVN must be cleaned of all of that, even if
it is not part of our releases?
>
>> >>
>> >> So I don't see a problem here, so long as we:
>> >>
>> >
>> > I do see a problem and unless some higher power from
>> > legal@ OKs it, my vote for a release or project
>> > graduation will be -1 (binding), on the basis that
>> > if we do this once we will likely be perpetuating
>> > such practice in all releases.
>> >
>>
>> We already had this discussion before. My impression
>> was it was resolved.
>> See: http://markmail.org/message/2o42tzsw24z5znst
>>
> In that same thread the situation is left mostly
> unresolved. Ross in particular said:
>
You were looking for an opinion for Apache Legal. Robert is a member
of Apache Legal Affairs, not Ross.
> "That is not my understanding. As far as I am aware
> automated downloading of incompatible licensed coffee
> is not acceptable."
>
> Furthermore there is a specidif statement that we do
> have to get the SVN tree clean of incompatible
> licenses (I never manage to find that link when I
> need it).
>
>> In any case, there are no vetos on release votes.
>>
>
> It does mean legal or someone else will have to look
> at it and solve it, which is what I am asking for.
> Just thought I should save you from surprises later
> on and avoid delays.
>
I'm happy to have someone review the issue, if you can state what the
policy issue is. I simply don't see any problem here. We're not
including category-b source code in our release, period.
-Rob
> cheers,
>
> Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Pedro Giffuni <pf...@apache.org>.
--- Gio 12/1/12, Rob Weir <ro...@apache.org> ha scritto:
...
>
> >> Also, the MPL license requires that we make our
> modified
> >> files available electronically for 12 months.
> >
> > Thank you for pointing this out.
> > This sounds pretty much unacceptable for Apache
> > policies and a good reason to avoid carrying such
> > code in our
> > repository.
> >
>
> I don't see the issue here. Can you point me to what
> Apache policy is violated here? Or argue how downstream
> consumer of our releases will be harmed or confused by this?
>
We never impose a condition such of "make your modified
files available electronically for 12 months". I surely
don't expect anyone doing a SVN checkout to have to do
that.
> >>
> >> So I don't see a problem here, so long as we:
> >>
> >
> > I do see a problem and unless some higher power from
> > legal@ OKs it, my vote for a release or project
> > graduation will be -1 (binding), on the basis that
> > if we do this once we will likely be perpetuating
> > such practice in all releases.
> >
>
> We already had this discussion before. My impression
> was it was resolved.
> See: http://markmail.org/message/2o42tzsw24z5znst
>
In that same thread the situation is left mostly
unresolved. Ross in particular said:
"That is not my understanding. As far as I am aware
automated downloading of incompatible licensed coffee
is not acceptable."
Furthermore there is a specidif statement that we do
have to get the SVN tree clean of incompatible
licenses (I never manage to find that link when I
need it).
> In any case, there are no vetos on release votes.
>
It does mean legal or someone else will have to look
at it and solve it, which is what I am asking for.
Just thought I should save you from surprises later
on and avoid delays.
cheers,
Pedro.
Re: Category-B tarballs in SVN (was Re: External libraries)
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jan 12, 2012 at 1:12 PM, Pedro Giffuni <pf...@apache.org> wrote:
>
> --- Gio 12/1/12, Rob Weir <ro...@apache.org> ha scritto:
> ...
>> >
>> > I hate to make developer's life difficult but, from
>> > what is known, no Apache Project seems to be carrying
>> > Category B software in their repositories (feel free
>> > to prove me wrong). Not that it's a new problem, just
>> > something we will have to think about.
>> >
>>
>> It is a service to downstream consumers. Just as we
>> aggregate licenses and notices to make it easier for
>> them, we also aggregate the optional category-b code
>> tarballs.
>>
>
> It is actually a disservice. Some of those tarballs are
> obsolete and carry known security risks.
>
Whether we have such tarballs in SVN or whether we have our build
scripts point to an externally hosted tarball of the same version, the
security issue is the same, and orthogonal. However we access the
files we are responsible for ensuring the end product is secure.
>> Also, the MPL license requires that we make our modified
>> files available electronically for 12 months.
>
> Thank you for pointing this out.
> This sounds pretty much unacceptable for Apache policies
> and a good reason to avoid carrying such code in our
> repository.
>
I don't see the issue here. Can you point me to what Apache policy is
violated here? Or argue how downstream consumer of our releases will
be harmed or confused by this?
>>
>> So I don't see a problem here, so long as we:
>>
>
> I do see a problem and unless some higher power from
> legal@ OKs it, my vote for a release or project
> graduation will be -1 (binding), on the basis that
> if we do this once we will likely be perpetuating
> such practice in all releases.
>
We already had this discussion before. My impression was it was
resolved. See: http://markmail.org/message/2o42tzsw24z5znst
In any case, there are no vetos on release votes.
> Pedro.
>