LGPL for Interpreted Languages?

Hans Fugal hans at fugal.net
Sun Jan 28 14:58:28 MST 2007


On Sat, 27 Jan 2007 at 19:58 -0700, Michael Torrie wrote:
> On Sat, 2007-01-27 at 19:29 -0700, Hans Fugal wrote:
> ><snip>
> > What I'd like is to release it under something conceptually equivalent
> > to the LGPL. That is, you should be able to use the library for any
> > purpose you like including proprietary software. IOW it isn't viral. But
> > I do want any changes to the library (which are distributed) to be
> > opened up. The problem is that the language in the LGPL doesn't really
> > make much sense for interpreted languages.
> 
> I don't know why you say this.  The LGPL is a pretty good choice for a
> library written in any language, so long as you want to allow unfettered
> use of the library while preserving access to the source of the library
> itself.  Why should a library be any different just because it is
> interpreted rather than compiled?

It's not clear to me that the word "link" has the same meaning in
interpreted languages. Apart from that, though, is an issue that is more
peculiar to ruby (though not unique), which comes from open classes.

In Ruby I can take the built-in Array class and add a method foo to call
my grandma with VOIP and wish her happy birthday. In my program, Array
has been extended, but it has not been subclassed. Has the "library"
been modified and a derivative work created? Or has the library remained
unmodified and is ok in light of the LGPL? I don't say the LGPL isn't
applicable, I just say that I don't yet know for sure if it is. I'd love
to entertain arguments as to why the LGPL, which was very obviously
designed with C in mind, still applies to more interesting languages.

I have found this statement since I wrote the original email which
satisfies many of those questions. He asserts that the LGPL is ok for
subclassing, which afaict would be essentially the same for open classes
too (and why not - you can always do the same thing by subclassing -
it's just a little more hassle).
http://www.gnu.org/licenses/lgpl-java.html


> On a related note, I've noticed potential legal minefields when using
> python for major projects because of the various licenses that units
> use.  Of course no matter what language one uses, you have to be careful
> when linking to libraries so as not to violate their license by making
> your own code legally incompatible.  Do people worry about this in perl
> and python?  

They should.

-- 
Hans Fugal ; http://hans.fugal.net
 
There's nothing remarkable about it. All one has to do is hit the 
right keys at the right time and the instrument plays itself.
    -- Johann Sebastian Bach
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20070128/9d3521cf/attachment.bin 


More information about the PLUG mailing list