Google’s open source guru Chris DiBona, however, told us that Google will just make its own code when needed to get around clauses similar to these. “We have enough engineer resources that, if the license has obligations we are not interested in, we can just not use it,” he said.

I think this clearly highlights one of the compromises that “badgeware” forces us to make. Companies are defensive of their brand (or they should be). They will not do anything that dilutes that brand, like having a.n.other logo on every page. This is what Chris appears to be saying in the above quote.

However, in the case of Google, they are one of the most active supporters of major open source software projects I know of. They invest masses of resources into projects that their company depends upon, thus they help to ensure that those projects remain sustainable. In the above statement Chris is clearly stating that Google will not be able to assist in the sustainability of “badgeware”.

Some open source projects simply don’t care about attracting the support of large organisations like Google. They may have their own internal resources to sustain the software, or they may be targeting a large number of smaller contributors. Where the owning company has a strong brand it can actually be a benefit to the smaller companies to show that badge as a mark of quality. But what happens when that small companies brand becomes more valuable? Will they want to develop their own code in order to avoid the badgeware issue? Will they purchase a licence from the copyright holder so that they do not need to display their logo (this may not be possible if there is no single copyright holder)?

The introduction of this new OSI approved licence simply adds another set of variables to the mix when selecting the right licence for your project. Selecting a licence is not an easy process, but if you clearly identify your objectives it makes licence selection much simpler (especially if you ask OSS Watch to help).