Tag Archives: license

Does it matter if you anger practitioners and enthusiasts?

Posted on by
Reply

I put this topic on my kanban board in August of 2023. At the time, Hashicorp had just angered a lot of people by switching their popular tools to the Business Source License (BuSL). This was not long after Red Hat angered a lot of people by changing how they made source code for Red Hat Enterprise Linux (RHEL) public. While the anger was numerous and voluminous, my suspicion was that it didn’t matter.

The people who buy enterprise software are, by and large, not the enthusiasts who care about the practical or philosophical importance of open source software. You can anger the nerds (I use that term with endearment, as I am one, too) all you want, because they’re not the ones who sign the checks. This is a cynical take, but Hashicorp’s subsequent (pending) acquisition by IBM would seem to reinforce it. Much of the analysis I read at the time suggested that switching to the BuSL was part of Hashicorp trying to be more appealing to potential buyers and perhaps the reason that IBM made the acquisition offer. I’m not convinced of the latter, since IBM was willing to pay a lot more for Red Hat, who open sourced everything*.

It doesn’t seem to matter

Shortly after the Hashicorp acquisition was announced, SJVN wrote an article in which he noted that IBM’s share price had fallen 8% on the news. This, combined with the fact that Hashicorp stock fell 22% between the announcement of the BuSL switch and the acquisition news, led him to wonder if the acquisition was a “blunder” on IBM’s part. But as of Friday’s close, just over four months since the news was announced, IBM shares are up almost 10% from the pre-announcement price and have reached a one-year high. If the price isn’t quite at an all-time high, it’s within spitting distance of the 2013 peak.

But now we have actual analysis. RedMonk analyst Rachel Stephens published an article last week examining the effect of license changes on Hashicorp, MongoDB, Elastic, and Confluent. You should read the whole article, but the quick summary is that the license changes appear to have no impact on revenue. The changes in valuation and net income are a little messier, but the conclusion holds: “here does not seem to be a clear link between moving from an open source to proprietary license and increasing the company’s value.”

Importantly, though, the analysis does not show a clear link between moving to a proprietary license and decreasing the company’s value. It’s a small sample size, but the best we can tell, changing the license doesn’t matter either way. If your primary business is enterprises, not SMBs or individuals, there’s little evidence that a change that angers practitioners matters, at least in the short term.

What about Elasticsearch?

Elastic dropped a surprise on Thursday. They announced that Elasticsearch is once again open source, this time under the AGPL. Elastic announced a change from the Apache Software License in January 2021, driven in part by issues with Amazon Web Services. Does this mean they finally caved to pressure from the people who were upset about the initial change?

I don’t think so. On the same day Elastic announced the shift to the AGPL, they also released their quarterly earnings. Although the earnings and revenue beat expectations, the company cut their guidance from the coming quarter. The market was displeased, and about a quarter of Elastic’s market value went poof in a single day.

I’m not a market analyst and I don’t have any inside knowledge, so the best I can do is speculate based on what I know about the software industry. But my take is that this license change is less about responding to the pressure from open source fans and more about reducing ambiguity for potential adoptees. The Server Side Public License has some vague terms that could scare away someone trying the free offering, and a better-known license can remove that friction. Is this a win? Maybe, but not a philosophically-driven one.

Elastic’s re-re-license announcement mentions working issues out with AWS. The fact that they switched to the AGPL seems like a defensive move against future perceived shenanigans. If this is the primary motivator, then it seems like the move away from open source was successful and justifies the first license change.

So what do we do?

Anger from practitioners doesn’t seem like a meaningful consequence, so how do we prevent the sort of license changes that have caused such a stir in the last few years? If I had an easy answer, I’d get paid a lot of money as a consultant. (Spoiler: I do not get paid a lot of money as a consultant.)

But it’s clear when making the case for open source at our employers that we should not rely on philosophical arguments (because those only work when money is cheap and times are good). Nor should we rely on a “this will kill us with enthusiasts” because it turns out that might not matter.

The case for open source has to be presented in terms that matter to the business. This doesn’t have to be revenue or profit, which is good since the links are not always direct. But it does need to connect in clear, direct ways to the business’s goals, strategy, or other decision influences.

Does open source matter?

Posted on by
3

