Copyleft licenses are not "restrictive"
drewdevault.com
Copyleft licenses are not "restrictive"
1–10 of 16 posts
Re: Copyleft licenses are not "restrictive"
#2Copyleft 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.)
Re: Copyleft licenses are not "restrictive"
#3[deleted]
Re: Copyleft licenses are not "restrictive"
#4I 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.
Re: Copyleft licenses are not "restrictive"
#5This 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
Re: Copyleft licenses are not "restrictive"
#6[flagged]
Re: Copyleft licenses are not "restrictive"
#7This 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…
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.
Re: Copyleft licenses are not "restrictive"
#8[deleted]
Re: Copyleft licenses are not "restrictive"
#9Copyleft 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.
Re: Copyleft licenses are not "restrictive"
#10This 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…
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 worl…
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.