On Nov 19, 8:36 pm, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > Carl Banks <pavlovevide...@gmail.com> writes: > > On Nov 19, 3:24 pm, Joshua Bronson <jabron...@gmail.com> wrote: > > Apart from the GPL, it seems perfectly fine to release, and looks like > > an interesting strategy. I've wanted one of those once in a while, > > never enough to bother looking for one or writing one myself. > > I would think GPL is an excellent choice for such a library then, if the > author's intention is to encourage more software to be free software so > that it can incorporate a unique library like this.
Well, yes and no. This bidict class sounds nice and full-featured, especially after the changes prompted by the fruitful discussion. I personally use inverse mappings on a regular basis, but for the most part, my data doesn't change all that dynamically (or performance doesn't really matter), so when I need to go backwards I often do something like: inverse_mapping = dict((y, x) for (x, y) in forward_mapping.iteritems ()) Having said that, if I ever actually *need* something more full- featured to add to non-GPLed software, I'd just write it (and release it under a permissive license). IMHO, GPLing something this simple is really the tail trying to wag the dog. Case in point: I was just using rst2pdf to combine some restructured text and SVG images, using svglib. svglib had some bugs and didn't work right on my PDFs. svglib is not developed publicly, and the author is somewhat slow to accept patches. Since svglib is reasonably small, if it had been released under a permissive license, or even the LGPL, I probably would have just copied it into the rst2pdf repository and fixed it. If it were any smaller, I would have rewritten it. I don't own the rst2pdf package, and didn't really want a license discussion about 1K of source lines dictating a license change on 15K lines. As it is, I figure the svglib author will probably get around to fixing the bug at some point anyway, and for now I can easily use PDFs for my graphics input format, so I cleaned up and added to some old PDF code I had lying around, and released it as the open source pdfrw package, and now rst2pdf can use that to import PDFs as vector images without rasterizing them -- a new capability. So in this case, the GPL spurred open-source development, in exactly the same way that proprietary licenses do... I'm quite happy to *use* GPLed software (and greatly appreciate the authors' efforts), and I'm even sometimes willing to debug or add features and submit patches to GPLed software, and I might even have a (business, not political) reason to release some software under the GPL myself someday. But if I ever did release something under the GPL for business reasons, it would be because I also had the right to also offer a proprietary version. This would require that I owned _all_ the code in the package, so the implication is: I'm not going to use your tiny little GPLed code in any major software I write for release, whether my software is GPLed or not. The LGPL is different. I view the LGPL as a statement of "if you ever add related functionality to this or fix a bug in this in a shipping product, I'd like to see the fix, please" and I could even see myself releasing something with this license under the right circumstances. Now if I were doing a web service, it would be a different story. I would be quite happy to add your GPLed software into the mix, so if that's a terrible thing, perhaps you should consider affero for your future offerings :-) Best regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