Matt Asay’s article “The Open Source Licensing War is Over” has been making the rounds this week, as text and subtext. While his position is certainly spicy, I don’t think it’s entirely wrong. “It’s not that open source doesn’t matter, but rather it has never mattered in the way some hoped or believed,” Asay writes. I think that’s true, and it’s our fault.

To the average person, and even to many developers, the freeness or openness of the software doesn’t matter. They want to be able to solve their problem in the easiest (and cheapest) way. Often that’s open source software. Sometimes it isn’t. But they’re not sitting there thinking about the societal impact of their software choices. They’re trying to get a job done.

Free and open source software (FOSS) advocates often tout the ethical benefits of FOSS. We talk about the “four essential freedoms“. And while those should matter to people, they often don’t. I’ve said before — and I still believe it — FOSS is not the end goal. Any time we end with “and thus: FOSS!”, we’re doing it wrong.

FOSS advocacy — and I suspect this is true of other advocacy efforts as well — tends to try to meet people where we want them to be. The problem, of course, is that people are not where we want them to be. They’re where they are. We have to meet them there, with language that resonates with them, addressing the problems they currently face instead of hypothetical future problems. This is all easier said than done, of course.

Open source licenses don’t matter — they’ve never mattered — except as an implementation detail for the goal we’re trying to achieve.

The right of disattribution

Posted on by
2

While discussing the ttyp0 font license, Richard Fontana and I had a disagreement about its suitability for Fedora. My reasoning for putting it on the “good” list was taking shape as I wrote. Now that I’ve had some time to give it more thought, I want to share a more coherent (I hope) argument. The short version: authors have a fundamental right to require disattribution.

What is disattribution?

Disattribution is a word I invented because the dictionary has no antonym for attribution. Attribution, in the context of open works, means saying who authored the work you’re building on. For example, this post is under the Creative Commons Attribution-ShareAlike 4.0 license. That means you can use and remix it, provided you credit me (Attribution) and also let others use and remix your remix (ShareAlike). On the other hand, disattribution would say something like “you can use and remix this work, but don’t put my name on it.”

Why disattribution?

There are two related reasons an author might want to require disattribution. The first is that either the original work or potential derivatives are embarrassing. Here’s an example: in 8th grade, my friend wrote a few lines of a song about the destruction of Pompeii. He told me that I could write the rest of it on the condition that I don’t tell anyone that he had anything to do with it.

The other reason is more like brand protection. Or perhaps avoiding market confusion. This isn’t necessarily due to embarrassment. Open source maintainers are often overworked. Getting bugs and support requests from a derivative project because the user is confused is a situation worth avoiding.

Licenses that require attribution are uncontroversial. If we can embrace the right of authors to require attribution, we can embrace the right of authors to require disattribution.

Why not disattribution?

Richard’s concerns seemed less philosophical and more practical. Open source licenses are generally concerned with copyright law. Disattribution, particularly in the second reasoning, is closer to trademark law. But licenses are the tool we have available; don’t be surprised when we ask them to do more than they should.

Perhaps the bigger concern is the constraint it places on derivative works. The ttyp0 license requires not using “UW” as the foundry name. Richard’s concern was that two-letter names are too short. I don’t agree. There are plenty of ways to name a project that avoid one specific word. Even in this specific case, a name like “nuwave”—which contains “uw”—because it’s an unrelated “word.”

Excluding a specific word is fine. A requirement that excludes many words or provides some other unreasonable constraint would be the only reason I’d reject such a license.

FOSS licenses permit, not restrict

Posted on by
Reply

Last week, Matthew Wilson shared a very correct take on Twitter:

A few people in the mentions argued that the GPL is doing it wrong by his definition. This is incorrect. Copyleft licenses do not prevent the user from doing things, they ensure that subsequent users can do the same thing.

This may seem like a semantic argument, but there’s substance to it. All licenses (except those that amount to a public domain dedication) contain some conditions, minimal though they may be. It’s important to remember that the default is that you can do nothing with a work. Copyright is by definition a monopoly on a work.The entire point of free and open source software licenses is to tell you what you can do, because the default position is that you can’t.

One of the most annoying things about license wars is the argument that one category of license is somehow more free than another. That’s dumb. Both copyleft and permissive licenses promote freedom, just from different perspectives. Permissive licenses give the next person in line the freedom to do (essentially) whatever they want. Copyleft licenses preserve freedoms for all subsequent users, no matter how many hands the work passes through. There are plenty of philosophical and practical reasons you might choose one class of license over the other (I tend to prefer copyleft licenses, myself), but it’s wrong to paint one or the other as anti-freedom.

