LGPL (lesser copyleft) is still a copyleft and this license prevents forms of commercial adoption by requiring that changes to the library be released under the

LGPL (lesser copyleft) is still a copyleft and this license prevents forms of commercial adoption by requiring that changes to the library be released under the LGPL. While LGPL isn't particularly horrible, it still has restrictions that BSD license doesn't have. Hence, there possible uses (where contributing code back) isn't an option due to business goals of an organization. Even if you have some ability to contribute back, LGPL requires due-diligence that can amount to a substantial amount of time: including involving IP attorneys to render a professional opinion. I think GPL (and LGPL in some cases) makes sense for dual-licensing situations, where your company turns down contributors who don't assign copyright. This only works if the money invested keeps enough velocity that GPL-forks (ala Drizzle fork of MySQL) don't get traction. Without the dual-licensing approach, I think it then comes down to values. Do you want more commercial adoption, even if someone makes additional improvements and sells them as proprietary software (BSD/MIT)? Or, do you want to force commercial adopters to contribute back (GPL/LGPL). I use PostgreSQL has a solid example of how BSD/MIT works, including commercial forks -- some of which is contributed back. It turns out that maintaining your own fork is quite expensive and most companies typically contribute back without being compelled since it's cheaper & provides kudos. Even for companies that keep a proprietary fork (ala GreenPlum), they still contribute indirectly by funding engineers that know the code base and providing commercial options for users of the software. So, I think that if this is the leach model, it's not so bad.