Reading the issue[1] I think the IBM request is a lot more reasonable than this tweet makes it seem. The issue is that a mitmproxy dependency has a CVE, mitmproy updated the dependency (in March), but hasn't made a stable release yet with this update (last release from Nov 2022), and IBM guy is asking "when do you plan to tag a release? Do you have a timeline for this so we can communicate this to our customers?"
Notably it's NOT asking for a fix; "when will you fix it?" is not accurate as there is nothing to be fixed. It's just asking "when do you plan to make a new release with this dependency update?"
I don't think that's an unreasonable question. I also don't think it's unreasonable to ask for a support contract if you want these kind of fixes shipped within a certain timeframe, but the question is a lot more reasonable than it seems at a glance and immediately coming back with "email me for a support contract" seems a bit over the top to me. I could have asked this question and I think most people here could.
The initial question was polite and reasonable, as was @mhils's response. What wasn't at all reasonable was the follow-up email from IBM (same person?) accusing him of a "thinly veiled extortion attempt". Maximilian is not obliged to provide a release schedule to someone who isn't paying him, and it wasn't at all unreasonable to suggest that if IBM really needs a timetable they could pay for it.
Heck, IBM could probably put together their own internal release of mitmproxy today if they cared that much.
IBM is a cash poor company that just doesn't have the resources to pay for the software it sells.</snark>
Seriously though, I am kind of curious why IBM can't cough up cash. I'm guessing it takes a while to set up a vendor in their system. So they probably //could// pay for a support contract, but by the time they set it up they'll have blown through some internal deadline. Or maybe this request is being made from a lower level person and someone in their reporting chain has blocked the idea of setting up a support contract.
My memory of IBM is they're pretty insular, the particular person involved could just not understand what open source is. For instance, I was hired into a team in Boca Raton in the late 80s because my resume said I had experience with multiple Virtual Machines (VMs). I actually had experience with VMS, which was an operating system from Digital Equipment Corporation. When I asked my boss about that, her response was "What's VMS? What's Digital Equipment Corporation?" Which was a very strange thing to say as they had (more than) decimated IBM's S/36 and S/38 sales. Later on when I worked for the AIX division, I found many people who were clueful.
I think what I'm saying is:
1. IBM is a big company. It's probably not accurate to judge the whole organization from one person's interaction.
2. You can survive at IBM without understanding the outside world. (though I'm just extrapolating that assertion from what I saw in the 80s,90s and late 2000s.)
I don't think the initial response was really reasonable. Expecting an open source project that your company is leeching off of to care about your customer's problems is pretty tone deaf. Asking about a release schedule: fine. Trying to pressure the project into releasing sooner by talking about regulations: dick move.
> Heck, IBM could probably put together their own internal release of mitmproxy today if they cared that much.
They could, and so could I, and most people here if they wanted to. That doesn't mean it's an unreasonable question to ask. If anything it's exactly the sort of question you would ask if you planned to make your own release, so you know if it's going to be worth the effort.
Asking for a release date is a perfectly reasonable request! My response was highly influenced by the context. I came back with "email me for a support contract" because 1) I previously stated in the thread that we will not ship a patch release for this[^1] and 2) the commenter emphasized the impact on their paying customers. So this was all I had to add there. I agree that I could have phrased this more nicely, but I personally don't feel my reply was totally over the top.
[^1]: the CVE itself is bogus and we don't use that part of the dependency.
> the CVE itself is bogus and we don't use that part of the dependency.
A trend I'm noticing, compliance and infosec teams only caring about checklists and not able to understand nuances of CVEs. They only see the number. Thus the boneheaded pursuit and odd expectations spilling into the open source ecosystem.
FWIW I think your initial reply was absolutely fine as is. Talking about problems with your paying customers while asking upstream to work for free is pretty tone deaf.
It really wasn't, not from the Tweet alone, which could very easily be interpreted as demanding to fix a specific bug.
As for the email: shrug. The question was reasonable, and his reply on GitHub wasn't especially great, and neither was the email. No one is coming off particularly well here IMHO.
> The issue is that a mitmproxy dependency has a CVE,
As the maintainer explained, the CVE doesn't even effect mitmproxy. All they would be doing is helping an infosec person tick off a box.
> immediately coming back with "email me for a support contract" seems a bit over the top to me.
Why should the maintainer work for free while the requester profits off free labor?
> I don't think that's an unreasonable question
What's unreasonable is FrugalGuy's entitlement. You have to be a special type of hypocrite to accuse an open source maintainer of extortion after demanding they work for free. You can't demand things of volunteers working part time on foss projects.
> You have to be a special type of hypocrite to accuse an open source maintainer of extortion after demanding they work for free. You can't demand things of volunteers working part time on foss projects.
In the original github comment, the corporate asked a question.
Questions are not demands. He didn't say "Do this"; he _ASKED_ "When will you do this?"
This makes it even worse, tbh. Just fork the code and tag an release yourself. How are regulated entities just pulling code from third party repos without a sanity check. At some size this has to happen, right?!?
Emotional labor can be challenging; it requires consistently crafting polite responses.
And .. managing expectations ..
"EXPECTATIONS
Acquiring open source software usually doesn't involve any payment. There's no contract between you and your users, or between you and the people whose software you use.
But the buyer/seller relationship we have in everyday life automatically carries over into this world. People have expectations that software will work, that issues with software will quickly be fixed, and that you'll answer their questions.
This relationship is often the hardest part of software because it as some similarity with traditional buyer / seller relationships but substantial and important differences. With no payment or contract, you can't give an angry user a refund. You can't suggest they leave your store. You'll naturally be in the most empowered place to make the improvements your users want, but how are their needs expressed and received?
Of course, financial transactions aren't the only kind of value exchange. You might work on features in order to make your projects more popular, which leads to a better portfolio and reputation in the community. Reputation can lead to a better job or better positioning if you found a company. You might work on a feature in order to learn about the problem or acquire new skills.
....
Responding to feature requests
Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution.
- The maintainer does not owe their time to anyone
- The maintainer must treat everyone with respect
Ignoring the first principle will lead to burnout: there are unlimited features to be requested and limited time to implement them. The sense of obligation quickly becomes an emotional burden.
Ignoring the second principle will damage the project
and reduce its chances of ever attracting additional contributors, which is the only way to succeed in the long term.
Maintainers are the keepers of the project principles
The goal of the software.
The scope that defines problems that the
software will try to fix and those it will not.
The style of the project: which programming
practices are used, which language.
The culture by which the project is managed.
Maintainers approve of changes to the software by these principles, and also manage discourse and which other contributors are allowed."
Maybe the world isn’t entirely transactional And dominated by the need to grow. ' I can do a thing that provides me some value and maybe it does for you too. We both win.
OP here. To be clear, I don't mind the release question at all, it's valid! But the context should be along the lines of "we have an interest in this, how can we help make it happen" (contributions or $) and not "you are causing problems for our customers". I don't want the requestor to have a miserable time because of a badly-worded comment, I want large companies to have a healthy relationship with FOSS.
The code they're looking for is already in the repo (just a version bump on some dependencies), so the response would actually have been "instructions for building from source can be found here [0]".
We transitioned from S3 to R2 for downloads.mitmproxy.org because egress got prohibitively expensive for a hobby ($300/month). CI for 9.x still points to the old infrastructure. This does not mean we couldn't ship a patch release right now, but it would take me 1-2 hours.
The vulnerability in question is in parts not used by mitmproxy. We looked at it when it came out, and I'd even say it's more of a bug than a security vulnerability. Again, in either case it's not used by mitmproxy.
Given that nobody is paying them, "I don't feel like it right now" is as perfectly valid a reason as any. With an email response like that, I certainly wouldn't feel like it for as long as possible.
How are contributions or money going to solve a release issue? If the issue is a bug, I can fix it and submit it as a patch. But if the issue is that there's no release for already made fixes, how do I fix that with a contribution or money?
Hmmm. Lets say you have a plumber install a sink at your house, and you're happy with it.
If you later on decide you want something extra done to the sink, and the plumber says "oh, that's easy I can do that for you for free in a few weeks..." that would generally be a positive right?
But lets say you wanted it done Real Soon Now instead. Like tomorrow or the next day.
If the plumber's response was "Well, that can be done but I'll have to charge you our normal rates", that doesn't sound unreasonable does it?
That's what this situation seems like to me. I'm not sure why you're thinking there's attempted extortion involved?
Extortion implies an illegal abuse of power to obtain property. A cursory glace at the MIT license (which mitmproxy is licensed under) proves you wrong:
> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software [...]
It's all there, black and white, clear as crystal. They knew what they were getting into when they agreed to the license of the software they use. Hell, IBM could fork the project and sell the code back to the original developer, if they wanted. If they disagree with the license, well... caveat emptor:
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
This sounds very much like the idiocy of "infosec" lunkheads who know nothing about what they're "fixing" but if an automated system tells them a CVE exists, they've absolutely got to have it "patched". They don't look into what the claims of the CVE are, or whether their specific use case is vulnerable. They don't know, they don't care, they're not even programmers. All they know is a box needs ticking.
A similar thing happened with h2database - a "security researcher" found that if you do something you're told not to do, then bad things happen.. but they demanded and got a CVE allocated anyway. Anyone who looks at it realises it's bullshit, but the mere existence of a CVE is all that matters to these idiots.
> I struggle to understand why I should feel the slightest shred of sympathy for "major corporations" that are using a volunteer-developed open-source project. Feel free to get your corporation to pay someone to deal with this, or pay for a similar commercial library.
> This sounds very much like the idiocy of "infosec" lunkheads who know nothing about what they're "fixing" but if an automated system tells them a CVE exists, they've absolutely got to have it "patched". They don't look into what the claims of the CVE are, or whether their specific use case is vulnerable. They don't know, they don't care, they're not even programmers. All they know is a box needs ticking.
They may know and understand all of this and still not care. Maybe their performance is judged by how quick they can get checkboxes checked, with overzealous approvals harming them more than overzealous rejections. They may be empowered to make exceptions when the specific circumstance warrants it, but that might require them to fill out even more paperwork to justify their decision. That extra paperwork slows them down and harms the metrics by which their performance is judged.
“If you pass a password via the command line, other processes on the system could see it via ps.”
Yeah, no shit. If that qualifies as a “high severity” CVE then, uh, you can call me a security researcher because I can think of at least a half a dozen applications that allow the exact same thing with the exact same disclaimer (“don’t do this”).
I work for a SaaS vendor in an industry where that is still a bit 'exotic'. We get sent ridiculous 'security surveys' for which 90% of the answers are N/A. I'm dubious that anyone reviews the other answers.
I’ve had sudden spike of ”when will you fix this” and „I am also affected, this is important!” comments on one of my projects. It was very odd to see sudden interest like that.
But around the same time I’ve got an email with apology explaining that company’s boss asked employees to stir up the pot to pressure me into a fix, pretending its affecting far more people than it really did.
There are many things that I would do for free that I wouldn't do for many thousands of dollars. Once you accept money for something you create an expectation that the thing will get done.
Sounds to me like somebody learned that using an aggressive/threatening tone has been highly effective at their own job and doesn't their negotiating position here is quite different.
There is a subtle difference between "I would like to know when this will happen so I can make plans"and "I need this done because I'm being paid for your work, please hurry". If the requester left out the background information, the tone of the request would have been more of the former and less of the latter.
I disagree that this would have been the right thing to do. There's nothing wrong with explaining why something could be useful in an open source project - if the reason seems like something important that a lot of other users of the software would also need, the maintainers of the software might want to know about it so that they can add the feature or fix the bug sooner. It can also help if there's some way of working around the problem.
Calling the developer extortionate was unreasonable, but I don't think there's anything wrong with the first message.
Corporate entitlement about using open source (and demand support for it) is enormous. I would love if licences with usage restrictions were more popular, and the OSI wouldn't just say "that's not open source!!!". It would prevent these kinds of situations.
The GNU AGPLv3 makes corporate lawyers seethe so hard, it may as well be a non-commercial license. But it isn't, and it satisfies both the OSI and the FSF.
Anyway, it's good for OSI and FSF to take a hardline stance here. If your priorities don't align with theirs, why should they change to satisfy you? Simply use the license you like, even if they don't approve of it. Why is that a problem for you? Why do you need these orgs to stamp their approval on your choice of license, when you obviously don't share their values in the first place?
> I would love if licences with usage restrictions were more popular, and the OSI wouldn't just say "that's not open source!!!".
I agree with you, but guess who pays the OSI's bills: https://opensource.org/sponsors/ For their corporate sponsors, not supporting usage restrictions is a feature, not a bug.
There's also a ton of dogma surrounding the open source and free software definitions where you'll get dog-piled for not conforming to these definitions. These definitions are often considered as holy writ and their adherents refuse to entertain if perhaps these definitions might need to be adjusted for the realities of 2023.
Even if you try to ignore them and coin your own terminology so as to not to conflict, open source and free software advocates will continue to try and control the narrative by insisting on their own language, which is designed to have negative connotations in their circles.
> but guess who pays the OSI's bills: https://opensource.org/sponsors/ For their corporate sponsors, not supporting usage restrictions is a feature, not a bug.
Stallman and the FSF are hardly darlings of the corporate world, but they also consider the first and most important software freedom to be: "The freedom to run the program as you wish, for any purpose (freedom 0)." This is something people in this space earnestly believe in, not something they're just being paid by corporations to espouse.
If you don't share these values, then that's your prerogative. Simply use another license and ignore people who complain about it; since they don't share your values you shouldn't care what they think.
Yeah, you've put it way better than I could ever have, thanks. I just massively dislike how they pretend the OSI has a trademark over the word "open source" (which they don't) and that they presume everyone wants to have their work be freely combinable with others.
If you use it, great, if you don't want to because you are afraid of the legal issues, no problem. It's massive entitlement to think that just because you released the source code, anyone should be granted the four freedoms to essentially do whatever with it. (Which includes the SaaS loophole as well....)
As per the warranty disclaimer, free software is given to you with no strings attached. It is boorish to demand free support and maintenance as well, when you've already been gifted the freedom to make any amendments you see fit. I don't think changing the license would make such boorish people go away.
I think most people don't want to be that anti-corporate. Otherwise they wouldn't use permissive licenses in the first place.
And there may be non-license options that are friendlier to open source than corporate. E.g. if someone has a non-trivial issue they must publish a reproducer.
I'm not sure how that will solve the problem. Chance are the software would still be used in business environments and you would still have people asking for support on behalf of their employer. I have heard stories a plenty of businesses doing that in the 80's, when support was typically offered for free, with pirated software. The only thing that reduced that type of shenanigans were paid support contracts. Your only real recourse is suing for license violations, and relatively few open source developers are going to have the means to do that against a medium business, never mind a major corporation.
While the behavior from "FrugalGuy" is immature and childish, a better way for the mitmproxy maintainer would be to post a polite but firm response, one that leaves no room for error or drama such as this one:
> As per the mitmproxy license, the software is provided as-is without warranty, and project maintainers are currently constrained by other priorities and deliverables.
> As such, statements on the Github issue tracker are not considered as sufficient justification for the prioritization of issues. The only way to prioritize issues would be to enter a support contract, available [here], the terms of which we will be happy to discuss further.
This doesn't seem substantially different from what they actually said, except a bit more rude (maybe that is the intention?) so I'm not sure what this gives you that the actual response doesn't.
I agree you're not owed politeness in this situation, but it prevents the ensuing drama after such things have been said, which is very draining for the people on the receiving end of said drama.
Readit News
Notably it's NOT asking for a fix; "when will you fix it?" is not accurate as there is nothing to be fixed. It's just asking "when do you plan to make a new release with this dependency update?"
I don't think that's an unreasonable question. I also don't think it's unreasonable to ask for a support contract if you want these kind of fixes shipped within a certain timeframe, but the question is a lot more reasonable than it seems at a glance and immediately coming back with "email me for a support contract" seems a bit over the top to me. I could have asked this question and I think most people here could.
[1]: https://github.com/mitmproxy/mitmproxy/issues/6051
Heck, IBM could probably put together their own internal release of mitmproxy today if they cared that much.
Seriously though, I am kind of curious why IBM can't cough up cash. I'm guessing it takes a while to set up a vendor in their system. So they probably //could// pay for a support contract, but by the time they set it up they'll have blown through some internal deadline. Or maybe this request is being made from a lower level person and someone in their reporting chain has blocked the idea of setting up a support contract.
My memory of IBM is they're pretty insular, the particular person involved could just not understand what open source is. For instance, I was hired into a team in Boca Raton in the late 80s because my resume said I had experience with multiple Virtual Machines (VMs). I actually had experience with VMS, which was an operating system from Digital Equipment Corporation. When I asked my boss about that, her response was "What's VMS? What's Digital Equipment Corporation?" Which was a very strange thing to say as they had (more than) decimated IBM's S/36 and S/38 sales. Later on when I worked for the AIX division, I found many people who were clueful.
I think what I'm saying is:
1. IBM is a big company. It's probably not accurate to judge the whole organization from one person's interaction.
2. You can survive at IBM without understanding the outside world. (though I'm just extrapolating that assertion from what I saw in the 80s,90s and late 2000s.)
They could, and so could I, and most people here if they wanted to. That doesn't mean it's an unreasonable question to ask. If anything it's exactly the sort of question you would ask if you planned to make your own release, so you know if it's going to be worth the effort.
Not being a logged in Twitter user, the remainder of the thread is hidden to me.
[^1]: the CVE itself is bogus and we don't use that part of the dependency.
A trend I'm noticing, compliance and infosec teams only caring about checklists and not able to understand nuances of CVEs. They only see the number. Thus the boneheaded pursuit and odd expectations spilling into the open source ecosystem.
It's his follow up communication referring to "thinly-veiled extortion" which is very, very far from reasonable.
It really wasn't, not from the Tweet alone, which could very easily be interpreted as demanding to fix a specific bug.
As for the email: shrug. The question was reasonable, and his reply on GitHub wasn't especially great, and neither was the email. No one is coming off particularly well here IMHO.
Deleted Comment
As the maintainer explained, the CVE doesn't even effect mitmproxy. All they would be doing is helping an infosec person tick off a box.
> immediately coming back with "email me for a support contract" seems a bit over the top to me.
Why should the maintainer work for free while the requester profits off free labor?
> I don't think that's an unreasonable question
What's unreasonable is FrugalGuy's entitlement. You have to be a special type of hypocrite to accuse an open source maintainer of extortion after demanding they work for free. You can't demand things of volunteers working part time on foss projects.
In the original github comment, the corporate asked a question.
Questions are not demands. He didn't say "Do this"; he _ASKED_ "When will you do this?"
Deleted Comment
mhils: "@FrugalGuy has just sent me genuine apology, which I truly appreciate. Please be nice and assume good intentions. :heart: "
https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...
I'm split between my blind hatred of robotic CVE checklists and my blind hatred of waterfall release management.
https://macwright.com/sites/polite.technology/preview
Emotional labor can be challenging; it requires consistently crafting polite responses.
And .. managing expectations ..
"EXPECTATIONS
Acquiring open source software usually doesn't involve any payment. There's no contract between you and your users, or between you and the people whose software you use.
But the buyer/seller relationship we have in everyday life automatically carries over into this world. People have expectations that software will work, that issues with software will quickly be fixed, and that you'll answer their questions.
This relationship is often the hardest part of software because it as some similarity with traditional buyer / seller relationships but substantial and important differences. With no payment or contract, you can't give an angry user a refund. You can't suggest they leave your store. You'll naturally be in the most empowered place to make the improvements your users want, but how are their needs expressed and received?
Of course, financial transactions aren't the only kind of value exchange. You might work on features in order to make your projects more popular, which leads to a better portfolio and reputation in the community. Reputation can lead to a better job or better positioning if you found a company. You might work on a feature in order to learn about the problem or acquire new skills.
....
Responding to feature requests
Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution.
- The maintainer does not owe their time to anyone
- The maintainer must treat everyone with respect
Ignoring the first principle will lead to burnout: there are unlimited features to be requested and limited time to implement them. The sense of obligation quickly becomes an emotional burden.
Ignoring the second principle will damage the project
and reduce its chances of ever attracting additional contributors, which is the only way to succeed in the long term.
Maintainers are the keepers of the project principles The goal of the software. The scope that defines problems that the software will try to fix and those it will not.
The style of the project: which programming practices are used, which language.
The culture by which the project is managed. Maintainers approve of changes to the software by these principles, and also manage discourse and which other contributors are allowed."
Only because people don't read the license which explicitly says YOUR EXPECTATIONS ARE WORTH SQUAT.
Dead Comment
It’s actually very kind of you to offer such a contract.
FrugalGuy could have gotten the response “please submit a PR”. Not sure if that would have made them happy.
[0] https://docs.mitmproxy.org/stable/overview-installation/#adv...
Just curious.
The vulnerability in question is in parts not used by mitmproxy. We looked at it when it came out, and I'd even say it's more of a bug than a security vulnerability. Again, in either case it's not used by mitmproxy.
If you later on decide you want something extra done to the sink, and the plumber says "oh, that's easy I can do that for you for free in a few weeks..." that would generally be a positive right?
But lets say you wanted it done Real Soon Now instead. Like tomorrow or the next day.
If the plumber's response was "Well, that can be done but I'll have to charge you our normal rates", that doesn't sound unreasonable does it?
That's what this situation seems like to me. I'm not sure why you're thinking there's attempted extortion involved?
> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software [...]
It's all there, black and white, clear as crystal. They knew what they were getting into when they agreed to the license of the software they use. Hell, IBM could fork the project and sell the code back to the original developer, if they wanted. If they disagree with the license, well... caveat emptor:
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
If they said, "Since you asked I want money or ill plant a backdoor to ruin you", sure thats extortion, but that didn't happen.
A similar thing happened with h2database - a "security researcher" found that if you do something you're told not to do, then bad things happen.. but they demanded and got a CVE allocated anyway. Anyone who looks at it realises it's bullshit, but the mere existence of a CVE is all that matters to these idiots.
What the h2database developer said about it: https://github.com/h2database/h2database/issues/3686#issueco...
> I struggle to understand why I should feel the slightest shred of sympathy for "major corporations" that are using a volunteer-developed open-source project. Feel free to get your corporation to pay someone to deal with this, or pay for a similar commercial library.
They may know and understand all of this and still not care. Maybe their performance is judged by how quick they can get checkboxes checked, with overzealous approvals harming them more than overzealous rejections. They may be empowered to make exceptions when the specific circumstance warrants it, but that might require them to fill out even more paperwork to justify their decision. That extra paperwork slows them down and harms the metrics by which their performance is judged.
“If you pass a password via the command line, other processes on the system could see it via ps.”
Yeah, no shit. If that qualifies as a “high severity” CVE then, uh, you can call me a security researcher because I can think of at least a half a dozen applications that allow the exact same thing with the exact same disclaimer (“don’t do this”).
https://daniel.haxx.se/blog/2023/03/06/nvd-makes-up-vulnerab...
InfoSec raises vulnerabilities that show up on reports that get managers scared.
Developers have to continually update to accomodate. Even for non-prod deps. You can raise exceptions, but that's a completely separate can of worms.
Managers wonder why dev work is slowed down.
But around the same time I’ve got an email with apology explaining that company’s boss asked employees to stir up the pot to pressure me into a fix, pretending its affecting far more people than it really did.
Calling the developer extortionate was unreasonable, but I don't think there's anything wrong with the first message.
Anyway, it's good for OSI and FSF to take a hardline stance here. If your priorities don't align with theirs, why should they change to satisfy you? Simply use the license you like, even if they don't approve of it. Why is that a problem for you? Why do you need these orgs to stamp their approval on your choice of license, when you obviously don't share their values in the first place?
I agree with you, but guess who pays the OSI's bills: https://opensource.org/sponsors/ For their corporate sponsors, not supporting usage restrictions is a feature, not a bug.
There's also a ton of dogma surrounding the open source and free software definitions where you'll get dog-piled for not conforming to these definitions. These definitions are often considered as holy writ and their adherents refuse to entertain if perhaps these definitions might need to be adjusted for the realities of 2023.
Even if you try to ignore them and coin your own terminology so as to not to conflict, open source and free software advocates will continue to try and control the narrative by insisting on their own language, which is designed to have negative connotations in their circles.
Stallman and the FSF are hardly darlings of the corporate world, but they also consider the first and most important software freedom to be: "The freedom to run the program as you wish, for any purpose (freedom 0)." This is something people in this space earnestly believe in, not something they're just being paid by corporations to espouse.
If you don't share these values, then that's your prerogative. Simply use another license and ignore people who complain about it; since they don't share your values you shouldn't care what they think.
https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
If you use it, great, if you don't want to because you are afraid of the legal issues, no problem. It's massive entitlement to think that just because you released the source code, anyone should be granted the four freedoms to essentially do whatever with it. (Which includes the SaaS loophole as well....)
I would not. Or rather, not if the "usage restrictions" were outwith the varying strengths of share-alike enforcement provided by the LGPL, GPL, AGPL.
Freedom for users to run software for any purpose is freedom 0, and Stallman sets out very eloquently why usage restrictions would not help: https://www.gnu.org/philosophy/programs-must-not-limit-freed...
As per the warranty disclaimer, free software is given to you with no strings attached. It is boorish to demand free support and maintenance as well, when you've already been gifted the freedom to make any amendments you see fit. I don't think changing the license would make such boorish people go away.
And there may be non-license options that are friendlier to open source than corporate. E.g. if someone has a non-trivial issue they must publish a reproducer.
Dead Comment
Dead Comment
> As per the mitmproxy license, the software is provided as-is without warranty, and project maintainers are currently constrained by other priorities and deliverables.
> As such, statements on the Github issue tracker are not considered as sufficient justification for the prioritization of issues. The only way to prioritize issues would be to enter a support contract, available [here], the terms of which we will be happy to discuss further.