IANAL. As you are all are hopefully aware there are huge differences the exact "freedoms" allowed by the various open source licenses. I find that many younger developers have a natural affinity to the GPL, because they seem to feel its important to prevent someone from just taking their code, building upon it and not releasing their changes under an open source license when they distribute. Maybe with enough experience you start to realize that it happens close to never that a proprietary fork of an open source project ends up outpacing the original project. So why bother regulating this? It just makes legitimate business uses harder and in the grand scheme of things, I don't worry about this. People who prefer to go proprietary are likely not in the state of mind yet where I would want to work with them anyway.
So these days I prefer BSD, Apache and MIT licenses. My first open source project PEAR MDB was licensed as BSD. The Symfony2 eco-system is mostly licensed under the MIT. With basically Johannes Schmitt being the odd one out using the Apache license. We moved PHPCR to the Apache license in the early stages of the development push thinking this makes sense given that JCR is also licensed under the Apache license. We also moved Jackalope to Aapche thinking we might one day contribute it to the Apache foundation. There is one trouble here in that I recently learned with Apache 2.0, the FSF considers it incompatible with (L)GPLv2. Note that (L)GPLv3 is considered compatible.
Popular projects like Drupal being GPLv2+ and Doctrine LGPLv2 there is a problem. As Drupal is considering adopting PHPCR/Jackalope they would have to move to GPLv3+, which is easy for them to do since they made sure to include the "or later" when they went with GPLv2. Now for Doctrine the situation isn't so easy since its LGPLv2 without the "or later" option. Meaning we couldn't just drop the LGPLv2. That being said to me the LGPL is very fuzzy in combination with an interpreted language like PHP, but it would be good to avoid such a grey area. As a result all the current core developers have agreed to try and switch Doctrine to the MIT license. Due to its longer history moving the Doctrine ORM and more importantly the DBAL over is going to be quite hard, however the rest of the project is sufficiently young that its feasible to attempt this. Note that the DBAL actually started its life in Doctrine as part of the 1.x branch which in turn was a fork of my MDB project which was BSD licensed. Still since then a lot of code went in and out.
Now the big question is how on earth can we work through such a license change? In short its going to be really really hard. At least in the days of git and github we will not be faced with quite as many patches that were committed by someone else than the creator as back in the day many changes came in via patch files submitted to issue tickets or mailing lists. But there is still the risk of code lifts from other projects that might also be using a non MIT compatible license. So it seems like we really need a tool to help manage determining all the contributors and if they have approved the license change. Then also helping in reviewing individual commits if they are worthy of a copyright (typo fixes and obvious bug fixes do not). Maybe even do some analysis to show is which code portions remain without consent for the license change so that we can choose to rewrite them. Unfortunately I am not aware of any such tool. The only high profile project I remember having done such a change is VideoLan, but at least in their blog posts it seemed like they simply got the permission of their few dozen core developers. Anyway I will follow up this blog post with another one outlining some ideas I have for how such a tool could work.
Now to finish up this blog post I want to touch upon the topic of a CLA. When I first mentioned this issue on twitter, people were quick to point out that a CLA would make such a license change easier. Avid readers of my blog should know that I have spoken out against CLAs quite a lot in the past. The two main reasons is that it adds an annoying legal hurdle for contributors and that all CLAs I have seen include patent clauses which I reject. But it is true that a CLA would enable the entity to which the CLA would be signed to could easily do a license change (which could also be an irritating fact for some). Now there is a different kind of agreement called a Fiduciary Licensing Agreement which is used by the KDE. Essentially it gives the KDE guys the right to change the license, but also to defend the rights of the original creators in court. The difference to the CLA is that a FLA is also useful even if you do not force everyone to sign it. As a result the practice is to simply get people to sign it eventually after several contributions and not like a CLA before even the first patch can be accepted. As such an FLA does not suffer from the above mentioned legal hurdle and there is also no patent clause. Now with an FLA there can still be a number of patches from people that have not signed the FLA and before any license change these will need to be addressed by either: getting the contributor to sign the FLA, getting the contributor to at least allow the license change, determining that the patch was not copyright worthy or by throwing out or rewriting the given code. The benefit is that the work as to be done for much less code. So maybe step one before bothering with the license change is establishing an FLA.
Update: Instead of writing a blog post on a concept for a license change tool, Benjamin just wrote one with some feedback from me.
The position of the Software Freedom Law Center is that GPLv2 (and therefore I presume LGPLv2) is implicitly "or later" unless you explicitly say otherwise. When Drupal sorted out its licensing from "uh, GPL, right?", I made very careful to explicitly add the "or later" all over the place to make it very clear that moving to GPLv3 would be easy should we decide to do so.
Just because the copy of the LGPL that you have in the repo for Doctrine is the v2 copy doesn't mean that it must be v2-only. You should check with someone at SFLC (I have an old contact I can try referring you to if you'd like) to see if arguing that it's already "or later" would be defensible, and therefore mean that the project leadership could move to v3+ with a consensus of the current contributors rather than a signature of all contributors ever.
Where has been written that the Apache 2.0 license is incompatible with the LGPL v2? I only now about the GPL v2, but the LGPL is a compromise license that must not stretch over the whole package, so I can imagine that it can be compatible.
And the Doctrine2 code does not specify the version of the LGPL:
This software consists of voluntary contributions made by many individuals and is licensed under the LGPL.
Not specifying the version of the license allows tjhe licensee to choose the version:
Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. [Emphasis added]
There is no problem to use Doctrine2 under the LGPLv3+ license. So even in case LGPLv2 could not be used in a compatible way with Apache 2.0 licensed code (for distribution), there would be no problem.
But I'm with you, that the LGPL is a grey choice for PHP libraries because for these works it's not really clear where they start and end. In my eyes the chance to clarify this for the community has been passed when the PEAR group did the license changes back in 2004. LGPL was promoted without clarifying the questions that were raised that time, so time to do better education now.
For the Fiduciary License Agreement (FLA), please see as well the page on the FSFE website, the FSFE supports projects here when they are interested. More developers should know about it in my eyes.
And btw, the GPL is useful and it does offer the protection you write it is not necessary. I've personally seen it necessary more than one time. And there is not much else with working copyleft in OSS than GPL.