Copyleft licenses are not "restrictive" | Hacker News Reader

Copyleft licenses are not "restrictive"

drewdevault.com

31 pointsdrewdevault12 comments

Copyleft licenses are restrictive as obligations are restrictions. "You must provide a source code to your users" is equivalent to "You cannot use this software if your source code is not available to your users".

Freedom is a finite resource in which copyleft licenses take from the developer to give to users. (which ends up at the same point as the article but I prefer wording it this way.)

> Freedom is a finite resource in which copyleft licenses take from the developer to give to users

I think this GNU essay has the right take: if it enables your own self-determination, that's freedom, but if it enables you to impose on others, that's power, and it makes sense to make the distinction.

https://www.gnu.org/philosophy/freedom-or-power.en.html

I disagree with the title, it feels like arguing on a technicality. Obviously they are restrictive because they make you do something.

As the author points out, there are two axes, freedom of use and obligation. Copyleft has high freedom but some obligation. When collapsed to one dimension that obligation is a restriction.

Licenses like MIT that require sharing a notice would have high freedom and a minor obligation. CC0 or unlicense would have complete freedom and no obligation.

This article paints copyleft software as something fairly disjoint from corporate software, however in my experience these are not mutually exclusive. If you look at the kernel's howto for new development[0], it seems fairly focused on the reality that a majority of people walking in to the linux project are doing so on the payroll of some company. For some guy in his 20s who is a bit late to the party, and not being helped out by some corporate arm, the Linux kernel feels like this completely unapproachable monster. In other words, without knowing someone ahead of time it seems impossible to be active in the community. The source is available sure, but that doesn't mean the code isn't corporate.

Copyleft licenses often need a lawyer in the room to figure out what can and can not be done, they are complicated legal documents. My preference for MIT is to allow software to spread in a way unencumbered by the access to a license lawyer.

[0] https://www.kernel.org/doc/html/v4.16/process/howto.html

An MIT license requires no propagation of software changes. I would say that a Copyleft licenses enforce software to be out-in-world. The lawyers needed to find out how not to propagate changes.

This reverse duality depends on whether the 'software' propagated is that which uses licensed software or evolution in public of the licensed software itself. If Linux itself was MIT licensed we would have a much messier world of fragmented, semi-working, partially compatible, proprietary platforms.

We already live in the world of fragmented, semi-working, partially compatible platforms. The openness did not make this better. Take one look at what is going on in the risc-v world with nearly every soc having its own fork of the linux kernel, hacked up for specifically their board. ARM has the same issue to a lesser extent. You want to try bcachefs on your ARM NAS board? good luck.

Compared to what though? Every SoC having its own entire OS implementation derived from some closed source origin that way back when started from some MIT licensed base. It probably wouldn't even have a bcachefs to every try on it.

Apologies I typed soc but really I was trying to talk about sbc's. The type of little boards you find running linux. As far as I know there is not currently (or at least as of a few years ago) risc-v sbc you could get that boots off of nothing but mainline.

>Take one look at what is going on in the risc-v world with nearly every soc having its own fork of the linux kernel

There aren't that many RISC-V Linux-capable SoCs out there, and the ones I know all can boot a generic Linux (relying on SBI for e.g. timers or console i/o), and have ongoing efforts for upstreaming drivers.

It's a much more serious problem on ARM, which does not have anywhere as much platform nor boot standarization.

I was not aware of a risc-v board that could boot with nothing but mainline, could you link me to one that doesn't require any third party code to use?

Anything based on JH7110, of which VisionFive 2 is most mature.

As well as anything else in opensbi upstream.

Thanks, I'll give that a look.

Reply on news.ycombinator.com