On 6 Mai, 19:22, [EMAIL PROTECTED] (Ville M. Vainio) wrote: > Excuse the long post.
Excuse the cherry-picking from your long post. ;-) [...] > Also, you can do what Paul Boddie did - fork the project, or maintain > patches that are under LGPL. With a liberal license, you have that > privilege. Sure, my patches were LGPL, if you'd like to consider it that way, but I have to point out that the derived work maintained by me became LGPL as a result - I wasn't offering the non-Paul Boddie version under the original licence as well. Now, I did leave a fair amount of information about the heritage of the code, so that anyone who is scared of the LGPL could just go and get the original work, but that is probably your only viable option if you want to revert to the old licensing. [...] > I don't think BSD/MIT like license really annoys anyone. Think python > here ;-) As some have pointed out, it can discourage people from contributing. I've said many times before that some companies might not contribute to a permissively licensed project because their competitors could leverage the benefit in proprietary software, and I consider Linux and the involvement of companies like IBM to be a reasonable example of this. [...] > Not at all, it's a very practical thing related to all the > intellectual property lawyerage in corporate setting. With Vellum, it > doesn't matter a lot because most of the tools are only used in-house, > but it would still be nice if you could just grab the code from > somewhere without having to think about license at all, or considering > whether any of this would ever be needed for something that involves > selling stuff under proprietary license. You can almost never just "grab the code from somewhere without having to think about [the] license" since even permissive licences typically have a list of conditions that must be observed. Certainly, they aren't as demanding as those in copyleft licences, but by not observing them you are infringing someone's copyright. [...] > Also, for some reason, GPL is used for evil (dual-licensing schemes - > make money but still gain the open source mindshare, and possibly rack > up free contributions to something that is your *commercial product*) > more often than it's used for good (gcc, Linux kernel - prevent IP > exploitation and ensure that all improvements are freely accessible). The whole "evil" aspect of dual-licensing schemes is mostly to do with copyright assignment (or the contribution agreement), not licensing, although the licences typically employed obviously prevent the wider community from making proprietary versions of the software, thus creating the conditions for a dual-licensing business. That said, it's easy to refuse to play along with such schemes if you're motivated: just don't agree to assign your copyright to someone else, or don't license your contributions under permissive licences (which interestingly takes us back to the issue of Python contributions and the associated list of acceptable licences). These days, some companies are getting a lot of bad publicity about their project governance: Sun seem to be getting continuous criticism about the management of OpenOffice.org, and now that they've picked up MySQL, they'll presumably be the target of criticism by people who had to sign over their ownership of patches in order to feed the MySQL corporate machine. But again, this isn't a sign that the licence was the problem: it's what people were asked to do with the copyright which effectively negated the benefits of the licence for those wanting to keep the software free and open. Paul -- http://mail.python.org/mailman/listinfo/python-list
