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
signature.asc
Description: Digital signature
/* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
