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).

Firstly, this is a data management problem rather than an API problem. As the gatekeepers of the data, you're well placed to handle it. If a particular API that is causing problems, you can take it up with the maintainers or something. A blanket ban on any APIs not provided by ScientiaMobile is overkill.

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.

This adds barriers to using WURFL in an application, and it isn't obvious what the options are. I'd be hesitant to build and maintain (for example) a Django module that required users to choose between a very old version of the data or a commercial license. Besides, the licensing options specifically state that they are "per platform", and there's no option for "using my own API".

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.

It's a showstopper if the project in question doesn't use any of the supported languages and wants to provide access to data newer than April 2011.

Did I mention that we handled out discounted and free-of-charge commercial licenses to non-profit, non-commercial and governmental entities?

It might be worth mentioning that on your product page. The only options there are "open source" and "commercial".