You may have mixed feelings about relying too heavily on open-source software, but if you do use it, the license is everything.

(There are a lot of licenses, by the way—Apache, BSD, GNU, MIT, and Mozilla are some of the popular ones.)

The issue came to a head last week due to two separate licensing decisions in the space. First, the database project Redis, which is known for its ability to store data in memory, announced it would use a new kind of license called “The Commons Clause,” which looks like open source (in that the source is available to use and modify) but doesn’t fully fit the standard because it allows the project to require that some commercial clients pay for use.

The problem for Redis Labs, the maker of the software, was that many cloud providers, such as Amazon, use its software but don’t contribute to its upkeep.

“Cloud providers contribute very little (if anything) to those open source projects. Instead, they use their monopolistic nature to derive hundreds of millions dollars in revenues from them,” the company wrote on its licenses page. “Already, this behavior has damaged open-source communities and put some of the companies that support them out of business.”

Separately, another open-source project named Lerna, which is used to manage JavaScript projects, attempted to change its license to prevent companies that serve as vendors to U.S. Immigration and Customs Enforcement (ICE) from using the software. That list specifically named 16 companies and organizations, including Microsoft, Amazon, Dell, UPS, Xerox, and multiple universities. But the outcry around Lerna’s decision led to a quick reversal on Thursday.

Both cases, while not specifically affecting associations, reflect new, complicated fronts for open-source software. Redis was trying to address long-standing funding challenges. Meanwhile, Lerna brought politics into an arena where it previously wasn’t before—understandable given the current climate, but still an uncomfortable shift for many.

The outcry from critics was swift. Open Source Initiative (OSI) President Simon Phipps told ZDNet that the new Redis license was “a major abrogation of software freedom, removing essential rights from any affected open-source community.” And Phipps emphasized on Twitter that Lerna’s move, attaching political views to the way its software is distributed, was contrary to the traditional intent of free software, as laid out by Free Software Foundation founder (and open-source icon) Richard Stallman.

practical questions

The ethical arguments underpinning these points are understandable, especially as OSI’s mission is to protect the use of major open-source licenses. But for IT departments at associations and beyond, the concern is more fundamental: You don’t want to invest thousands of dollars in a specific solution only for the rules to change, because you’re then stuck cleaning up the mess.

Redis’ license problem opens up a useful discussion point for organizations that rely on free software, whether that’s in the form of server software, a content management system, or another piece of software: How much should you contribute if you rely on such a tool? Should that contribution be financial, or should it take some other form—say, by volunteering time or expertise, in the same way your volunteers support your association?

If you’re willing to invest a lot of time and energy in implementing a piece of open-source software, which comes with its own bag of implementation concerns, perhaps financial investment should be part of the equation as well. Many prominent open-source tools have nonprofit foundations supporting their work; like your association, they’re trying to make the money work, too.

As for Lerna, I think the lesson there is about relationships. Just like regular vendors, open-source projects have real people building their tools, and it’s worth understanding what motivates their decision-making. Depending on the importance of the tool to your organization, that might mean building a relationship with the development team. Dramatic license shifts are rare, but if you have a relationship with the team, it’s more likely you’ll have a say in where the project goes next.

These stories, while far outside the norm for what we’ve come to expect from open-source software, may help build a case for some against relying on open-source tools within an organization. But that would be the wrong lesson to take here.

The real lesson is the same as it is with traditional vendors: You should be in the loop on an open-source project just the same as you might be on a tool that you pay for.

Don’t get caught off guard.

(LysenkoAlexander/iStock/Getty Images Plus)