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.)
This is what it's like at GE. Stocked with people who have been there their while life. They extrapolate what they know (GE) to the outside world and hence fail to understand almost everything impacting them. The people who come there mid-career are a distinct, and marginalized, class who don't really fit in (mostly because they aren't dillusional).
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.
I don't find it unreasonable at all, the author is under no obligation to communicate in any particular way.
If a stranger drives through my neighborhood and asks "when are you going to plant begonias? I drive through here all the time but I want to see begonias", a fine response is "if you want to pay for some begonias, I'll plant them!"
You have "begonias for everyone to view" and purchased a bigger begonia (visible to everyone but not yet planted), and a stranger asks "when are you going to plant the big begonia?".
Totally, it's not strange or entitled to ask. But it's also not strange or entitled to reply with "when I get around to it, unless you want to come help!"
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.
So not only is there not "begonias, open for everyone to view" sign in this case but there is a big sign saying "NO BEGONIAS GUARANTEED. IF YOU DON'T LIKE THE PLANTS WE CURRENTLY HAVE, THAT'S NOT OUR PROBLEM."
The maintainer could theoretically have responded a bit more gently, but if I got that response to a query on a GitHub PR, I would have thought "oops, touched a nerve" and apologized for coming off as pushy.
Maintainers are humans, and they're humans who deal with an insane amount of entitlement from unreasonable people. Their "I'm being exploited" nerves are a little oversensitive from repeated exposure, and that's understandable and forgivable.
Besides, the fact that the IBM employee followed up the way they did shows that Maximilian's "I'm being exploited" reaction was dead on—the person he was dealing with was not being reasonable. They responded to a very slight escalation in tone by throwing around dangerous words like "extortion". Would you have done that?
Obviously "apologized for coming off as pushy" would have been better, yes, but it's not just the maintainers who are human: turns out IBM engineers are also human. It's a simple question that can have a simple answer; there's no reason to not give it, really.
You don’t give planned release dates to customers as a rule of thumb for the simple reason that somebody will take it as a promise and complain when you miss the date for some reason. It’s a lesson you learn quickly.
This goes double for Open Source projects. And the person asking is a leecher like here, I definitely wouldn’t commit to date either.
> I'm assuming your response to my request for the next mitmproxy target date was a joke rather than an official project response or, worse, a thinly veiled extortion attempt. In reviewing the project's official documentation...
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.
Just FYI: in a situation where someone else is making money off other people’s unpaid labor, and then demanding they do more work for free to keep the $$$ flowing, the person doing the demanding is always the villain. I’ve been in the same situation as the requester and I did the thing any other sane, not-ridiculously-entitled developer would do: forked, patched myself, and then submitted back as a pull request.
I didn't read it as "demanding"; asking a question is not "demanding".
And to repeat: there is nothing to be patched. The fix is merely an update of a dependency, which already happened months ago. It is ONLY asking "when will you tag a new release?"
The whole interaction has to be colored by what the person eventually sent in their email. In that light, it’s very much a demand. Do this unpaid work for me. Any request for recompense is extortion.
Secondly, this is just semantics. Fork, update the dependency or whatever reference to it, and submit back as a pull request. Or maintain the forked repo yourself if it’s that mission critical.
I fully agree. The original request can be read either either with a neutral/oblivious tone or a negative demanding tone. This is the wrong way to ask someone to do free work for you regardless if it's reasonable or not, and the issue is compounded by highlighting the financial aspect.
The followup email proves that taking a negative reading of the original request is the more reasonable read of the writer's intention.
FYI, I think that as of this comment you don't understand what the maintainer was being asked to do. There is nothing in the code to fix. There is no dependency to be updated. Forking and doing whatever isn't what's needed. The person is just asking the person to tag a new release. The requester can't do this themselves.
> The person is just asking the person to tag a new release.
Just to point out, making a new release can be a fairly involved "all day" process depending on what supporting stuff needs doing. eg blog post(s), getting people to manually sign things, notifying other people, etc
Literally no idea if that's the case for this project, but it definitely is for some of the projects I'm on.
Yes for sure! And in fact the person clarified elsewhere on this thread that it would be multiple hours of work to create a new release (in which case I think they’ll asking for support is totally reasonable). But just from looking at the exchange on GitHub this is not clear.
More pointless semantics. So your claim is that there is absolutely nothing IBM can do to resolve this situation, with all their myriad resources, besides opening a GitHub issue and then using absurd, abusive language in follow-up emails? Okay.
On my GitHub repos creating a new release generally involves using GitHub’s new release UI, which only I can do because I’m the only one with permissions. If someone else wanted a new release on my repo, how can they do this without me doing it?
The original request can be judged on it's own merits. We can also, simultaneously, judge the personality of the requester with all data considered. One does not exclude the other. I judge the original request to be reasonably worded, and I also judge the guy to be an asshat in light of the subsequent email.
It's absolutely not "semantics", because the amount and type of work involved is radically different. Some bug is something I can fix myself with a patch; a new release isn't something I can do at all.
> Fork, update the dependency or whatever reference to it, and submit back as a pull request.
IT HAS ALREADY BEEN FIXED. How many times do I need to repeat this?
Indeed, the maintainer has commented on this very post that more work than simply tagging a release is involved with fixing, as well as that the CVE impact on their repo is bogus because they’re not actually affected by it.
It's not just tagging a release; the interlocutor is demanding real work, ie a full qa pass. A release means, in the real world, "we view this set of things as working, and have tested it as such. Likely including some baking in prod."
Asking about a timeline doesn't need you to mention your paying customers and government regulations. These are mentioned specifically to create a sense of urgency while being fully aware that you are relying on free labor. This wasn't someone asking an innocent question.
> 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]".
> The recommended way to install mitmproxy on Linux is to download the standalone binaries on mitmproxy.org.
> Dependencies in the binary packages are frozen on release, and can’t be updated in situ. This means that we necessarily capture any bugs or security issues that may be present. We don’t generally release new binary packages simply to update dependencies (though we may do so if we become aware of a really serious issue).
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.
Even the term "volunteer" implies too much responsibility. This is a project to which people contribute their time, for whatever personal reason motivates them. If they don't want to do a release ever again, or they don't feel like updating a dependency, or decide the purpose of the project should change in some fundamental way, too bad. This is Free Software, if you don't like what is happening in some project the only thing you are entitled to is a fork.
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?
Bad analogy. There is reasonable expectation that security related bugs will be fixed in a reasonable time. And that it won't be a premium feature. Not legally of course as it's free etc. But that's commonly how the world works.
A better analogy would be Microsoft asking for money to fix a security bug in Windows.
This, I think, is the core issue of this thread. It's totally not reasonable to expect anything from people who were kind enough to put their code on the internet for free for others to use. The requester is using the code someone gifted them to make money, and expects the other person continue volunteering their time for free so they can make more money. Moreover, there is no actual security vulnerability here.
Most Free Software projects are not professional. Time is spent on them for personal reasons. Those reasons may not align with users of that project, but that is just too bad. If you don't like it, all you are entitled to is the source code.
> A better analogy would be Microsoft asking for money to fix a security bug in Windows.
Microsoft has the exact same practice. If you want to tell Microsoft how to spend their time, you better be prepared to fork over lots of money.
Firefox is maintained by paid employees. This is not the same thing. There is no talk of making this a paid only release anywhere. Please avoid strawmen.
That’s absolutely relevant because Mozilla engineers are getting paid in the end. It’s reasonable to expect to get job done for the money. The volunteer devs are not getting paid and do their FOSS job after hours. There’s no obligations whatsoever.
Windows is a paid product, FOSS is not. Plus you not only cannot, it's also illegal to fix the security bug yourself in Windows. Meanwhile, if someone needs something changed in FOSS they are free to do it themselves (it wasn't even a change, just a stupid rubber stamp)
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.
Imagine the level of privilege required to refuse to deal with a slip of paper for $999/hr. Checks are a pain in the ass roughly equivalent to having to clip your fingernails every once in a while.
First of all, it was a joke. Second, if a job is offering me $999/hr and asks me to use cheques, something's really fucking wrong and it's a scam.
Third, "blah blah take a picture with your phone" -- y'all talk about privilege as if you ever lived outside of the US. Where I'm at, dealing with a cheque involves finding a bank that will accept them (Mine sure as hell doesn't), and opening an account there, then most likely depositing it in one of their rare remaining branches because there's no such thing as photo-deposits or w/e.
Foreign checks are admittedly a bit of a pain; I need to go to a bank branch (though not exactly a $999/hr pain). But I routinely deal with domestic checks and it's <5 minutes with my phone's bank app.
How hard could it be for you to simply take a picture with your phone? I can understand opposition to writing checks since you'd need to go track down your checkbook or even get one if you don't already have one. But cashing a check is completely trivial.
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.
> Stallman and the FSF are hardly darlings of the corporate world
I imagine the corporate world is very happy with the FSF, because they represent the most popular non-permissive licenses by a significant margin, and RMS's stewardship of the FSF in the era of GPLv3+ has been an enormous help in the rise of popularity of permissive licenses.
> This is something people in this space earnestly believe in, not something they're just being paid by corporations to espouse.
I'm not implying that its adherents are influenced by corporations, but that its adherents have seemingly taken its tenants as holy writ instead of critically re-examining them in the context of today's open source landscape.
> I'm not implying that its adherents are influenced by corporations, but that its adherents have seemingly taken its tenants as holy writ instead of critically re-examining them in the context of today's open source landscape.
You can imply that all you want but that doesn't make it true. Once you allow the terms to be muddied by usage restrictions you agree with you will quickly find them also used for software with usage restrictions that you don't agree with and soon the terms will be entirely meaningless. The point of open source licenses is that they effectively put the software into the commons (which copyright on its own fails to do) and, in with copyleft licenses, to keep derivatives in the commons as well.
Non-commercial restrictions specifically don't just afect big corporations but anyone who accepts money vaguely related to their use of the software. Accept donations? Do related work for hire? Agree to fix an issue for your friend in exchange for a beer? Accept any kind of reward or sponsorship based on your status from work using the software? Better call you lawyer first to make sure the conditions allow it. More often than not, the answer is going to be "no way to tell until you get sued".
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....)
If you don't want to grant the four basic freedoms, simply don't call your license open source. Stop trying to mooch off of the goodwill around open source software.
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.
But that restriction also makes it incompatible with other licences which means the code can't be used by other FOSS projects. And often people care more about that.
It'd be great if we had something like an LAGPL though.
Yeah, it's not compatible with the GPL or the AGPL, you are correct. However, it would be compatible with other FOSS licences as long as you abide by the added restrictions.
The fact that many people say that you can't call it "open source" if it doesn't grant the user the four OSI freedoms.... even though they don't have a trademark on the expression "open source".
I own and operate a chicken farm. I raise my chickens ethically, and I say so on my website. But I get angry emails from activists saying that it is unethical to farm chickens at all, no matter how I do it. To support their argument, they link to a PETA website saying as much. So I hatch a plan, I lobby PETA to change their espoused principles. Amazingly, PETA acquiesces and endorses my business. What happens next?
What happens next is those activists still send me hate mail, and now they also send PETA hate mail as well. The people who previously cited PETA to defend their position aren't swayed by PETA's change of policy. They were never taking marching orders from PETA in the first place. They previously liked PETA because PETA aligned with their values, but PETA no longer aligns with their values so now they've got a beef with me and PETA.
Do you see what I'm saying here? Open source / Free Software activists don't take marching orders from the OSI or FSF. We cite those organizations because those organizations align with our beliefs. Should those organizations change, our beliefs would not. The Zeroth software freedom isn't something we fight for because some organization tells us to, it's something we fight for because we believe in it. You can't change this by getting the OSI to change their website.
Terms of art are as important as company-owned trademarks for consumer protection. Don't try to deceive users about what your license is by calling it something that already has a different meaning and you won't get any complaints.
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.
Sorry, I was a bit unclear. I was talking about the fact that if you release your code as open source but want to restrict how it is used, people will brigade you and flame you for not providing the users all the OSI freedoms.
OSI doesn't have a trademark on the expression "open source"....
Words mean things. If you say open source, people are going to expect that your license is going to follow the existing expectations set by OSI.
Think about this as setting expectations. You can avoid all the controversy by saying that your software has a generous 'source-available' license. People will know they don't get all the freedoms, and that might be ok, but people won't get upset that you misled them.
Fair enough, you are entirely right. But wouldn't that draw a different complaint about "why isn't this open source then if you published the code anyway"? I don't have an example right now but I've seen several projects where it's been a huge source of controversy that they've made it source-available but didn't use any FOSS licence for it.
The Open Source Definition does not require any specific development methodology. Open Source with a private bug tracker is still Open Source.
Open Source was promoted as a pragmatic method to write better software, and public ("bazaar") development was recommended over private ("cathedral") development. But this is more a case of marketing than legal terms. The Open Source Definition was inspired by the Free Software Definition, and in practice is almost identical. Free Software is primarily about ethics, not software quality, so it has nothing to say about development methodologies. The Open Source Definition did not change this.
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.
I think a year's salary of an engineer (which is NOTHING at certain corporate scales) would make the fix happen in matter of weeks and it is only fair.
OR if you absolutely don't want to pay then other way would be to allocate one of your own engineer for few months to patch the parts you need for the paying customers and contribute upstream.
EDIT: SORRY - This one year one engineer compensation is just my own limited incorrect estimation. I am no position to say what's exactly worth in but I would estimate few months of effort for an engineer that's NOT familiar with the code base, probably.
Apparently they would just need to build a newer release, the fix is already done (but I suspect that doing so would evoke other compliance issues, which is probably why it wasn't done; obviously this isn't the open source project's problem).
His followup email linked by the OP is completely over the line, but I don't think this github post was objectionable. (Nor was the "pay me" response objectionable.)
> "Do you have a target date for the next release?"
Simply asking for such a thing isn't objectionable, he's not demanding it.
> "I'm trying to formulate our case for waiting, but need some kind of target date."
The way this is phrased, the "need" is something others are requiring of him, not something he is requiring from the mitmproxy developer. In this comment, he's making a request and explaining his commercial and personal motivation for his request. There wasn't any problem here until the guy came back with an email throwing around words like extortion.
I’m not a native speaker but the way I read it is that FrugalGuy needs some kind of target date. So FrugalGuy is asking mhils for a target date. Which is the opposite of what you’re saying.
More like "I've been subletting the appartment you have been providing to me for free and now my tenants are complaining that the company that made the paint also made lead paint. Can you please repaint all the walls even though you already checked that your building didn't use any of the lead paint so that I can continue to profit off of your house without paying you anything, kthx."
The original comment was already at the very least, absolutely tone deaf.
Edit to replies: Both the context and the employer were in the original post. Blasting the actual GitHub issue when it's clear the author specifically tried to avoid that is awful behavior too.
Just as calling the maintainer's offer extortion is not correct, I think it's also to call the email a threat is not correct. It's at worst entitled and slightly aggressive in the part that we saw.
It's pretty shocking that someone in the industry so long thinks that OSS maintainers owe him anything though, or that he didn't think to simply fork his own version - he must know this is an option. He's probably read the MIT license at some point in his career - has he never stopped to think about what to provide something 'as-is' means? His position suggests that he has the resources available to do a lot of things that were far less embarrassing than asking someone who owes him nothing to make his job easier.
I don't think the person was important but the employer might. It seems to be IBM which is not surprising I guess, although I'd hoped that RedHat would influence how they work with open source somehow.
I've just realized, if you don't want your code to be used for commercial purposes, instead of using the GPL, just claim your project has a critical risk vulnerability.
Depends on the use, but there are a lot of cybersecurity regulations that apply to regular companies and this is only getting stricter as time goes on.
It seems more interesting to discuss the implied underlying situation here than focus on any individual actor's tone.
It seems from the interaction that a part of IBM has (1) taken software that explicitly has no warranties, (2) repackaged it and sold it for profit by unilaterally adding new warranties of their own creation, and (3) attempted to redirect the burden of compliance with those warranties to the original authors (who had explicitly disclaimed any such warranties).
I've worked on many commercial products that have incorporated open source components (and respected their licenses.) I was always under the assumption that it there was a problem with the open source bits, it was MY responsibility to resolve those problems for my customers, because it was part of the product I was shipping. Full Stop.
That almost always meant getting into the code and fixing what I needed fixed and (hopefully) getting a PR accepted so it'd be in the next release. If I needed fixes from the maintainer to support my commercial product, I'd expect that I'd need to pay...something to make it a priority for them. I mean, my problems aren't their problems, right?
You are correct. Open source licenses, at least the ones I'm aware of, have no warranty clause. That said, it won't prevent people/businesses from asking/demanding a fix from the developer. It simply means the developer doesn't have to remedy the problem.
Have developers forgotten how to publish community forks to package managers? I believe the reason projects wait for releases is to allow the community to find bugs and the release to stabilize. If the community is rushing the publisher, they would be better off cutting their own beta releases, because a primary namespace semver does not magically make the changes stable.
This points to such a great communication principle, including one that HN/dang promotes -- if the point remains the same, then take out anything else, especially when it's personal or potentially inflammatory.
Now, instead of a fairly simple and straightforward issue as the current top comment points out, this has blown up between parties and on the internet because of the completely unnecessary "extortion" remark.
I think even more disheartening here would be giving a response the commenter requested and then not even getting a "thank you" in return, which happens all too often.
This is the correct response whenever a corporate OSS user shows up and reveals themselves as such. 'For corporate users, we can arrange a support contract to answer questions. For non-corporate users, support is provided via the community forum.'
It won't actually, because owning repositories doesn't automatically mean that you should be allowed to demand others' work for free without consequence, yet this is clearly how (a portion of) IBM views open-source software.
It was more than that. It tried to influence project priorities by characterizing the impact. The response stated that another way to influence priorities is to pay money. Nobody was being unreasonable. The follow-up email demonstrated low EQ.
I think it's simply a cultural difference, and the message was interpreted by the developer as "give me a date that is close to now to satisfy me" which may or may not be accurate depending on FrugalGuy's intent. But also, the idea that the devs might not care to set and be held to a date seems to be lost on the asker. They probably have not considered that this relationship is not a vendor relationship and asking for something like a date commitment is "out of bounds" for the relationship between them and the OS developers.
Lack of understanding and empathy on both sides for something that probably could have been turned into a fruitful relationship if it had been handled differently (not that it couldn't still, but that certainly doesn't seem like the direction things are going).
Context: the fix is already in a main branch, waiting for a release tag.
I wonder if it is possible to fork the repo as is, build the product/library on question and use it? What is the procedure to convince the regulator that CWE is fixed and it's okay to go on?
Is it really rude to ask an OS maintainer when they plan to release X, and explaining why they care about this topic? Emphasis on ask - not demand. The maintainer is well within his rights to ignore or refuse the request. But going on twitter to put someone on blast for "may not be the best way to introduce yourself"? I have no idea who Maximilian is, but he doesn't come across well in this exchange.
Even if you ask once and ask nicely, the question is bound to come up often enough to rate as annoying. Explaining makes matters worse, from the perspective of using another person's time and opening up the communication to misinterpretation (e.g. it may be construed as laying a guilt trip on the developer).
More and more convinced that full FOSS is not the way to go. It is a thankless job. There has to be a mixed license where it is Free until Revenue X$ and after that one has to acquire commercial license. It doesn't matter what the software is. Once you reach a certain threshold of revenue you have to pay for commercial license. Period.
Anyone wonders what their actual use case for mitmproxy for them is? For what they are using that type of software? I know infosec uses, but for what are they using it in this case.
Assuming this is Ron Craig from IBM, the bastions of funding open source projects & not winning outsourcing contracts by using FOSS software without donations.
The dev's response on Github was unhelpful. The original comment just asked for a target date for the next release. Why didn't he just tell them? And if he didn't have a release scheduled (which I believe is the case here) then he should have just said so. Instead, he gave zero context and just asked for money. I agree that the person from the original post sent a VERY rude and useless email, but it's not like it was unprovoked.
The initial message was polite and just asking a question. On the surface.
If you read between the lines, it can also sound quite entitled.
1. "Our customers..." - apparently it's part of their services or products in some way, which means they are getting paid for the mitmproxy developers work. Of they have a problem, they should ask "how can we help fix it?", not "when will it be done?"
2. "...in regulated industries [...] are prohibited by regulations..." - these are clients with deep pockets, which makes point 1 sound even worse. Also implying that their clients problems should somehow be a priority for the project maintainers. If I hadn't read the reply I would have guessed from the tone that they're already sponsoring the project somehow. It sounds like a friendly but somewhat frustrated paying customer to me .
3. "...s/w with known High and Critical severity vulnerabilities" a bit of a stretch but this could be interpreted as "your software is terrible and full of unpatched vulns".
I'm not writing this to say that the IBM guy is a bad person. I'm sure he's just trying to get his job done and communication is hard. Just trying to convey how messages that are following all the "rules" (be polite, don't make demands, don't call people names, ...) can still be interpreted as rude.
The "I hope you don't find this follow-up to be offensive -- that's certainly not my intention" part of the email sounds like someone that is aware that they're sometimes unintentionally offending people.
The intent behind the response from mhils is pretty clear to me. He points out that he's not being paid, that he doesn't appreciate the message, and that you can't make any demands unless you're willing to contribute somehow.
The problem is, I think, that this type of language isn't clear to everyone. The follow-up email just shows that the message didn't get across.
I don't know the IBM guy, maybe he's just entitled, but living around several very intelligent autistic people has made me see how common these types of interactions are. I think us non-autistic people can get better at recognizing the situations and adapt our communication to be more direct and precise without a lot of effort. It's often the case that the person on the other end is already spending a lot of energy on adapting.
Not excusing anyone's behavior of course. I just think this interaction could have had a lot of other outcomes.
The original question was polite and gave his reason for asking.
The developer's response was not helpful and a bit snarky.
A better response? "No, I don't have a target date; this is X on my priority list, after my paying work. If your company is willing to contract me for support, I can prioritize the release. Email me if you'd like to do that."
Companies pay for software all the time. Just make it easy for them to do so (IIRC that was posted on HN a little bit ago) and direct folks to that if they need priority support.
Otherwise, it can appear as if the developer has a "first one's free" mentality, where the user is now dependent upon broken software and the developer wants to charge for the fix.
"But the corporate guy's e-mail was rude and aggressive!" Yes, but his original questions was not; it was mhils who first responded like a jerk.
Ah yes, because what I want to infest my personal hobby projects is all the corporate bullshit speak that I'm forced to deal with from 9-5. If IBM ever starts monetizing a project of mine, that's fine, but if they try to waste even 12 seconds of my time reading an issue, I'm pretty sure I'll respond in whatever way sparks joy.
Mhils answered happy to setup a support contract if you need timely release while pointing to his email. Nothing in his answer is out of line. I think you need to seriously reset your expectations if you think that answer from someone providing free labour is in any way wrong.
What rubs me the wrong way about the mhils Github response is that it fails to answer the question that the commenter asked: Is there or is there not a target date for the next release (and if so, what is it)? It's fine to charge money to move the date up, but it seems like if you are going to make that offer, you should try to tell the person how much time they would actually be buying.
> What rubs me the wrong way about the mhils Github response is that it fails to answer the question that the commenter asked: Is there or is there not a target date for the next release (and if so, what is it)?
Why exactly do you expect him to answer that? It’s not like he is working for the guy. He can do whatever he wants.
Reading this discussion I’m starting to understand why so many open source maintainers end up calling it quit.
Yeah, back to what my grandma would say “if you don’t have anything nice to say…”.
Either…
This is something I, as someone spending some time on a passion or hobby project, don’t want to deal with and I’ll just ignore it.
Or
It’s a business transaction and I’ll at least try and explain what services I can provide, not just “lol pay me”. “We don’t have a release schedule. Except in the case of actual critical vulnerabilities making our users vulnerable, releases are tagged when we have enough functional changes to warrant them. If you would like to get in touch to discuss a support contract and us tagging a release just for you and your customers you can contact me at X.”
Refusing to engage on the question or how you can work together and just saying “lol pay me” definitely comes across as “fuck off” to me. And if that was the intent… better to not say anything at all.
He explained it already: the requested change is purely for regulatory purposes and has no functional value. He would release once enough functional changes accumulate.
mhil's response was polite and reasonable. The :-) could possibly be interpreted as antagonistic, but in absence of other clear antagonism, I wouldn't assume it was meant that way even if it might have been. The email is where this exchange went off the rails, everything prior to the email was fine.
> Otherwise, it can appear as if the developer has a "first one's free" mentality, where the user is now dependent upon broken software and the developer wants to charge for the fix.
I would be willing to be the original “first one’s free” license came with an explicit disclaimer that the software was provided “AS IS”, without any warranty implied or explicit.
So, it seems like it would be on the company for deciding to use the software in a critical way, without having a plan for support.
I'd argue that weaponizing politeness with the explicit intent to exploit someone's free labor -- especially when you stand to gain monetary value -- is in and of itself "jerkish behavior".
I agree that the response is a bit snarky and escalates the situation. However, unpaid open-source project maintainers aren't obligated to be scrupulously polite at all times no matter what. If you want professional corporate interactions, then pay professional corporate prices.
I'm also sympathetic to not wanting to commit to a specific release schedule for an open-source free time project, with implied consequences if it isn't met.
> However, unpaid open-source project maintainers aren't obligated to be scrupulously polite at all times no matter what. If you want professional corporate interactions, then pay professional corporate prices.
It would have cost mhils nothing to be polite and the idea that "if you want polite then pay for it" justifies abusive behavior.
I've personally seen far too many co-workers state that they're paid for their technical skill rather than to be polite, or even that they're not paid _enough_ to be polite.
The maintainer didn't answer the question. But I don't think it was snarky. If you want a problem solved in an open source project you (and your financially very solvent customers) rely on the minimum would be to offer some way you can help or provide resources.
Is this some kind of next level sarcarsm that I'm not getting? The "other side" literally implied that the developers response better not have been a "thinly veiled extortion attempt". Not really sure how a developer of an open source project can extort IBM, but yknow...
I don't think his characterization of this interaction is accurate. A plain reading of is question is he was just asking when the next released was planned, and without knowing more about what their native language is, and how they normally speak, I don't think you can really read anything more into it, especially over text.
And frankly from their perspective, your response does kind of read like extortion, e.g. "shut up or pay me". The thread already indicated that this was fixed and waiting for the next release [1] so I don't see how your response is appropriate to the asking when that was planned.
I can certainly understand why this guy is frustrated as an open source maintainer, but snapping like this doesn't help anything.
From the IBM employee's perspective it should seem reasonable that if he's asking for specifics that take time to figure out and for answers to questions while not contributing anything to the project, that he should pay for those answers in a timely fashion for his benefit. He's treating the Github like a support page so I don't see anything wrong with the maintainer offering a support contract in response to that. It would be beneficial to both parties.
If the maintainer said "I'm not releasing this until you grant me a support contract", maybe that would be extortion. Until then, he's simply getting the service he pays for.
There was nothing OP could have done here. The fix was already merged. He's just asking for a tagged release. You cannot submit a PR or contribute to the project in a way to make this happen.
If you think any business will go through a multi-week procurement and contract negotiation process valued at multiple thousands of dollars just to get a release tagged on Github, I have bad news for you.
The work was already done per messages that the Twitter author/maintainer conveniently did not screenshot. The only thing they were waiting on was a release which something only the maintainer can do. Maybe it's just me, but I think it's unreasonable to be expected to paid to do the basic tasks of a project maintainer.
You do realize you're capable of maintaining internal company release right? It just costs money (to IBM), dishing out "thinly veiled demands" is free though.
The work is presumably publicly available in a branch at that point. Nothing is stopping that person from forking the repo, and bundling their own release.
They should fork the entire project and launch a competing project rather than ask for a ballpark for the next release so they can inform their stakeholders?
You seem to be incapable of understanding that it is quite possible and not at all unusual to internally carry patches to dependencies on which your commercial product is built. In this case, the patch merely involves changing two bytes[1], three if you include the pyOpenSSL bump, something a company like IBM should easily be able to do.
Which is why paid licenses have an "Enterprise license" where response times is hours or max a day. I feel all FOSS projects should stop being fully FOSS (yes even if I get hate for saying this so be it) and adopt a mixed model where it is free up until revenue X$ and then commercial. Commercial would automatically entail fast response times (including fixing bugs, tagged releases etc).
The revenue X$ can be something reasonable. Have slabs for various revenue levels starting from something decently high: million dollars and up.
The answer was completely reasonable. The commenter (IBM) required timeline and resolution for business critical reasons - the way to get that is to sponsor the work or do it yourself. The commenter should know that, and businesses know that.
Offering to do it for money when a company asks is helpful, as the option is not a given. Declining is also fine, in which case you can either wait till it happens or get a full refund.
The response was fine, in the same tone as the original request even if the first one was offensive by accident. A kind, functioning human would be puzzled at the slightly blunt response and re-evaluate the whole conversation.
They would not go to a private channel, knowing that they would get blasted for such a response in a public forum, and get even more offensive. Plus, any non-native that has an advanced enough understanding of English to use the phrase 'thinly veiled extortion' can also control the tone of their requests. No need to defend IBM here.
You can hardly say that they switched to a private channel because they knew "that they would get blasted for such a response in a public forum" when the comment they were responding to was the one that suggested the switch to email.
The comment suggested email for payment, not an extortion accusation (i know accusation is bit too much of a strong word, i couldnt find anything better)
Plus, they did get blasted just because the email was made public. To me, that shows that they wanted a more private channel.
I agree it would have been more civil to take this initially as a simple request for a schedule estimate. But regardless, how on earth is “you’ll need to pay me to work for you” extortion? Using that word is a bright red flag to me.
I don't think so. It's fair to ask for a timeline and even "slightly demand" from the author if they can speed up. (like "Can we please have this by ...). However, mentioning your clients as such (highly regulated industries) seems to me (I might be wrong) to imply a certain kind of coercion and responsibility for the author (hey look there are some very important people here using this.). It's not the responsibility of the author, and he shouldn't be stressed about it.
Your definition of extortion, withholding labour in the absence of payment, is the bedrock of our economic system. I have no idea how workers sleep at night.
Anyway, someone who maintains an open source project for free does so for his own satisfaction and is not obliged to do anything. This guy was very reasonable in suggesting the other guy pay if he wants something, given he's being paid and so is his company. Neither did he snap, since he was polite and constructive.
I often respond "shut up or pay me". It works pretty frequently for niche technical software and I land some contract work which I get to open source. The alternative of just fixing their issue never works.
So, if it sounds fun I just fix it. If it sounds boring, pay me
The original interaction is not unreasonable tbh. I have in the past have posed questions on issues of OS projects to ask about timelines. Sometimes it is important for you to know that because you have to either fix it yourself, find alternatives or wait for the fix, but with a timeline laid out for regulatory purposes. Getting offended by a question like that would be a red flag for me. I do understand the frustration of OS devs, but a polite we can’t fix it rn and we don’t know when we’d be able to, is often sufficient.
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