Use a BSD style license for your Open Source Project (2021)

> I could bring up how proprietary software companies go out of their way to insult the GPL by calling it "viral" but the breathtaking dishonesty of that argument alone makes my case for me.

Eh?

For a lot of my projects I don't care who uses it; I wrote it for my own reasons and if it's useful for anyone else, including corporations, that's fine with me. Other people can make different decisions on that, but this is mine. Integrating GPL, however, makes it a "GPL project" and makes it harder to use in some contexts because derivative software will have to be GPL as well, which why I'd rather not integrate GPL for these projects.

So it certainly "spreads" to other pieces of the software if integrated; i.e. it's "viral" (although I don't really like that term as it comes off as rather dismissive). All of this is kind of the very purpose of copyleft.

> I could bring up how proprietary software companies go out of their way to insult the GPL by calling it "viral" but the breathtaking dishonesty of that argument alone makes my case for me.

I'm willing to say it -- the reason this narrative has so much purchase is that the FSF wants the GPL to be "viral" via its "interpretations" of its own license. If you don't want people to think you're part of the loony fringes, stop hanging out at the loony fringes.

As to whether the GPL actually is legally "viral", I have my doubts. I think the reason you actually don't see the FSF, SFLC, SFC in court is they think they've already lost at the fringes. The last several years of copyright law has been very, very hostile to any of the legal arguments they might make, say, re: dynamically linking modules. Credibility-wise they'd be wiped out. So, they keep soldiering on, pretending to man the battlements day after day.

That is true. But it is weaker than GPL in that it permits mixing CDDL code with non-CDDL code.

The argument that the essay appears to be making is that large companies want to establish themselves as monopolies by requiring that competing forks publish their changes, incorporating the good changes, and outgunning them on overall development effort. My reading is that the CDDL would not force forks to publish the source code for changes that are made to non-CDDL source files.

On:

"projects using licenses like the GPL… live under constant threat of having someone take over the project by producing a better version of the code and doing it faster than the original owners."

Yeah, I don't understand what the article is trying to say. Honestly the above seems like a good thing.

In other words, it's not that abandoned GPL can't be forked, it's that it's significantly less likely to be forked because the number of parties that could potentially fork it is significantly smaller.

Particularly for more niche projects, it depends not only on a party with the same use case and licensing needs as the original author stumbling across it, but also having the skill and will to take it over and judging that it's better to do that than to start from scratch. There's so many funnels there I wouldn't be surprised if for many projects only a single-digit number of people match that description.

I know the differences perfectly well. This is not a problem of me not knowing the difference. But what do the differences have to do with the point the author is trying to make?

Because it doesn't make any sense to me.

Either that or just multi-license, apache2+gpl2-or-later

> Why would the eventual user care whether or not something is GPL or BSD?

As a user, I definitely prefer to use a copylefted program. This means that I am guaranteed to enjoy the four software freedoms; in particular, I can look at how the program works and I can change its behavior, or hire a programmer to change it.

A non-copylefted program, however, may be distributed by some middleman that deprives me of this freedom. Even if the original developer of the program shared it under a free-software licence, it can be re-packaged as a non-free wrapper. This is impossible with copyleft licenses. Thus, even if copyleft "imposes" some mild restrictions to developers, it is certainly very liberating to users! Notice that the only "restriction" imposed to developers is that they cannot re-package a copylefted program so that it becomes un-free.

I don't develop OpenWRT, but I use it extensively. The GPL is one of the best tools we have for the software side of the right to repair, especially the GPLv3 (anti-tivoization provisions).

Just because you don't actively develop something doesn't mean that you won't find the economy and wider options and market forces it provides useful.

You're not using it, only services on top of it, so you're not entitled to it.

On the other hand, there's a reason Google forbids even spelling the letters AGPL, because then they might have to give you the source code. Copyleft doing exactly what it's supposed to do.

That's the main omission in the article. They claim if you modify the source of a GPL program you need to publish your modifications. That's just not correct. If you distribute a binary form of the modified program you need to make the source available. Google don't distribute their internal kernel, so they are not required to make their modifications available.

are you saying that a goal you support has not been achieved, or that it's a stupid goal?

A negative for the ISC license: there has been controversy about "and/or" vs. "and" wording in the ISC license text. [1]

The OpenBSD project uses the "and" wording, whereas the license text on the OSI website uses the "and/or" wording.

Given all this, it seems to me that recommending the 2-clause BSD is the most straightforward option, because its only (and innocuous) issue is that it contains some no-longer-necessary language after the Berne convention agreements.

[1] From Wikipedia: When initially released, the license did not include the term "and/or", which was changed from "and" by ISC in 2007. Paul Vixie stated on the BIND mailing list that the ISC license started using the term "and/or" to avoid controversy similar to the events surrounding the University of Washington's refusal to allow distribution of the Pine email software.

Does anyone know which parts in the 2-clause BSD license were made unnecessary by the Berne convention?

No. BSD has a number of problems, not least of which is the false dichotomy re binary and source distribution.

I never knew he was involved at all - I always thought of the UCB work as wholly independent hacking/reverse engineering.

well, the thing about legal documents such as licences is that the devil is in the wording. bsd and mit, to me, seem to have quite different terms.

not conciously, no.