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 Sat, 15 Mar 2008 04:21:32 GMT
On Fri, Mar 14, 2008 at 7:52 PM, Joe Schaefer <joe_schaefer@yahoo.com> wrote:
> --- Joe Schaefer <joe_schaefer@yahoo.com> wrote:
>  >
>  > --- Robert Burrell Donkin <rdonkin@apache.org>
>  > wrote:
>  >
>  > > On Thu, 2008-03-13 at 10:07 -0700, Henri Yandell
>  > > wrote:
>  > >
>  > > <snip>
>  > >
>  > > > More important right now would be the issues of
>  > > > what the FSF's
>  > > > non-compiled/dynamic-linked stance is,
>  > >
>  > > +1
>  > >
>  > > even when we've disagreed with the FSF's
>  > > interpretation we've respect
>  > > the spirit and intention of their licenses (as
>  > > expressed by the FSF).
>  > > IMO this approach should be continued.
>  >
>  > I just dug this up:
>  >
>  >
>  http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL
>  >
>  > It directly conflicts with what I said about
>  > the situation for spamassassin.  According
>  > to that url, if spamassassin acquired a GPL
>  > dependency, it would have to license everything
>  > under the GPL.  (The FSF apparently believes
>  > copyright extends to actual processes, not
>  > just files on the filesystem).
>  FWIW, here's what the US Copyright Act says about
>  computer programs:
>   § 117. Limitations on exclusive rights: Computer
>  programs
>   (a) Making of Additional Copy or Adaptation by Owner
>   of Copy. — Notwithstanding the provisions of section
>   106, it is not an infringement for the owner of a
>   copy of a computer program to make or authorize the
>   making of another copy or adaptation of that
>  computer
>   program provided:
>   (1) that such a new copy or adaptation is created as
>   an essential step in the utilization of the computer
>   program in conjunction with a machine and that it is
>   used in no other manner, or
>  [...]
>  To me, that seems to say that copying the bits of a
>  file from the filesystem to into main memory isn't
>  infringing copyright, so I don't understand the FSF's
>  position here.  Can anyone here enlighten me about it?

I suspect they're grappling with the same kind of grey area that we are.

They want to allow environmental type applications - that way GPL on
Win32 is good, a GPL Rebol script is good etc. At the same time, they
want the use of code libraries to be considered linking. In this case,
dynamic linking.

This definitely fits how we should look at it - judge the intent
rather than trying to pick holes in the license. So bash scripts would
be fine as it's an interpreter and they want people to use it, a GPL
Perl module would not be fine as it's a library. Same for the standard
JDK modules that come with the Java interpreter. If you used Perl
under the GPL rahter than Artistic license, all your code would need
to be GPL. Ditto if you run code on top of OpenJDK with a pure GPL
license, your code would be GPL.


As I'm not immune - here's another hole to pick:

There seems to be a bit of a big contradiction in the FAQ item after
the one you link to.

Things distributed with the compiler are considered System Libraries
under GPL and LGPL. I don't know about you, but the standard Java
classes fit that description very well to me. I get the Java compiler,
and a bunch of libraries. That would imply that OpenJDK-SE does not
need the Classpath exception. Which also means that not having the
classpath exception for OpenJDK-ME isn't protecting anyone.

The "Interpreter's modules pass GPL", and the "System Libraries do not
pass GPL" entries seem to contradict each other when the interpreted
language uses a separate compiler to create its variant of object


We could spend ages digging into such things. End of the day:  Bash
scripts => clean. Use of a perl module or Java library => messy.


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