Thank you for your comment, Jerith.
You are right that business model which works for other FOSS products does not work for WURFL. Been there. Done that.
As far as third-parties API go, there was a subtly crucial technical problem: third-parties API tend to be simpler than the standard API, hence people ended up adding unnecessary/bogus data in WURFL (think 7 identical Android devices where only the locale substring changes).
Anyway, we are not really blocking third party WURFL APIs. People with a non-standard WURFL API can bundle it with their own product, add an older version of WURFL (the April 2011 version, for example) and advise users that they can get an updated file from the WURFL site. At that point, how their users will cope with WURFL licensing is not their problem.
For example, commercial licensees of WURFL will also get a customer vault with weekly snapshots all licensed more liberally for the use by that customer.
Of course, I am not saying that this situation is ideal for other FOSS projects, but it it is certainly not a showstopper for those who still want to use WURFL as a DDR module in a larger open-source artifact.
Did I mention that we handled out discounted and free-of-charge commercial licenses to non-profit, non-commercial and governmental entities?
Anyway, point taken about the need to enlarge the number of supported languages.