.
Leaving the GPL - the gloss over:
Puppet has provided an example of a change in licensing, which I will refer to in this article.
"I know this argument doesn’t persuade all of you"
...Somebody forgot to mention dual licensing perhaps.
Fact is if you want to go Apache, then go Apache, no need to gloss over dual licensing option, and suggest that your hand was somehow forced.
GPL versus BSD / MIT / Apache style Licensing:
For a useful Comparison MySQL is GPL, but Postgres is under more of an Apache style license.
Personally I really like Postgresql, however there is no denying that MySQL does seem to be the bigger of the two in terms of counting installations.
The GPL allows you to charge for your software, and companies do just that (MySQL enterprise), aswell as selling support.
Both of these things are no easier for Puppet now that it is under an Apache license.
"Apache enables far more partnerships", well now Infobright and Calpont seem to be getting along pretty well with MySQL and no hinderance from the GPL there.
There has yet to appear a column oriented database partner for Postgresql, and Postgresql is under the sort of license which Puppet has just switched to in order to "enables far more partnerships"
If somebody does a fork of Puppet from the last GPL point, then I'm sure there will be howls of protest.
Big question for puppet is whether a well funded commercial rival might enter the market, if it did happen would they take the GPL codebase, and try and take out puppet, whilst sharing changes, or would they take the Apache codebase, and start looking at what value added features they might add, that could be patented in an exclusive way?
How do I sell my GPL software, surely my competitors can just copy it?
If what you are working on is a simple shopping cart with a few thousand lines of code, then yes your competitors will easily copy what you have, and produce an equally saleable variant.
If you answered yes above, then you might want to ask yourself is a couple of thousand lines of code really a saleable and 'protectable' innovation. Might be that neither you or anyone else out there could actually sell the thing, in sufficient numbers for it to be viable?
Be honest. It might be a great little project, however few of those little projects could actually persuade thousands of folks to part with money willingly.
( On Windows and Mac desktop systems, there has been a history of freeware. Not free to distribute or contribute to, but free as in zero cost. Those freeware cds were mostly programs that were great little ideas, but not a saleable proposition. )
If you are unsure then set aside £1000 and pay for two things:
- Small market research exercise via social media
- Group of physically present test subjects, who are willing to install the thing and give honest feedback.
Even without access to the code, the functionality is likely to be reproducible by an independent developer with a couple of weeks tops.
If you are talking about Red Hat Linux, which has a codebase of which a significant part is GPL licensed, then that is different. Because of the sheer scale of the product (lines of code), you have something that really is saleable and protectable, and that is your experience, your brand, your support, and rolling them all together, the recognisable product known as 'Red Hat Linux'
But CentOS just copied Red Hat?
Yes and No. The saleable brand of Red Hat includes all those things I just mentioned, and is not simply the bare code on a cd.
But Oracle just copied Red Hat with Unbreakable Linux?
Yes and No. In Unbreakable Linux they copied Red Hat code as part of a very specific Application Stack, and do not provide support for the complete range of tasks and workflows that a regular business user of Red Hat might be able to use / utilize.
By doing this they have sliced off whole areas of the Red Hat brand as 'out of scope' for their support. That has provided some success because of this narrow focus.
I could make a whole article about Red Hat versus Unbreakable Linux, but I'll reiterate what I said and move on...Yes and No.
Here is a question for you....
"Did CentOS or Unbreakable Linux have an easier or harder time of the copying exercise because of GPL"
My opinion: License was irrelevant.
The question of GPL becomes more interesting if CentOS or Unbreakable Linux tried to compete directly with Red Hat by attempting to derive and build upon Red Hat codebase, by say adding a few million lines of code to the kernel and important system routines.
Neither of these things has happened.
No reason why it could not happen, however the 'challenger' would have to be 'better' than Red Hat, and that is no mean feat.
How do I sell my Apache 2.0 software, surely my competitors can just copy it?
See the first three paragraphs of the previous section.
Licensing is playing no part in this question, it really is firstly about whether you truly have something that you can build a sustainable business around.
( A few thousand lines is just not going to cut it, regardless of whether you license GPL, Apache 2, or keep it hidden in a safe! )
What your competitors might be able to do if the code is Apache 2.0 is wrap it up and pass it off as their own, by submitting to a smartphone app store. It does happen!
But I digress, lets say that your product is a significant codebase, say 10 million lines of code.
Perhaps it is the Apache server itself?
Does Apache 2.0 license prevent some other company from coming along, wrapping that code up and calling it Cherokeeee Web Server.
Some companies in fact probably do similar things - I am just guessing here that IBM http server is probably Apache rebadged (I might be mistaken)
Why does Apache not just go commercial and sell it's software?
The history and licensing decisions made previously have provided an ethos which would be difficult for the Apache foundation to now change.
Fact is that IIS which is Microsoft's take on web serving, is hardly a cash cow, so reality also says that web serving (as a portion of the corporate stack), is not a profitable segment to target anyway.
Now OpenOffice is being made available under an Apache license and LibreOffice under an LGPL3 license.
Neither makes a difference to the end users ability to give a copy on a usb stick to a friend - perfectly legal, great way to share a good piece of software with a pal.
So why the distinction? IBM market a free software suite as 'Symphony', and want to continue to 'pull' changes contributed by the open source community, but without engaging with the LibreOffice folks. There is much speculation as to why that might be, however I leave that as a research exercise for the reader.
Does Apache 2.0 or LGPL3 make any difference to IBM ability to rebrand? Not really, however LibreOffice is something that IBM (and Oracle) see as an organisation that might undermine their attempts, to dominate a business channel (Non-Microsoft Office)
The reaction: Undermine LibreOffice by creating a split license situation, and attempt to slow the acceptance of LibreOffice.
Neither Apache 2.0 nor a GPL license make any difference to the Office example above - that is just corporate shenanigans ... license switching to disrupt a new competitor (LibreOffice) before it can develop a sales channel of it's own.
But one day I might be the IBM or Oracle? Well you might be, but more likely is that you will make a successful business selling to SME's, and shifting several hundred thousand licenses - in direct competition to IBM and Oracle.
You will likely be on the receiving end, of similar attempts to disrupt your sales channel by the big corporates.
Here you need to think about software licensing as a 'protection' of you business, not from the consumer (EULAs and all that garbage), but from the sharks further up the food chain.
Reread your preferred license, and think about it, from the point of view of your own business success, and how your OSI license, might help you deal with threats from larger players.
Here your concerns will go beyond software licensing, and will take in branding, marketing, patents, access to markets and other concerns.
Piece of advice: Stay away from any sort of custom license. Choose GPL or Apache 2.0 and run with it. Any sort of custom license may well open you up to:
- The slow drip drip of fees to law firms, as the market challenges the custom clauses you have created. Probably seemed a great idea at the time, but long term, those custom clauses are just a law firm money sink.
- Disruptive moves by the larger competition. The top ten frequently used licenses from OSI including GPL and LGPL and Apache 2.0 have clauses that were carefully drafted over several years, and have been tested in the market.
How do I partner with Commercial companies - do I have to change my license?
Not at all.
If you are GPL, then some of your partnerships will be formed on a sharealike understanding.
If you are GPL, then you can make whatever alternative licensing arrangements you like with partners who are wanting to take a codebase, and work on it without contributing back changes.
The phrase is "Dual licensing"
You can go further and "Triple license", it really is up to your company.
The important thing is not to switch from GPL. When you do that you create a future cul-de-sac into, which an IP aggressor can push the project after a takeover.
Worst case: You are taken over by Oracle and everything seems rosy for a couple of years, then the closure creep begins to wear on you, and you get tired of your once great product being just an 'up sell' opportunity to a proprietary product.
You have spent a decade working on the thing. Within two years the takeover has dead ended your project. By switching away from the GPL a couple of years prior to the sale, those two years of building (now kept private) are lost to you and everyone else.
Do you work on that software ever again? Do you give up on software engineering altogether as you cannot see yourself investing a decade in something new?
The things I have referred to in the past three paragraphs are real. Do some reading up about the career moves of the leading Java and MySQL folks, during and after, the Sun to Oracle sale.
I am wanting to partner with Puppet, but somebody suggested that this GPL thing is dangerous?
Do your research. Consult as widely as you need to.
You talk to some fella in the queue at Starbucks, and he mentions that GPL is bad and Apache 2.0 is better.
I repeat ... Consult as widely as you need to. Try a software licensing expert if in doubt.
(If it costs you £500, it really is small change for a partnership, where you intend to work on several hundred thousand lines of code)
When you consult, you will understand that a key question is 'sharealike'.
Puppet make their code freely available for partners and the wider community to distribute and modify. Do you want to do that?
Do you want your partners to be compelled to 'return the favour', and make available the 5,000 lines of enhancement they just added?
A commercial license arrangement in addition to GPL give you both ways of partnering - pay me and take my codebase with no forward requirement to share your enhancements, or take the GPL codebase and 'sharealike'.
A commercial license arrangement (in addition to GPL) also *might* be expected to include warranty and indemnification.
If your partner indicates that they want (1)Warranty and (2)Indemnification included in the commercial license...
Then (1) means people, time, and quality business processes and (2) means legal counsel and possibly a commitment, by your company, to absorb some of the legal threat a partner may be subject to, as a direct result of using and distributing your original codebase.
Just to point out one benefit of the GPL from the perspective of a future partner.
**A commitment to non-exclusive patent granting.**
But how could this be a benefit for me as a partner?
As the only partner, you probably care little about the two way non-exclusive patent handshake you are party to through the GPL.
However I give an example of the situation under Apache 2.0 which has no bi-directional non-exclusive patent right clause.
I am Puppet, and I develop software P. I then partner with you (Apache 2.0) and you develop your own P+. Another partner agreement is made (Apache 2.0) and another product P++ is born.
The P++ vendor is an IP aggressor and intends to use the '++' features as a market lockout. The company files a bundle of patents on the '++' technology they added, develops the market to want those '++' features.
Nothing too bad just yet.
But then the patent stick is pulled out. As a 'market aware' partner you mistakenly got caught up in adding some of those features, which IP aggressor patented, and you are now the target of a patent lawsuit.
Three boats set out on the river...the original and two partners.
The original has now become a little less relevant due to market developments.
The 'P+' partner (that's you) has been killed off by the deliberate patent plan of the 'P++' vendor.
A non-exclusive patent clause now probably sounds like a good idea in retrospect.
A non-exclusive patent clause is not to be feared as a partner, if you genuinely build robust reliable software that is better than the competition (P++), then people will buy it. It does not need patents to be a better product. It needs skilled developers and lots of commitment.
But Oracle will just take my additions and market that on top of their product?
Are they marketing a 'better' product than you by doing that?
No. And your customers can see just that.
( Going back to the Unbreakable Linux question, Oracle in that instance are not offering a 'better' product, they are addressing a very specific appliance segment, one which is not, just now, targeted explicitly by Red Hat )
But what about the original project, should they be rewarded for not adding features the market wants?
If the P++ vendor has really built an excellent, and significant set of features in the ++ additions it made, then it will be first to market, and associated with those excellent features.
There is little reward to just copying exactly what another vendor has done, especially if that vendor has an active marketing campaign.
They are associated with being first to market with the ++ features, and make the sales.
However if the ++ features are an unstable pile of mush, then the original project could theoretically rework the codebase and implement it better.
Who wins there? The market and the customer.
Just to put things back into terms of the boats on the river analogy...
A bi-directional non-exclusive patent right, ensures that none of the partners can sink the boats of the other using patent aggression.
This is why Oracle and Microsoft do everything they can to discourage GPL adoption, it deprives them of an element of their corporate strategy ...
... To kill decent rival products by using patent aggression, to scare development teams away from projects, using patentable 'value added' additions, and private patent agreements.
Whilst I do not agree with everything that Brian Gentile of Jaspersoft say, I quote an extract here with my own highlighting:
They would rather have standard, commercial terms around the software and its use. By going to a commercial version, customers have a commercial license which includes the indemnification and protection they want to go along with it.I have touched on some of those highlighted points previously.
The third reason is professional support. The forums and the support that you get from working with the Jaspersoft community are pretty robust, but if your use of Jaspersoft is relatively mission critical, you probably want the comfort of knowing that you have a support team that’s very intimate with the code and available to you 24/7.
I am going to interpret the use of the word indemnification to mean warranty, something which MySQL AB used to offer in it's commercial licensing, to meet that requirement.
Brian's use of the word protection should have been clarified further by the interviewer, or Brian himself.
I will not speculate further, other than saying this, could be just another way of saying 'security updates', or could be closer to what the Oracle and Microsoft camps, mean by protection.
Oracle and GPL:
I could take aim at Oracle regarding the Oracle / Google android situation, however I reserve judgment on that issue. It is complicated and has a ream of in depth articles already.
But surely Oracle contributes to Open Source, and under the GPL license?
Btrfs is a good technology, and the license is GPL
Contributing to one project under GPL, whilst a promising start, does not 'define' Oracle.
Since taking over Sun, Oracle have taken many 'Free and Open Source' projects, and, thrown out anything, which cannot be seen to contribute to their proprietary stack.
Rather than embrace all those developers, Oracle has chosen to reassert it's 'type', rather than adapt.
Microsoft and GPL:
A company even less able to adapt than Oracle, pursuing tired business tactics to try and turn back the clock to the 90s.
Rather than drone on here, just do a websearch for GPL microsoft app store, to read up on opinion, as to why Microsoft, is targeting the GPL, as one of the few OSI-approved licenses which it prevents from entering it's smartphone app store.
By comparison I quote from the Wikipedia section 'Legal barrier to app stores' and the portion related to Ubuntu app store
In other cases, such as the Ubuntu App Store, proprietary commercial software applications and GPL-licensed applications are both available via the same system