breaking the very basic principles of open source?
No, the basic principles of open source are either the four freedoms (if you agree w/ Stallman) or the OSI open source definition. Here are Stallman’s four freedoms:
The freedom to run the program as you wish, for any purpose (freedom 0).
The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help others (freedom 2).
The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Russians still have these freedoms WRT the Linux kernel. They can still run, study, and redistribute modified versions of the Linux kernel. There’s no violation here.
No part of the definitions of open source or free software obligate a maintainer to work with anyone else, the only obligations are to the legal freedom of the code. Russians can still use, modify, and redistribute the software, they just aren’t allowed to have maintainer positions within the Linux foundation. They can still submit code, and it’s up to the maintainers if they choose to look at that code.
That said, I’m sad that it has come to this. I hate the idea of international politics interfering w/ FOSS, but I still maintain that it’s 100% fine for Linus Torvalds (and his legal counsel) to make this call. So I agree with the core of your argument, that politics interfering w/ FOSS is bad, but I disagree that it violates any part of the basic concept of FOSS, FOSS maintainers should always be able to decide who they work with, and the rest of the community gets to decide if they’re okay with that or if they’d rather follow someone else’s fork.
Fair on your part, I might’ve gone too far with my argument.
I was talking more about collaborative nature and what happens to it when the major open-surce project decides to gatekeep based on something highly arbitrary.
Linux is long past a simple hobby project, and it should be managed responsibly and with respect to the people that make this all happen.
Sure, the roots of FOSS came from collaboration, with people sharing code between universities and whatnot. But the process has always been “here are my changes, take them if you like.” So even the term “collaboration” is a bit of a stretch, since it was almost always a bunch of solo efforts and people would pull in the changes they like. The idea of any kind of structure to FOSS development was added later to help organize it, but the foundation was always someone working on a thing and then advertising those changes for others to pull, if they wanted.
A collaborative project would work something like Python where a core team decides which features to add (i.e. PEPs), and people on the dev team or the community at large would develop those features, and any development that’s not part of those approved features tend to be rejected until it goes through the review process.
Linux isn’t particularly collaborative in that sense, it’s more like the old-school FOSS development process where individual developers would build a thing, use it themselves, and then submit their changes for upstream consideration. I worked on a team where we maintained our own kernel patches separate from upstream for years before trying to submit them upstream, and every time we’d upgrade the kernel, we’d have to reapply the patches, occasionally fixing some things that had changed. The network of maintainers is largely a convenience for working in this more chaotic model, where maintainers are responsible for reviewing and passing along changes for a certain area of the kernel, they don’t actually guide development in any meaningful way.
So the main change here is that Russian contributors can still contribute, they just aren’t trusted as inner-circle reviewers. It’s still collaborative in the same sense that it has always been, there’s just a bit more scrutiny over which reviews to trust.
No, the basic principles of open source are either the four freedoms (if you agree w/ Stallman) or the OSI open source definition. Here are Stallman’s four freedoms:
Russians still have these freedoms WRT the Linux kernel. They can still run, study, and redistribute modified versions of the Linux kernel. There’s no violation here.
And the OSI definition is similar (and longer, so I won’t repeat it here).
No part of the definitions of open source or free software obligate a maintainer to work with anyone else, the only obligations are to the legal freedom of the code. Russians can still use, modify, and redistribute the software, they just aren’t allowed to have maintainer positions within the Linux foundation. They can still submit code, and it’s up to the maintainers if they choose to look at that code.
That said, I’m sad that it has come to this. I hate the idea of international politics interfering w/ FOSS, but I still maintain that it’s 100% fine for Linus Torvalds (and his legal counsel) to make this call. So I agree with the core of your argument, that politics interfering w/ FOSS is bad, but I disagree that it violates any part of the basic concept of FOSS, FOSS maintainers should always be able to decide who they work with, and the rest of the community gets to decide if they’re okay with that or if they’d rather follow someone else’s fork.
Fair on your part, I might’ve gone too far with my argument.
I was talking more about collaborative nature and what happens to it when the major open-surce project decides to gatekeep based on something highly arbitrary.
Linux is long past a simple hobby project, and it should be managed responsibly and with respect to the people that make this all happen.
Sure, the roots of FOSS came from collaboration, with people sharing code between universities and whatnot. But the process has always been “here are my changes, take them if you like.” So even the term “collaboration” is a bit of a stretch, since it was almost always a bunch of solo efforts and people would pull in the changes they like. The idea of any kind of structure to FOSS development was added later to help organize it, but the foundation was always someone working on a thing and then advertising those changes for others to pull, if they wanted.
A collaborative project would work something like Python where a core team decides which features to add (i.e. PEPs), and people on the dev team or the community at large would develop those features, and any development that’s not part of those approved features tend to be rejected until it goes through the review process.
Linux isn’t particularly collaborative in that sense, it’s more like the old-school FOSS development process where individual developers would build a thing, use it themselves, and then submit their changes for upstream consideration. I worked on a team where we maintained our own kernel patches separate from upstream for years before trying to submit them upstream, and every time we’d upgrade the kernel, we’d have to reapply the patches, occasionally fixing some things that had changed. The network of maintainers is largely a convenience for working in this more chaotic model, where maintainers are responsible for reviewing and passing along changes for a certain area of the kernel, they don’t actually guide development in any meaningful way.
So the main change here is that Russian contributors can still contribute, they just aren’t trusted as inner-circle reviewers. It’s still collaborative in the same sense that it has always been, there’s just a bit more scrutiny over which reviews to trust.