www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <bay...@apache.org>
Subject Re: fair use (was Re: What licenses in category X satisfy criterion #2?)
Date Thu, 13 Mar 2008 17:07:57 GMT
On Thu, Mar 13, 2008 at 7:41 AM, Matthieu Riou <matthieu@offthelip.org> wrote:
> On Wed, Mar 12, 2008 at 8:13 PM, Joe Schaefer <joe_schaefer@yahoo.com>
> wrote:
> >
> >
> > --- Joe Schaefer <joe_schaefer@yahoo.com> wrote:
> >
> >
> > > Because I'm trying to give you folks the perspective
> > > of a perl hacker on licensing.  We don't ever have
> > > these lofty debates on module licensing, because we
> > > let perl do all the actual binding for us.
> >
> > Let me say some more words about the situation for
> > perl, because I think it will reinforce Sam's point
> > that no algorithic approach will work out fairly
> > for everyone at the ASF.
> >
> > Spamassassin is an ASF project that some closed source
> >
> > providers base their work on.  Spamassassin also
> > depends on lots of 3rd party perl modules.  Were one
> > of those modules ever to be relicensed under the GPL,
> > it is my opinion that no material impact would happen
> > to the spamassassin community if they kept right on
> > using it.  The reason I say that is that in perl,
> > module boundaries are generally license boundaries,
> > because the modules themselves are independent works.
> > Use of such modules, in the sense of writing
> > compatibility code, does not constitute producing
> > derivative works of them.  All a closed source
> > provider
> > would have to do is honor the terms on the GPL module,
> > and they could continue producing closed source
> > solutions based on spamassassin.
> >
> > Were the policy to forbid spamassassin from using
> > 3rd party GPL'd modules, it would only be for the
> > reason that we trying to protect the brand, IMO.
> > It would not serve the actual spamassassin
> > community in the least if they had to reimplement
> > the module themselves.
> FWIW this observation also applies to most dynamic languages. I can write
> Ruby code using a given library just by looking at the documentation and
> never even touch the library code until runtime. Because of duck typing the
> used library can be switched at anytime (even runtime). So I'd be interested
> in knowing what the FSF would call "linking" in that case.

Somewhat agreed.

You could improve the algorithm approach to cover these; talk about
compiling vs not compiling, but I'm in agreement that the algorithm
should not be policy - personally I think it should be legal-pmc
guideline and built up by a case history.

More important right now would be the issues of what the FSF's
non-compiled/dynamic-linked stance is, and what our policy is with
regards to what you call the Apache brand. Should people downloading
an Apache project expect it to be largely permissive, by that
finger-in-the-air determination of whether a product is/contains GPL,
or just works on top of GPL.

There are GPL modules in Perl and Ruby land, so I'm sure the subject
will come up on here at some point with an actual use case.


DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message