No. No. And no.
While each of these is important, the gating factor to using an open source project is the license that governs it, according to a joint survey from Tidelift and The New Stack. Eighty-six percent of respondents to the survey cited an “acceptable open source license” as important to their decision to use an open source package, with 61% describing the license as “extremely important.” At bigger companies (over 1,000 employees), a whopping 78% say the license is “extremely important.”
Decades into our open source journey, licensing still matters.
SEE: How to build a successful developer career (free PDF) (TechRepublic)
Scoping the exit
Of course, licensing isn’t the only factor that developers consider. Developers may be an independent bunch, but they prefer to hunt in packs, as it were, for solid repositories. Just behind licensing considerations comes the activity volume of a given open source package (measured according to the number of commits, pulls, etc.), and then factors relevant to community and things like documentation (Figure A).
But licensing sits atop that heap, and for good reason: No developer wants to get into a new open source package without knowing how she’s going to get out. This is one critical reason that highly permissive licenses (Apache, BSD, MIT) have been on a steep climb for many years while more restrictive licenses (GPL) have declined.
SEE: Software licensing policy (TechRepublic Premium)
Corporate legal departments also factor in, as John Mark Walker has pointed out. “[T]hese [developers] have been handed an acceptable license list by their legal counsel. And if a piece of software doesn’t have a license on the allowed list, they have a hefty amount or work ahead of them to get an exception.” Arguably true, but also it’s likely that the “allowed list” exists to steer developers toward licenses with easy exits/light requirements.
This is also why license innovation probably isn’t your friend.
Pushing licensing rocks uphill
For those that have been around open source for awhile, we’ve seen this movie before, or one like it. Starting in 2000, free software advocates argued against license proliferation, which came to a head in 2004 when the Open Source Initiative launched a project to try to rein in license proliferation. At the time, the problem was mostly due to companies or developers launching vanity licenses that differed little from existing licenses, but ended up complicating compliance.
For a decade the open source license landscape remained mostly static. More recently, companies have launched new licenses designed to further their business models, while a new generation of developers has also pushed for licenses that improve working conditions (China’s anti-996 license) or that block the software being used for evil (e.g., the Hippocratic license). One can agree or disagree with the intentions behind these licenses, but one thing is harder to argue: Their practicality.
Again, look at that chart above–the number one gating factor to adoption of an open source project is the license. While Vicky Brasseur is correct to argue that the license should be the last consideration, after first figuring out what you want to do, an unfamiliar license immediately creates uncertainty and thus lowers the chance that the licensed software in question will be part of the solution.
Open source licensing, in short, isn’t the religious issue we once thought it was. It’s the most practical issue of all, for the most pragmatic of people: Developers. Developers are looking for software that works, and that is sustained by a vibrant community. According to the Tidelift/The New Stack survey, they’re probably not particularly interested in deciphering new open source license models.
Disclosure: I work for AWS but nothing written herein is related to my work there.