According to a talk by Benchmark Capital's Rob Bearden at this week's Open Source Business Conference (OSBC), the nature of open source business models are changing. He says open source companies should strive to become the "enterprise standard" in their market space in order to effectively monetize their commodities.

When is an open source license not an open source license? The recent rush to "Open Core Licensing" as defined by Andrew Lampitt, the business development director of JasperSoft, raises many questions as to the meaning and purpose of free and open source software.

News flash to old-school software vendors: an "API" doesn't make your product "open" and it certainly doesn't make it "open source." For the second time in two days, I've seen product marketing claiming a product was open because the vendor supplies an application program interface. Phooey.

In my role as pseudo general counsel at Alfresco, I wade through a lot of contracts. As part of this, I'm constantly trying to find the right balance between the needs of our customers and partners in different geographies. Interestingly, our European and North American customers view licensing very, very differently. Generally speaking, our European customers want our software under an open-source license (GPLv2). North Americans? They want the benefits of open source without the obligations and perceived risk (meaning, they prefer a dual-license approach that allows them to contribute back modifications if they wish, but not out of duty).

There are many ways to license open source software. Given the attention paid recently to the General Public License (GPL) and its latest version (GPLv3), you may be interested to know that there are other licenses that satisfy the principles of free and open source software without the confusion and polemics that surround the GPL.

If you ever plan on writing an open source program, then you must make an important decision, selecting a program license. Generally for open source programs, there are two main licenses that most developers take into consideration. These licenses are the Gnu General Public License, and the BSD license.

I’ve talked in the past about a number of “open source” business models. There’s the MySQL “dual license” model, where all the software is available under an open license but a proprietary license can be purchased.

While "open source" refers to software's underlying license and its adherence to the Open Source Definition, there are numerous examples of open-source projects that offer an open license but a relatively closed development process. But is it open enough? It's been called "fauxpen source" and worse, but we may have to get used to it.

Setting the legal nuances of the chosen open source license aside, wouldn't two products under any open source license have the same claim to the open source moniker?