Getting back to Matthew’s point, there has been a fair amount of license weaponization in the last few years. By this I mean the use of a license to try to exclude a certain class of user. Some of this I’m sympathetic to (e.g. the “ethical source” movement), some of this I’m not (e.g. the various “you can do what you want, just don’t make a successful software-as-a-service offering” licenses that have popped up). In both cases, I think copyright is the wrong mechanism for achieving the goals.

Excluding classes of users is antithetical to ideals free software and open source. That may be okay. As I’ve written, free software is not the end goal. But if you’re going to claim to be open source, you should act open source.

On CLAs, DCOs, and pinky swears

Posted on by
Reply

Recently, Van Lindberg decided to kick over a hornets’ nest on Twitter:

I don’t think either of them particularly change the risk profile to the end user of a project. Both a contributor license agreement (CLA) and developer certificate of origin (DCO) depend on the contributor asserting something that is correct. In my experience, the most common issue is a developer submitting code they can’t. This could be because they’re reusing code under an incompatible (including proprietary) license.

Another possibility is that they are not the copyright owner. This can be the case when contributing as part of a job or while using their employer’s resources. Van suggests that a CLA helps prevent this because it passes through the contributor’s employer’s legal department. That strikes me as naÏve. Most contributors, I suspect, will sign the CLA on their own without consulting anyone else.

Fundamentally, CLAs and DCOs depend on contributors understanding enough about intellectual property to ensure their contributions are valid. Neither mechanism is particularly effective at that.

This doesn’t mean they’re useless. My 2018 Opensource.com article gives more information on that.

Thoughts on Elastic License v2

Posted on by
Reply

Yesterday Elastic announced a revision to their not-great Elastic License. The Elastic License v2 was updated based on feedback from the community and apparently had a lawyer’s input. And while they seem to be backing off trying to imply that it is open source (because it decidedly is not), it still doesn’t seem like a good license.

First of all, it doesn’t comply with the Open Source Definition, so if that’s important to you, that’s all you need to know. I’m assuming if you’re reading this, you care about the license beyond that. And while I’m not a lawyer (so this is very much not legal advice), here are my thoughts: it’s vague! Seriously, the vagueness makes it a big risk whether or not you care about OSD compliance (and there are many reasons you might not, as I’ll discuss in an upcoming post).

The first line in the Limitations section reads thus:

You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.

This contains two things I have questions about. First of all, what is a “managed service” exactly? Does that include consulting services where someone provides direct management of a customer’s software? I have a good idea of what “managed service” means in industry terms, but if a licensor using this software decides they don’t like what you’re doing, there’s enough vagueness there for them to cause you problems. And of course, if you want to use it in a Software-as-a-Service model, you can’t use it under this license. You can use it under the SSPL, of course, but that is a non-starter for a lot of users.

Secondly, what is a “substantial set of the features or functionality of the software”? If someone does their own implementation of the functionality, does that count? If someone develops additional code that extends the functionality of the software and the upstream project later adds that functionality, does the additional code now violate the license?

Another problem is that it treats “you” and “your company” as distinct entities. This doesn’t make a lot of sense to me. If I use software on behalf of my employer, the employer is the licensee. The “Patents” section contains the only uses of “your company” and says “[i]f your company makes such a claim, your patent license ends immediately for work on behalf of your company”, but that’s redundant because the license was always for my company, not for me.

Frankly, I don’t see why anyone would use this license, particularly now that Amazon has forked the project.

What does “open source” mean in 2021?

Posted on by
2

The licensing discourse in the last few weeks has highlighted a difference between what “open source” means and what we’re talking about when we use the term. Strictly speaking, open source software is software released under a license approved by the Open Source Initiative. In most practical usage, we’re talking about software developed in a particular way. When we talk about open source, we talk about the communities of users and developers, (generally) not the license. “Open source” has come to define an ethos that was all have our own definition of.

Continue reading →

Introducing the “Permissive 3000” license

Posted on by
2

Software licenses aren’t necessarily the easiest texts to understand. This issue is compounded when the person trying to understand the license is in a different jurisdiction or is a non-native speaker of English. A recent thread on the OSI’s license-discuss list brought this issue to light. According to the original poster, a project using the BSD 3-Clause license was used without attribution in a proprietary product. The developer lost the court case because the judge did not understand English well. The poster brought an attempt at a rewrite to the list, but it had some contradictions and other meaningful differences. So I thought I’d give it a try myself.

