On Thu, Sep 27, 2012 at 7:26 AM, Benson Margulies <bimargul...@gmail.com> wrote:
> Perhaps I can help here.
>
> The root of all this, as I understand it, is an optional dependency.
> There is, of course, code that depends on the optional dependency.
> However, no one has mentioned any *source* code that is under an
> incompatible license, such as modified sources of an LGPL component.
>
> This is the critical question. If this is AL source code that makes
> calls to an LGPL component, then it can live in an ordinary AL source
> repository and be distributed in an ordinary AL release. However, a
> user must be able to build the release, by default, without the LGPL
> binary dependency.Thus, 'optional'.
>
> If, on the other hand, some members of a PMC wish to build source code
> that is not under the AL, it cannot be at Apache and there must be a
> bright line that avoids any confusion. Such a project could be at
> Extras, but then the question arises about whether mailing list
> connections and other conveniences would create unacceptable confusion
> about the distinction between 'things the PMC does' and 'things some
> PMC members happen to do elsewhere.'

I think that is just engineering prudence.  Take the example of a
component that you might have a  dependency.  I see no problem with a
PMC wanting to be informed about all changes to that component as well
as all bugs found in that component.  That information is entirely
relevant to the Apache project.  At the very least a PMC should be
aware of security flaws identified in any dependencies, optional or
otherwise, since this may require steps such as a patch to interface
code.

I understand the concern about avoiding the appearance that the PMC is
"building source code that is not under the AL", but surely that
depends on what the PMC *pushes or writes* to the Apache Extras, not
on what they *read*.  Being informed is never a crime.

Specific example.  OpenOffice podling has signed up for a security
mailing list where we receive security-related bug reports from
LibreOffice, an open source project that is LGPL/MPL, not ALv2.  We do
this by subscribing our security list directly to theirs.  Is this
against policy?   This seems directly analogous to a project receiving
bug reports from a non ALv2 Apache Extras project.

Regards,

-Rob

Reply via email to