Tag Archives: license

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.

Lightning photos added

Posted on by
Reply

On Monday evening, Angie and I went chasing unexpectedly.  While the storm produced some wind damage, I’ve been unable to find confirmation of a tornado (there was at least one real-time report, though).  We saw very little of interest, until the incredible light show afterward.  So I present to you a few boring cloud pictures, plus also the lightning:

http://weather.funnelfiasco.com/chase/21jun10

This is also kind of exciting because for the first time I’ve forgone the use of tables to layout the photos.  The result is that the page renders based on what your screen wants it to, not on what I demand it does.  This is supposedly a much less evil way to do things.  In the future, I’ll be converting some of the older pages to work this way as well.

Further, I’ve updated some of the pages to reflect new license information.  Instead of my custom written “you must have my permission” text, I’m now licensing content under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.  It’s simpler, more enforceable, and more in line with my own personal values.  There’s a blog post forthcoming where I muse upon licensing issues.  In the meantime, know that the content on FunnelFiasco.com is under whatever license it says it is. I’ll work on updating the license text on pages soon.  And maybe I should consider a more dynamic site (e.g. using PHP) so that I don’t have to keep making these changes on each. freaking. individual. page.