Friday, May 27, 2011

Open Source Licensing

I can't resist the opportunity to comment on the FSF's guidelines - apparently just published - for how to choose a license for your work.  A story on this was posted on Slashdot this morning.  The FSF's guidelines are a little more nuanced than they could be; for example, they recommend contributing code to existing projects under the licenses used by those projects, rather than starting a giant war with the maintainers of those projects.  And if you're including trivial test programs in your work, or your work is shorter than the text of the GPL itself, you might just want to put the work in the public domain.  Very sensible!

But that's about as far as they're willing to go.  For example, the section on contributing to existing projects suggests that, if you're making major enhancements to a non-GPL program, you might want to fork it and release your changes under the GPL.  In other words, in the FSF's opinion, sometimes you should start a giant war with the maintainers.  In the open source world, forks are a part of life, and people are free to choose the licenses they want, but this seems awfully cavalier to me.  Forks are really damaging.  Maintaining a large and unified developer community has value; having those people spend their time developing, rather than arguing about licensing, is a good thing.

This is just my opinion, but I think there can also be situations where using a license like the GPL inhibits contributions rather than encouraging them.   For example, a good portion of the motivation for the LLVM project was to create an open-source compiler project to which companies which also wanted to sell products based on the code to contribute.  So far, that project looks very promising, and the developer hours that are being spent on that project are not being spent on gcc.  It is even possible that clang will eventually displace gcc as the compiler of choice.  The PostgreSQL License allows similar freedom.  Not all the companies that have forked PostgreSQL have made contributions of code back to the community, but some have.  (My employer, EnterpriseDB, is one.)   Even cases where no code whatsoever has been contributed back to the community have led to increased mind-share for PostgreSQL, and jobs for PostgreSQL DBAs, and work for PostgreSQL support companies.  That's not a bad thing.


  1. Well, a good part of the motivation for the GCC project is that a company can contribute without fear that other companies will sell proprietary extensions. There are different licenses for different business models.