This weekend, I started from the original BSD 3-Clause license and excised all of the words not on the Oxford 3000™ word list (or reasonably close modifications, e.g. verb tense conjugations). I did make an exception for the word “copyright”, since it seems indispensable to a software license. In all other cases, I used synonyms and circumlocution in order to preserve the meaning while remaining within the constrained word list. This was challenging at times, since circumlocution can end up making the document more difficult to understand than an unknown word might. The difficulty is further compounded by the fact that many words have a distinct legal meaning and a synonym might not have the same weight.

I consoled myself with the fact that software warranties (where most of the real challenge was) are probably not that useful anyway. Furthermore, just because a word has a distinct meaning in American courts, that doesn’t mean that foreign legal systems have the same definitions. Trying to use largely U.S.-centric licenses written in English is a challenge for a global society, but I don’t know that a system of jurisdiction/language-specific licenses would be any better.

In any case, without further ado, I present the Permissive 3000 license. It’s highly experimental and totally unvetted by legal professionals, so nobody should use it for anything except a learning exercise. I’m looking forward to some constructive feedback and hopefully it sparks a discussion about how licenses can be simplified so that they’re more easily understood by judges, developers, and users alike.

How do you measure software quality?

Posted on by
6

There are two major license types in the free/open source software world: copyleft (e.g. GPL) and permissive (e.g. BSD). Because of the different legal ramifications of the licenses, it’s possible to make theoretical arguments that either license would tend to produce higher quality software. For my master’s thesis, I would like to investigate the quality of projects licensed under these paradigms, and whether there’s a significant difference. In order to do this, I’ll need some objective mechanism for measuring some aspect(s) of software quality. This is where you come in: if you have any suggestions for measures to use, or tools to get these measures, please let me know. It will have to be language-independent and preferably not rely on bug reports or other similar data. Operating on source would be preferable, but I have no objections to building binaries if I have to.

The end goal (apart from graduating) is to provide guidance for license selection in open source projects when philosophical considerations are not a concern. I have no intention or desire to turn this into a philosophical debate on the merits of different license types.

Why am I giving my work away for free?!

Posted on by
2

Recently, I began writing a regular weather blog for the local newspaper.  I’m not getting paid for this, so people may wonder why I’m giving free content to a for-profit organization.  I asked myself this very question, and the answer is that I don’t find the terms sufficiently objectionable.  Although the blog appears on the Journal & Courier website, they likely don’t make too much money off the ad revenue.  And while I don’t make any money either, I get the chance to refine and showcase my writing skills for a different audience than I currently have, and I get the chance to bring a little bit of traffic here (maybe I should start selling ads).  Of course there’s always the joy of sharing my knowledge, proving a public service, and keeping all of that meteorology I learned in school in my head a little longer.  Finally, I’m a compulsive favor-doer.

More than any of that, though, I am philosophically in favor of sharing information.  The vast majority of the writing I do is released under some form of the Creative Commons licenses.  The Fedora Project requires me to use the CC-BY-SA license, which does not prohibit commercial use.  In that sense, writing documentation for Fedora and writing my weather blog both could result in people who are not me making money off my work.  That’s fine, because I’m not doing it for money (although if someone wants to leave an envelope of cash on my doorstep, that’s okay).  In both cases, I consider the free access to my effort to be fair trade.  My Fedora work is my way of contributing to the project that provides me with free (both gratis and libre) software that I use on a daily basis.  The writing I do for the Journal & Courier I see as contributing to the betterment of my society (or at least the lowering of my blood pressure. Weather-related stupidity angers me quite effectively).  The fact that one is a non-profit and the other is for-profit is not a consideration for me.

I am a firm believer in freedom for users, but I also believe that content creators should be free to license their works as they see fit.  Copyleft licenses like the GPL are preferable to more restrictive licenses, but if someone wants to put a restrictive license on his work, that right should be available.  In each case, a decision must be reached as to what is and is not acceptable.  In the cases I’ve discussed here, I have determined that, for my own criteria, the terms are acceptable.  The nice thing about volunteer work is that if I determine at some point that the terms are no longer tolerable, I can simply stop contributing.  In the meantime, I hope as many people as possible enjoy the fruits of my labor, and I look forward to enjoying the works of others.