I find myself reluctantly agreeing with most of the article, which makes me sad. Nevertheless, I would like to be pragmatic about this.
That said, I think that most of the problems with the GPL can be sufficiently mitigated if we just remove the virality. In particular, I don’t think that copyleft is the problem.
The reason is because I believe that without the virality, companies would be willing to use copyleft licenses since the requirements for compliance would literally be “publish your changes.” That’s a low bar and especially easy in the world of DVCS’s and GitHub.
However, I could be wrong, so if I am, please tell me how.
The problem with ‘non-viral’ copyleft licenses (more commonly known as ‘per-file copyleft’ licenses) is that they impede refactoring. They’re fine if the thing is completely self-contained but if you want to change where a layer is in the system then you can’t move functions between files without talking to lawyers. Oh, and if you use them you’re typically flamed by the FSF because I don’t think anyone has managed to write a per-file copyleft license that is GPL-compatible (Mozilla got around this by triple-licensing things).
That said, I think one of the key parts of this article is something that I wrote about 15 or so years ago: From an end-user perspective, MS Office better meets a bunch of the Free Software Manifesto requirements than OpenOffice. If I find a critical bug in either then, as an experienced C++ programmer, I still have approximately the same chance of fixing it in either: zero. MS doesn’t let me fix the MS Office bug[1] but I’ve read some of the OpenOffice code and I still have nightmares about it. For a typical user, who isn’t a C++ programmer, OpenOffice is even more an opaque blob.
The fact that MS Office is proprietary has meant that it has been required to expose stable public interfaces for customisation. This means that it is much easier for a small company to maintain a load of in-house extensions to MS Office than it is to do the same for most F/OSS projects. In the ‘90s, MS invested heavily in end-user programming tools and as a result it’s quite easy for someone with a very small amount of programming experience to write some simple automation for their workload in MS Office. A lot of F/OSS projects have an elitist attitude about programming and don’t want end users to be extending the programs unless they pass the gatekeeping requirements of learning programming languages whose abstractions are far too low-level for the task at hand. There is really no reason that anything other than a core bit of compute-heavy code for any desktop or mobile app needs to be written in C/C++/Rust, when it could be in interpreted Python or Lua without any user-perceptible difference in performance.
Even the second-source argument (which is really compelling to a lot of companies) doesn’t really hold up because modern codebases are so huge. Remember that Stallman was writing that manifesto back when a typical home computer such as the BBC Model B was sufficiently simple that a single person could completely understand the entire hardware and software stack and a complete UNIX system could be written by half a dozen people in a year (Minix was released a few years later and was written by a single person, including kernel and userland. It was around 15,000 lines of code). Modern software is insanely complicated. Just the kernel for a modern *NIX system is millions of lines of code, so is the compiler. The bc utility is a tiny part of the FreeBSD base system (if memory serves, you wrote it, so should be familiar with the codebase) and yet is more code than the whole of UNIX Release 7 (it also has about as much documentation as the entire printed manual for UNIX Release 7).
In a world where software is this complex, it might be possible for a second company to come along and fix a bug or add a feature for you but it’s going to be a lot more expensive for them to do it than the company that’s familiar with the codebase. This is pretty much the core of Red Hat’s business model: they us Fedora to push core bits of Red Hat-controlled code into the Linux ecosystem, make them dependencies for everything, and then can charge whatever the like for support because no one else understands the code.
From an end-user perspective, well-documented stable interfaces with end-user programming tools give you the key advantages of Free Software. If there are two (or more) companies that implement the same stable interfaces, that’s a complete win.
F/OSS also struggles with an economic model. Proprietary software exists because we don’t have a good model for any kind of zero-marginal-cost goods. Creating a new movie, novel, piece of investigative journalism, program, and so on, is an expensive activity that needs funding. Copying any of these things has approximately zero cost, yet we fund the former by charging for the latter. This makes absolutely no sense from any rational perspective yet it is, to date, the only model that has been made to work at scale.
[1] Well, okay, I work at MS and with the whole ‘One Microsoft’ initiative I can browse all of our internal code and submit fixes, but this isn’t an option for most people.
The fact that MS Office is proprietary has meant that it has been required to expose stable public interfaces for customisation. This means that it is much easier for a small company to maintain a load of in-house extensions to MS Office than it is to do the same for most F/OSS projects. In the ‘90s, MS invested heavily in end-user programming tools and as a result it’s quite easy for someone with a very small amount of programming experience to write some simple automation for their workload in MS Office. A lot of F/OSS projects have an elitist attitude about programming and don’t want end users to be extending the programs unless they pass the gatekeeping requirements of learning programming languages whose abstractions are far too low-level for the task at hand. There is really no reason that anything other than a core bit of compute-heavy code for any desktop or mobile app needs to be written in C/C++/Rust, when it could be in interpreted Python or Lua without any user-perceptible difference in performance.
I’ve found this to be true for Windows too, as I wrote in a previous comment. I technically know how to extend the Linux desktop beyond writing baubles, but it’s shifting sands compared to how good Windows has been with extensibility. I’m not going to maintain a toolkit or desktop patchset unless I run like, Gentoo.
BTW, from your other reply:
I created a desktop environment project around this idea but we didn’t have sufficient interest from developers to be able to build anything compelling. F/OSS has a singular strength that is also a weakness: It is generally written by people who want to use the software, not by people who want to sell the software. This means that it tends to be incredibly usable to the authors but it is only usable in general if the authors are representative of the general population (and since they are, by definition, programmers, that is intrinsically not the case).
I suspect this is why it never built a tool something like Access/HyperCard/Excel/etc. that empower end users - because they don’t need it, because they are developers. Arguably, the original sin of free software (is assuming users are developers), and in a wider sense, why its threat model drifted further from reality.
The problem with ‘non-viral’ copyleft licenses (more commonly known as ‘per-file copyleft’ licenses) is that they impede refactoring. They’re fine if the thing is completely self-contained but if you want to change where a layer is in the system then you can’t move functions between files without talking to lawyers.
Is it possible to have a non-viral copyleft license that is not per-file? I hope so, and I wrote licenses to do that which I am going to have checked by a lawyer. If he says it’s impossible, I’ll have to give up on that.
Oh, and if you use them you’re typically flamed by the FSF because I don’t think anyone has managed to write a per-file copyleft license that is GPL-compatible (Mozilla got around this by triple-licensing things).
Eh, I’m not worried about GPL compatibility. And I’m not worried about being flamed by the FSF.
That said, I think one of the key parts of this article is something that I wrote about 15 or so years ago: From an end-user perspective, MS Office better meets a bunch of the Free Software Manifesto requirements than OpenOffice. If I find a critical bug in either then, as an experienced C++ programmer, I still have approximately the same chance of fixing it in either: zero. MS doesn’t let me fix the MS Office bug[1] but I’ve read some of the OpenOffice code and I still have nightmares about it. For a typical user, who isn’t a C++ programmer, OpenOffice is even more an opaque blob.
This is a good point, and it is a massive blow against Free Software since Free Software was supposed to be about the users.
Even the second-source argument (which is really compelling to a lot of companies) doesn’t really hold up because modern codebases are so huge.
I personally think this is a separate problem, but yes, one that has to be fixed before the second-source argument applies.
The bc utility is a tiny part of the FreeBSD base system (if memory serves, you wrote it, so should be familiar with the codebase) and yet is more code than the whole of UNIX Release 7 (it also has about as much documentation as the entire printed manual for UNIX Release 7).
Sure, it’s a tiny part of the codebase, but I’m not sure bc is a good example here. bc is probably the most complicated of the POSIX tools, and it still has less lines of code than MINIX. (It’s about 10k of actual lines of code; there are a lot of comments for documentation.) You said MINIX implemented userspace; does that mean POSIX tools? If it did, I have very little faith in the robustness of those tools.
I don’t know if you’ve read the sources of the original Morris bc, but I have (well, its closest descendant). It was terrible code. When checking for keywords, the parser just checked for the second letter of a name and then just happily continued. And hardly any error checking at all.
After looking at that code, I wondered how much of original Unix was terrible in the same way, and how terrible MINIX’s userspace is as well.
So I don’t think holding up original Unix as an example of “this is how simple software can be” is a good idea. More complexity is needed than that; we want robust software as well.
In other words, I think there is a place for more complexity in software than original Unix had. However, the complexity in modern-day software is out of control. Compilers don’t need to be millions of lines of code, and if you discount drivers, neither should operating systems. But they can have a good amount of code. (I think a compiler with 100k LOC is not too bad, if you include optimizations.)
So we’ve gone from too much minimalism to too much complexity. I hope we can find the center between those two. How do we know when we have found it? When our software is robust. Too much minimalism removes robustness, and too much complexity does the same thing. (I should write a blog post about that, but the CMake/Make recursive performance one comes first.)
bc is complex because it’s robust. In fact, I always issue a challenge to people who claim that my code is bad to find a crash or a memory bug in bc. No one has ever come back with such a bug. That is the robustness I am talking about. That said, if bc were any more complex than it is (and I could still probably reduce its complexity), then it could not be as robust as it is.
Also, with regards to the documentation, it has that much documentation because (I think) it documents more than the Unix manual. I have documented it to ensure that the bus factor is not a thing, so the documentation for it goes down to the code level, including why I made decisions I did, algorithms I used, etc. I don’t think the Unix manual covered those things.
From an end-user perspective, well-documented stable interfaces with end-user programming tools give you the key advantages of Free Software. If there are two (or more) companies that implement the same stable interfaces, that’s a complete win.
This is a point I find myself reluctantly agreeing with, and I think it goes back to something you said earlier:
A lot of F/OSS projects have an elitist attitude about programming and don’t want end users to be extending the programs unless they pass the gatekeeping requirements of learning programming languages whose abstractions are far too low-level for the task at hand.
This, I think, is the biggest problem with FOSS. FOSS was supposed to be about user freedom, but instead, we adopted this terrible attitude and lost our way.
Perhaps if we discarded this attitude and made software designed for users and easy for users to use and extend, we might turn things around. But we cannot make progress with that attitude.
That does, of course, point to you being correct about other things, specifically, that licenses matter too much right now because if we changed that attitude, would licenses really matter? In my opinion, not to the end user, at least.
Sure, it’s a tiny part of the codebase, but I’m not sure bc is a good example here. bc is probably the most complicated of the POSIX tools, and it still has less lines of code than MINIX. (It’s about 10k of actual lines of code; there are a lot of comments for documentation.) You said MINIX implemented userspace; does that mean POSIX tools? If it did, I have very little faith in the robustness of those tools.
To be clear, I’m not saying that everything should be as simple as code of this era. UNIX Release 7 and Minix 1.0 were on the order of 10-20KLoC for two related reasons:
The original hardware was incredibly resource constrained, so you couldn’t fit much software in the available storage and memory.
They were designed for teaching (more true for Minix, but somewhat true for early UNIX versions) and so were intentionally simple.
Minix did, I believe, implement POSIX.1, but so did NT4’s POSIX layer: returning ENOTIMPLEMENTED was a valid implementation and it was also valid for setlocale to support only "C" and "POSIX". Things that were missing were added in later systems because they were useful.
My point is that the GNU Manifesto was written at a time when it was completely feasible for someone to sit down and rewrite all of the software on their computer from scratch. Today, I don’t think I would be confident that I could rewrite awk or bc, let alone Chromium or LLVM from scratch and I don’t think I’d even be confident that I could fix a bug in one of these projects (I’ve been working on LLVM since around 2007 and I there are bugs I’ve encountered that I’ve had no idea how to fix, and LLVM is one of the most approachable large codebases that I’ve worked on).
So we’ve gone from too much minimalism to too much complexity. I hope we can find the center between those two. How do we know when we have found it? When our software is robust. Too much minimalism removes robustness, and too much complexity does the same thing. (I should write a blog post about that, but the CMake/Make recursive performance one comes first.)
I’m not convinced that we have too much complexity. There’s definitely some legacy cruft in these systems but a lot of what’s there is there because it has real value. I think there’s also a principle of conservation of complexity. Removing complexity at one layer tends to cause it to reappear at another and that can leave you with a less robust system overall.
Perhaps if we discarded this attitude and made software designed for users and easy for users to use and extend, we might turn things around. But we cannot make progress with that attitude.
I created a desktop environment project around this idea but we didn’t have sufficient interest from developers to be able to build anything compelling. F/OSS has a singular strength that is also a weakness: It is generally written by people who want to use the software, not by people who want to sell the software. This means that it tends to be incredibly usable to the authors but it is only usable in general if the authors are representative of the general population (and since they are, by definition, programmers, that is intrinsically not the case).
One of the most interesting things I’ve seen in usability research was a study in the early 2000s that showed that only around 10-20% of the population thinks in terms of hierarchies for organisation. Most modern programming languages implicitly have a notion of hierarchy (nested scopes and so on) and this is not a natural mindset of the majority of humans (and the most widely used programming language, Excel, does not have this kind of abstraction). This was really obvious when iTunes came out with its tag-and-filter model: most programmers said ‘this is stupid, my music is already organised in folders in a nice hierarchy’ and everyone else said ‘yay, now I can organise my music!’. I don’t think we can really make usable software until we have programming languages that are usable by most people, so that F/OSS projects can have contributors that really reflect how everyone thinks. Sadly, I’m making this problem worse by working on a programming language that retains several notions of hierarchy. I’d love to find a way of removing them but they’re fairly intrinsic to any kind of inductive proof, which is (to date) necessary for a sound type system.
That does, of course, point to you being correct about other things, specifically, that licenses matter too much right now because if we changed that attitude, would licenses really matter? In my opinion, not to the end user, at least.
Licenses probably wouldn’t matter to end users, but they would still matter for companies. I think one of the big things that the F/OSS community misses is that 90% of people who write software don’t work for a tech company. They work for companies whose primary business is something else and they just need some in-house system that’s bespoke. Licensing matters a lot to these people because they don’t have in-house lawyers who are an expert in software licenses and so they avoid any license that they don’t understand without talking to a lawyer. These people should be the ones that F/OSS communities target aggressively because they are working on software that is not their core business and so releasing it publicly has little or no financial cost to them.
To be clear, I’m not saying that everything should be as simple as code of this era.
Apologies.
My point is that the GNU Manifesto was written at a time when it was completely feasible for someone to sit down and rewrite all of the software on their computer from scratch.
Okay, that makes sense, and I agree that the situation has changed.
Today, I don’t think I would be confident that I could rewrite awk or bc, let alone Chromium or LLVM from scratch and I don’t think I’d even be confident that I could fix a bug in one of these projects (I’ve been working on LLVM since around 2007 and I there are bugs I’ve encountered that I’ve had no idea how to fix, and LLVM is one of the most approachable large codebases that I’ve worked on).
I think I can tell you that you could rewrite awk or bc. They’re not that hard, and 10k LOC is a walk in the park for someone like you. But point taken with LLVM and Chromium.
But then again, I think LLVM could be less complex. Chromium, could be as well, but it’s limited by the W3C standards. I could be wrong, though.
I think the biggest problem with most software, including LLVM, is scope creep. Even with bc, I feel the temptation to add more and more.
With LLVM, I do understand that there is a lot of inherent complexity, targeting multiple platforms, lots of needed canonicalization passes, lots of optimization passes, codegen, register allocation. Obviously, you know this better than I do, but I just wanted to make it clear that I understand the inherent complexity. But is it all inherent?
I’m not convinced that we have too much complexity. There’s definitely some legacy cruft in these systems but a lot of what’s there is there because it has real value. I think there’s also a principle of conservation of complexity. Removing complexity at one layer tends to cause it to reappear at another and that can leave you with a less robust system overall.
There is a lot of truth to that, but that’s why I specifically said (or meant) that maximum robustness is the target. I doubt you or anyone would say that Chromium is as robust as possible. I personally would not claim that about LLVM either. I also certainly would not claim that about Linux, FreeBSD, or even ZFS!
And I would not include legacy cruft in “too much complexity” unless it is past time that it is removed. For example, Linux keeping deprecated syscalls is not too much complexity, but keeping support for certain arches that have only single-digit users, none of whom will update to the latest Linux, is definitely too much complexity. (It does take a while to identify such cruft, but we also don’t spend enough effort on it.)
Nevertheless, I agree that trying to remove complexity where you shouldn’t will lead to it reappearing elsewhere.
F/OSS has a singular strength that is also a weakness: It is generally written by people who want to use the software, not by people who want to sell the software. This means that it tends to be incredibly usable to the authors but it is only usable in general if the authors are representative of the general population (and since they are, by definition, programmers, that is intrinsically not the case).
I agree with this, and the only thing I could think of to fix this is to create some software that I myself want to use, and to actually use it, but to make it so good that other people want to use it. Those people need support, which could lead to me “selling” the software, or services around it. Of course, as bc shows (because it does fulfill all of the requirements above, but people won’t pay for it), it should not just be anything, but something that would be critical to infrastructure.
One of the most interesting things I’ve seen in usability research was a study in the early 2000s that showed that only around 10-20% of the population thinks in terms of hierarchies for organisation. Most modern programming languages implicitly have a notion of hierarchy (nested scopes and so on) and this is not a natural mindset of the majority of humans (and the most widely used programming language, Excel, does not have this kind of abstraction).
I think I’ve seen that result, and it makes sense, but hierarchy unfortunately makes sense for programming because of the structured programming theorem.
That said, there is a type of programming (beyond Excel) that I think could be useful for the majority of humans is functional programming. Data goes in, gets crunched, comes out. I don’t think such transformation-oriented programming would be too hard for anyone. Bonus points if you can make it graphical (maybe like Blender’s node compositor?). Of course, it would probably end up being quite…inefficient…but once efficiency is required, they can probably get help from a programmer.
I don’t think we can really make usable software until we have programming languages that are usable by most people, so that F/OSS projects can have contributors that really reflect how everyone thinks.
I don’t think it’s possible to create programming languages that produce software that is both efficient and well-structured without hierarchy, so I don’t think, in general, we’re going to be able to have contributors (for code specifically) that are not programmers. That does make me sad. However, what we could do is have more empathy for users and stop assuming we have the same perspective as they do. We could assume that what is good for normal users might not be bad for us and actually try to give them what they need.
But even with that, I don’t think the result from that research is that people 80-90% of people can’t think in hierarchies, just that they do not do so naturally. I think they can learn. Whether they want to is another matter…
I could be wrong about both things; I’m still young and naive.
Licenses probably wouldn’t matter to end users, but they would still matter for companies. I think one of the big things that the F/OSS community misses is that 90% of people who write software don’t work for a tech company. They work for companies whose primary business is something else and they just need some in-house system that’s bespoke. Licensing matters a lot to these people because they don’t have in-house lawyers who are an expert in software licenses and so they avoid any license that they don’t understand without talking to a lawyer. These people should be the ones that F/OSS communities target aggressively because they are working on software that is not their core business and so releasing it publicly has little or no financial cost to them.
That’s a good point. How would you target those people if you were the one in charge?
Now that I have written a lot and taken up a lot of your time, I must apologize. Please don’t feel obligated to respond to me. But I have learned a lot in our conversations.
They’re fine if the thing is completely self-contained but if you want to change where a layer is in the system then you can’t move functions between files without talking to lawyers.
Maybe I misunderstand MPL 2.0, but I think this is a non-issue: if you’re not actually changing the code (just the location), you don’t have to publish anything. If you modify the code (changing implementation), then you have to publish the changes. This is easiest done on a per file basis of course, but I think you technically only need to publish the diff.
This is why it’s non viral: you say, “I’ve copied function X into my code and changed the input from integer to float”. You don’t have to say anything else about how it’s used or why such changes were necessary.
Generally, when you refactor, you don’t just move the code, you move and modify it. If you modify code from an MPL’d file that you’ve copied into another file then you need to make sure that you propagate the MPL into that file and share the changes.
they us Fedora to push core bits of Red Hat-controlled code into the Linux ecosystem, make them dependencies for everything, and then can charge whatever the like for support because no one else understands the code.
How do they make their things “dependencies for everything”? It seems you left out a step where other vendors/distributions choose to adopt Red Hat projects or not.
ISTM that quite a number of RH-backed projects are now such major parts of the infrastructure of Linux that it’s quite hard not to use them. Examples: pulseaudio, systemd, Wayland, and GNOME spring to mind.
All the mainstream distros are now based on these, and the alternatives that are not are increasingly niche.
If you want “non viral copyleft”, there are options: Mozilla Public License and the CDDL which has been derived from it. While they have niches in which they’re popular it’s not like they have taken off, so I’m not sure if “companies would be willing” is the right description.
Without the viral-nature, couldn’t you essentially white-wash the license by forking once and relicensing as MIT, then forking the MIT fork? It would take any power out of the license to enforce itself terms.
Virality is a separate thing from copyleft. People just think they are connected because the GPL is the first license that had both.
You can have a clause in the license that says that the software must be distributed under that license for the parts of the software that were originally under the license.
An example is a license I’ve written (https://yzena.com/yzena-copyleft-license/). It says specifically that the license only applies to the original source code, and any changes to the original source code. Anything else that is integrated (libraries, etc.) is not under the license.
Warning: Do NOT use that license. I have not had a lawyer check it. I will as soon as I can, but until then, it’s not a good idea to use.
So would you have to submit the source of the individual GPL components used as part of a derivative work? I don’t think the GPL would even make sense if it didn’t effect the whole project, that’s what the LGPL is for.
I think if you want to add a single GPL component you would need to release the full software under GPL. (Unless there were other licenses to allow the mixing)
This is such a weird article. I stopped reading halfway in because it felt like the author was fundamentally misunderstanding what the GPL even was about.
Let’s take the argument of “software doesn’t have an owner, so why do you want to restrict what others can do with it?”
This feels like a gotcha-tier misunderstanding of what the GPL is all about. What delimits the GPL from the BSD is precisely that the software is licensed in a restricted fashion. So the code does have a copyright holder. Does that mean it has an owner? No! As long as you work within the bounds of the GPL, the author cannot prevent you from doing what you want with it. It’s an unlimited license. That’s the whole point of the four freedoms!Beyond the bounds of the GPL, the original author remains the copyright holder and can do other things with the code as well, such as commercially license it to a closed-source product - but it seems bizarre to say the GPL has failed on account of capabilities that arise outside the context of the GPL! In the bounds of the GPL’s license terms, all licensees of the code are equal. Specifically, even the original author has no ability to impose restrictions on the GPLed usage. ¹ In any case, if you contribute changes, you are the copyright holder of those changes, so it’s not even correct to say that there is one unambiguous owner. Most GPL projects will have code that is owned, in pieces, by many people - as one would expect from a distributed model. At any rate, precisely Linux is not an example of this, considering the many independent kernel forks. Linus is BDFL by convention, not because he’s in a special position with regards to copyright.
This just feels like weird games with semantics. Which is especially sad because there are genuine problems with the GPL in some jurisdictions, such as the inability to enter into an irrevocable license agreement in the first place. But I didn’t see that mentioned here at all. Frankly, the feeling I get is just that the author switched from “FSF good” to “FSF bad” at some point.
¹ I think it helps to keep Stallman’s printer in the back of your mind whenever considering the GPL. This explains the GPLv3 perfectly - the printer manufacturers are now able to signature check drivers, so GPL3 forbids tivoization. (Canonization?) I think if there’s ever a GPLv4 (Affero GPL?), it will again aim to restore the capability to swap out software that runs something you bought. This is the consistent throughline of the whole concept.
I find myself reluctantly agreeing with most of the article, which makes me sad. Nevertheless, I would like to be pragmatic about this.
That said, I think that most of the problems with the GPL can be sufficiently mitigated if we just remove the virality. In particular, I don’t think that copyleft is the problem.
The reason is because I believe that without the virality, companies would be willing to use copyleft licenses since the requirements for compliance would literally be “publish your changes.” That’s a low bar and especially easy in the world of DVCS’s and GitHub.
However, I could be wrong, so if I am, please tell me how.
The problem with ‘non-viral’ copyleft licenses (more commonly known as ‘per-file copyleft’ licenses) is that they impede refactoring. They’re fine if the thing is completely self-contained but if you want to change where a layer is in the system then you can’t move functions between files without talking to lawyers. Oh, and if you use them you’re typically flamed by the FSF because I don’t think anyone has managed to write a per-file copyleft license that is GPL-compatible (Mozilla got around this by triple-licensing things).
That said, I think one of the key parts of this article is something that I wrote about 15 or so years ago: From an end-user perspective, MS Office better meets a bunch of the Free Software Manifesto requirements than OpenOffice. If I find a critical bug in either then, as an experienced C++ programmer, I still have approximately the same chance of fixing it in either: zero. MS doesn’t let me fix the MS Office bug[1] but I’ve read some of the OpenOffice code and I still have nightmares about it. For a typical user, who isn’t a C++ programmer, OpenOffice is even more an opaque blob.
The fact that MS Office is proprietary has meant that it has been required to expose stable public interfaces for customisation. This means that it is much easier for a small company to maintain a load of in-house extensions to MS Office than it is to do the same for most F/OSS projects. In the ‘90s, MS invested heavily in end-user programming tools and as a result it’s quite easy for someone with a very small amount of programming experience to write some simple automation for their workload in MS Office. A lot of F/OSS projects have an elitist attitude about programming and don’t want end users to be extending the programs unless they pass the gatekeeping requirements of learning programming languages whose abstractions are far too low-level for the task at hand. There is really no reason that anything other than a core bit of compute-heavy code for any desktop or mobile app needs to be written in C/C++/Rust, when it could be in interpreted Python or Lua without any user-perceptible difference in performance.
Even the second-source argument (which is really compelling to a lot of companies) doesn’t really hold up because modern codebases are so huge. Remember that Stallman was writing that manifesto back when a typical home computer such as the BBC Model B was sufficiently simple that a single person could completely understand the entire hardware and software stack and a complete UNIX system could be written by half a dozen people in a year (Minix was released a few years later and was written by a single person, including kernel and userland. It was around 15,000 lines of code). Modern software is insanely complicated. Just the kernel for a modern *NIX system is millions of lines of code, so is the compiler. The
bcutility is a tiny part of the FreeBSD base system (if memory serves, you wrote it, so should be familiar with the codebase) and yet is more code than the whole of UNIX Release 7 (it also has about as much documentation as the entire printed manual for UNIX Release 7).In a world where software is this complex, it might be possible for a second company to come along and fix a bug or add a feature for you but it’s going to be a lot more expensive for them to do it than the company that’s familiar with the codebase. This is pretty much the core of Red Hat’s business model: they us Fedora to push core bits of Red Hat-controlled code into the Linux ecosystem, make them dependencies for everything, and then can charge whatever the like for support because no one else understands the code.
From an end-user perspective, well-documented stable interfaces with end-user programming tools give you the key advantages of Free Software. If there are two (or more) companies that implement the same stable interfaces, that’s a complete win.
F/OSS also struggles with an economic model. Proprietary software exists because we don’t have a good model for any kind of zero-marginal-cost goods. Creating a new movie, novel, piece of investigative journalism, program, and so on, is an expensive activity that needs funding. Copying any of these things has approximately zero cost, yet we fund the former by charging for the latter. This makes absolutely no sense from any rational perspective yet it is, to date, the only model that has been made to work at scale.
[1] Well, okay, I work at MS and with the whole ‘One Microsoft’ initiative I can browse all of our internal code and submit fixes, but this isn’t an option for most people.
I’ve found this to be true for Windows too, as I wrote in a previous comment. I technically know how to extend the Linux desktop beyond writing baubles, but it’s shifting sands compared to how good Windows has been with extensibility. I’m not going to maintain a toolkit or desktop patchset unless I run like, Gentoo.
BTW, from your other reply:
I suspect this is why it never built a tool something like Access/HyperCard/Excel/etc. that empower end users - because they don’t need it, because they are developers. Arguably, the original sin of free software (is assuming users are developers), and in a wider sense, why its threat model drifted further from reality.
Is it possible to have a non-viral copyleft license that is not per-file? I hope so, and I wrote licenses to do that which I am going to have checked by a lawyer. If he says it’s impossible, I’ll have to give up on that.
Eh, I’m not worried about GPL compatibility. And I’m not worried about being flamed by the FSF.
This is a good point, and it is a massive blow against Free Software since Free Software was supposed to be about the users.
I personally think this is a separate problem, but yes, one that has to be fixed before the second-source argument applies.
Sure, it’s a tiny part of the codebase, but I’m not sure
bcis a good example here.bcis probably the most complicated of the POSIX tools, and it still has less lines of code than MINIX. (It’s about 10k of actual lines of code; there are a lot of comments for documentation.) You said MINIX implemented userspace; does that mean POSIX tools? If it did, I have very little faith in the robustness of those tools.I don’t know if you’ve read the sources of the original Morris
bc, but I have (well, its closest descendant). It was terrible code. When checking for keywords, the parser just checked for the second letter of a name and then just happily continued. And hardly any error checking at all.After looking at that code, I wondered how much of original Unix was terrible in the same way, and how terrible MINIX’s userspace is as well.
So I don’t think holding up original Unix as an example of “this is how simple software can be” is a good idea. More complexity is needed than that; we want robust software as well.
In other words, I think there is a place for more complexity in software than original Unix had. However, the complexity in modern-day software is out of control. Compilers don’t need to be millions of lines of code, and if you discount drivers, neither should operating systems. But they can have a good amount of code. (I think a compiler with 100k LOC is not too bad, if you include optimizations.)
So we’ve gone from too much minimalism to too much complexity. I hope we can find the center between those two. How do we know when we have found it? When our software is robust. Too much minimalism removes robustness, and too much complexity does the same thing. (I should write a blog post about that, but the CMake/Make recursive performance one comes first.)
bcis complex because it’s robust. In fact, I always issue a challenge to people who claim that my code is bad to find a crash or a memory bug inbc. No one has ever come back with such a bug. That is the robustness I am talking about. That said, ifbcwere any more complex than it is (and I could still probably reduce its complexity), then it could not be as robust as it is.Also, with regards to the documentation, it has that much documentation because (I think) it documents more than the Unix manual. I have documented it to ensure that the bus factor is not a thing, so the documentation for it goes down to the code level, including why I made decisions I did, algorithms I used, etc. I don’t think the Unix manual covered those things.
This is a point I find myself reluctantly agreeing with, and I think it goes back to something you said earlier:
This, I think, is the biggest problem with FOSS. FOSS was supposed to be about user freedom, but instead, we adopted this terrible attitude and lost our way.
Perhaps if we discarded this attitude and made software designed for users and easy for users to use and extend, we might turn things around. But we cannot make progress with that attitude.
That does, of course, point to you being correct about other things, specifically, that licenses matter too much right now because if we changed that attitude, would licenses really matter? In my opinion, not to the end user, at least.
To be clear, I’m not saying that everything should be as simple as code of this era. UNIX Release 7 and Minix 1.0 were on the order of 10-20KLoC for two related reasons:
Minix did, I believe, implement POSIX.1, but so did NT4’s POSIX layer: returning
ENOTIMPLEMENTEDwas a valid implementation and it was also valid forsetlocaleto support only"C"and"POSIX". Things that were missing were added in later systems because they were useful.My point is that the GNU Manifesto was written at a time when it was completely feasible for someone to sit down and rewrite all of the software on their computer from scratch. Today, I don’t think I would be confident that I could rewrite
awkorbc, let alone Chromium or LLVM from scratch and I don’t think I’d even be confident that I could fix a bug in one of these projects (I’ve been working on LLVM since around 2007 and I there are bugs I’ve encountered that I’ve had no idea how to fix, and LLVM is one of the most approachable large codebases that I’ve worked on).I’m not convinced that we have too much complexity. There’s definitely some legacy cruft in these systems but a lot of what’s there is there because it has real value. I think there’s also a principle of conservation of complexity. Removing complexity at one layer tends to cause it to reappear at another and that can leave you with a less robust system overall.
I created a desktop environment project around this idea but we didn’t have sufficient interest from developers to be able to build anything compelling. F/OSS has a singular strength that is also a weakness: It is generally written by people who want to use the software, not by people who want to sell the software. This means that it tends to be incredibly usable to the authors but it is only usable in general if the authors are representative of the general population (and since they are, by definition, programmers, that is intrinsically not the case).
One of the most interesting things I’ve seen in usability research was a study in the early 2000s that showed that only around 10-20% of the population thinks in terms of hierarchies for organisation. Most modern programming languages implicitly have a notion of hierarchy (nested scopes and so on) and this is not a natural mindset of the majority of humans (and the most widely used programming language, Excel, does not have this kind of abstraction). This was really obvious when iTunes came out with its tag-and-filter model: most programmers said ‘this is stupid, my music is already organised in folders in a nice hierarchy’ and everyone else said ‘yay, now I can organise my music!’. I don’t think we can really make usable software until we have programming languages that are usable by most people, so that F/OSS projects can have contributors that really reflect how everyone thinks. Sadly, I’m making this problem worse by working on a programming language that retains several notions of hierarchy. I’d love to find a way of removing them but they’re fairly intrinsic to any kind of inductive proof, which is (to date) necessary for a sound type system.
Licenses probably wouldn’t matter to end users, but they would still matter for companies. I think one of the big things that the F/OSS community misses is that 90% of people who write software don’t work for a tech company. They work for companies whose primary business is something else and they just need some in-house system that’s bespoke. Licensing matters a lot to these people because they don’t have in-house lawyers who are an expert in software licenses and so they avoid any license that they don’t understand without talking to a lawyer. These people should be the ones that F/OSS communities target aggressively because they are working on software that is not their core business and so releasing it publicly has little or no financial cost to them.
Apologies.
Okay, that makes sense, and I agree that the situation has changed.
I think I can tell you that you could rewrite
awkorbc. They’re not that hard, and 10k LOC is a walk in the park for someone like you. But point taken with LLVM and Chromium.But then again, I think LLVM could be less complex. Chromium, could be as well, but it’s limited by the W3C standards. I could be wrong, though.
I think the biggest problem with most software, including LLVM, is scope creep. Even with
bc, I feel the temptation to add more and more.With LLVM, I do understand that there is a lot of inherent complexity, targeting multiple platforms, lots of needed canonicalization passes, lots of optimization passes, codegen, register allocation. Obviously, you know this better than I do, but I just wanted to make it clear that I understand the inherent complexity. But is it all inherent?
There is a lot of truth to that, but that’s why I specifically said (or meant) that maximum robustness is the target. I doubt you or anyone would say that Chromium is as robust as possible. I personally would not claim that about LLVM either. I also certainly would not claim that about Linux, FreeBSD, or even ZFS!
And I would not include legacy cruft in “too much complexity” unless it is past time that it is removed. For example, Linux keeping deprecated syscalls is not too much complexity, but keeping support for certain arches that have only single-digit users, none of whom will update to the latest Linux, is definitely too much complexity. (It does take a while to identify such cruft, but we also don’t spend enough effort on it.)
Nevertheless, I agree that trying to remove complexity where you shouldn’t will lead to it reappearing elsewhere.
I agree with this, and the only thing I could think of to fix this is to create some software that I myself want to use, and to actually use it, but to make it so good that other people want to use it. Those people need support, which could lead to me “selling” the software, or services around it. Of course, as
bcshows (because it does fulfill all of the requirements above, but people won’t pay for it), it should not just be anything, but something that would be critical to infrastructure.I think I’ve seen that result, and it makes sense, but hierarchy unfortunately makes sense for programming because of the structured programming theorem.
That said, there is a type of programming (beyond Excel) that I think could be useful for the majority of humans is functional programming. Data goes in, gets crunched, comes out. I don’t think such transformation-oriented programming would be too hard for anyone. Bonus points if you can make it graphical (maybe like Blender’s node compositor?). Of course, it would probably end up being quite…inefficient…but once efficiency is required, they can probably get help from a programmer.
I don’t think it’s possible to create programming languages that produce software that is both efficient and well-structured without hierarchy, so I don’t think, in general, we’re going to be able to have contributors (for code specifically) that are not programmers. That does make me sad. However, what we could do is have more empathy for users and stop assuming we have the same perspective as they do. We could assume that what is good for normal users might not be bad for us and actually try to give them what they need.
But even with that, I don’t think the result from that research is that people 80-90% of people can’t think in hierarchies, just that they do not do so naturally. I think they can learn. Whether they want to is another matter…
I could be wrong about both things; I’m still young and naive.
That’s a good point. How would you target those people if you were the one in charge?
Now that I have written a lot and taken up a lot of your time, I must apologize. Please don’t feel obligated to respond to me. But I have learned a lot in our conversations.
Maybe I misunderstand MPL 2.0, but I think this is a non-issue: if you’re not actually changing the code (just the location), you don’t have to publish anything. If you modify the code (changing implementation), then you have to publish the changes. This is easiest done on a per file basis of course, but I think you technically only need to publish the diff.
This is why it’s non viral: you say, “I’ve copied function X into my code and changed the input from integer to float”. You don’t have to say anything else about how it’s used or why such changes were necessary.
Generally, when you refactor, you don’t just move the code, you move and modify it. If you modify code from an MPL’d file that you’ve copied into another file then you need to make sure that you propagate the MPL into that file and share the changes.
How do they make their things “dependencies for everything”? It seems you left out a step where other vendors/distributions choose to adopt Red Hat projects or not.
ISTM that quite a number of RH-backed projects are now such major parts of the infrastructure of Linux that it’s quite hard not to use them. Examples: pulseaudio, systemd, Wayland, and GNOME spring to mind.
All the mainstream distros are now based on these, and the alternatives that are not are increasingly niche.
If you want “non viral copyleft”, there are options: Mozilla Public License and the CDDL which has been derived from it. While they have niches in which they’re popular it’s not like they have taken off, so I’m not sure if “companies would be willing” is the right description.
I think you have a point, which is discouraging to say the least.
Without the viral-nature, couldn’t you essentially white-wash the license by forking once and relicensing as MIT, then forking the MIT fork? It would take any power out of the license to enforce itself terms.
No.
Virality is a separate thing from copyleft. People just think they are connected because the GPL is the first license that had both.
You can have a clause in the license that says that the software must be distributed under that license for the parts of the software that were originally under the license.
An example is a license I’ve written (https://yzena.com/yzena-copyleft-license/). It says specifically that the license only applies to the original source code, and any changes to the original source code. Anything else that is integrated (libraries, etc.) is not under the license.
Warning: Do NOT use that license. I have not had a lawyer check it. I will as soon as I can, but until then, it’s not a good idea to use.
No, because you can’t relicense someone else’s work.
“Virality” is talking about how it forces other software the depends on the viral software to release under the same license.
So would you have to submit the source of the individual GPL components used as part of a derivative work? I don’t think the GPL would even make sense if it didn’t effect the whole project, that’s what the LGPL is for.
I think if you want to add a single GPL component you would need to release the full software under GPL. (Unless there were other licenses to allow the mixing)
The debate isn’t without merit, but free-software-vs-open-source/copyleft-vs-permissive battles never fail to remind me of the PFJ and the JPF.
This is such a weird article. I stopped reading halfway in because it felt like the author was fundamentally misunderstanding what the GPL even was about.
Let’s take the argument of “software doesn’t have an owner, so why do you want to restrict what others can do with it?”
This feels like a gotcha-tier misunderstanding of what the GPL is all about. What delimits the GPL from the BSD is precisely that the software is licensed in a restricted fashion. So the code does have a copyright holder. Does that mean it has an owner? No! As long as you work within the bounds of the GPL, the author cannot prevent you from doing what you want with it. It’s an unlimited license. That’s the whole point of the four freedoms! Beyond the bounds of the GPL, the original author remains the copyright holder and can do other things with the code as well, such as commercially license it to a closed-source product - but it seems bizarre to say the GPL has failed on account of capabilities that arise outside the context of the GPL! In the bounds of the GPL’s license terms, all licensees of the code are equal. Specifically, even the original author has no ability to impose restrictions on the GPLed usage. ¹ In any case, if you contribute changes, you are the copyright holder of those changes, so it’s not even correct to say that there is one unambiguous owner. Most GPL projects will have code that is owned, in pieces, by many people - as one would expect from a distributed model. At any rate, precisely Linux is not an example of this, considering the many independent kernel forks. Linus is BDFL by convention, not because he’s in a special position with regards to copyright.
This just feels like weird games with semantics. Which is especially sad because there are genuine problems with the GPL in some jurisdictions, such as the inability to enter into an irrevocable license agreement in the first place. But I didn’t see that mentioned here at all. Frankly, the feeling I get is just that the author switched from “FSF good” to “FSF bad” at some point.
¹ I think it helps to keep Stallman’s printer in the back of your mind whenever considering the GPL. This explains the GPLv3 perfectly - the printer manufacturers are now able to signature check drivers, so GPL3 forbids tivoization. (Canonization?) I think if there’s ever a GPLv4 (Affero GPL?), it will again aim to restore the capability to swap out software that runs something you bought. This is the consistent throughline of the whole concept.