I'm aware of the Patch Rewards program. The problem is that you have to complete the work first and then hope that you'll be rewarded. They also had a Security Subsidies program with upfront payments but this was discontinued in December 2024.
Github's program is restricted to Github repos, making it useless for many projects.
It's usually the more user-facing products that can thrive on this freemium model (probably full web apps or a lot of code). For example, laravel might get a lot of funding from this.
However, the underlying infrastructure libraries, will not get any funding from this, even though they have much more users. For example, libxml2, xzutils, http parser ...
You can't build any product off of an infrastructure library, purchasing support doesn't make sense, and there are little bonus features to be made.
One way to remedy this, is to have well funded open source projects take ownership of its dependencies.
> Companies say "This my code when I need it, and it's your code when it breaks", and developers read the fine print very late, because they thought exposure is valuable.
I think that this is an accurate description of working relationship. But, the fine print (MIT license) explicitly says that the companies are responsible:
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED
That line allows shifting the blame upstream without any friction.
Exhibit A: Company X uses library Y by Mr. Z., which is used by another 100 or so companies. Mr. Z. is happy because he's quasi-famous because of all the exposure. A bug has been found in Y by users of Company X, which is not interested in fixing it.
- Users: Hey Company X, this feature provided by libY is broken.
- Company X: This makes us lose money, but it's complicated. Tell Mr. Z.
- Mr. Z: There's no warranty whatsoever.
- Company X: You either fix it, or we spread the word that you're irresponsible and everyone will inevitably migrate to libW.
- Mr. Z: OK. Lemme look at that.
Mr Z. drops everything, fixes problem, maybe gets a Thanks!, and might feel better. Company X and other hundred gets free labor for their problems, and one person burns out.
Why? Because nobody tried to understand how GPL works, and companies said MIT or no cookie points anyway.
So, another developer is bought with hope vapor. He gets nothing in the end, while the company is printing money in two ways by not buying an expensive library and selling its capabilities.
I don't claim to have first-hand experience, that was just a suggestion. But there is a recent study on how maintainers respond to bug bounties here: https://arxiv.org/abs/2409.07670 .
The title of the linked HN story is "Microsoft offered FFmpeg small one-time payment instead of support contract".
So FFmpeg said that they need a contract for that, and they have given a couple thousand dollars as a one-time contribution.
I mean, "a few thousand dollars" for something underpinning Teams, is unacceptable. They probably charge 10x much for a small client for their yearly license.
My point is if that FFmpeg, tried to raise more awareness of the issue, say talk to news outlets, they could get much more funding from MSFT.
Furthermore, big companies like Google, Microsoft care a lot about security. So they could raise money for security engineering like fixing memory corruption issues.
Of course, FFmpeg could complain Google, Microsft doesn't care about all the
high severity vulnerabilities in FFmpeg.
That would be much more of an eye catcher.
Please see what Daniel has shared today. Link is in the comment you replied to.
Open Source software became so common that the tragedy of the commons applies to it. IOW, there'll be always someone who will accept exposure as a valid form of payment either being very rich or being desperate or not caring.
I did read that link before commenting, and there's nothing in there about users damaging Daniel's reputation after he declines to do free work for them?
> there'll be always someone who will accept exposure as a valid form of payment either being very rich or being desperate or not caring
Why is this, especially in the cases of being rich or not caring about compensation, a problem? I have done a lot of Open Source work for free, and a lot of Open Source work while paid by companies, and I don't feel like I've been exploited or otherwise mistreated in either case.
It's not a problem, it's just a fact. I personally don't care about the compensation either, but not everyone is motivated the same about developing software.
On the other hand, I believe requesting somebody's time for free is unethical, esp. if you are a company and wanting something from other parties at a certain quality at a certain time.
Somebody using your code and getting business done with it might not feel exploitative, and it might be true for you, and me. However, if they demand support from you, in X hours, at Y quality, and expecting you to "stop, drop and roll" for them, now that's exploitative. This is what I'm trying to say.
Many young people, who happened to write good code and their good code picked up by corporations are exploited like that. Not all of them know the better or have the gravitas to tell "go fix yourself", and this allows exploitation to continue.
I'm very grateful for people who write this code to enable this massive and wonderful ecosystem. I try to help them by filing high quality bug reports, submitting patches if I can and monetarily support a couple of them. I'm not against open source, but prefer Free Software more, because it's fairer towards the developers and the users. I don't like companies running away with someone's effort and come back and low-key threaten for free work.
Also, again talking about Microsoft, there's the WinGet/AppGet saga, which is ugly in its own right.
> Not all of them know the better or have the gravitas to tell "go fix yourself", and this allows exploitation to continue.
Agreed there, but then this is what I think we should be arguing for. Not "companies are wrong to use software without paying" but "companies are wrong to demand work from (and especially to make threats to) volunteers" and "volunteer maintainers should be well supported by the community (and anticipate such) when they decline to extend software".
> Agreed there, but then this is what I think we should be arguing for.
I mean, the original comment (by me) you replied to is intended to portray a scenario where the company threatens the developer for not fixing a bug which affects the company in short notice, for free.
Possibly I read more into your comment than you were trying to say, but I interpreted you as saying "and so we should shame companies for not paying" as opposed to "and so we should shame companies for threatening"?
You dove a little deeper than I intended. In short:
- Companies use Free or Open Source Software: That's great.
- Companies give feedback (bug reports, RFCs, developer time etc.) to said projects: That's awesome.
- Companies wait for the developer and have no hard feelings when their requests are done for free, or rejected because it doesn't fit developer's vision: That's the way it should be.
- Companies pressure/threaten developer for features, timeline, requests and expect the developer to do as they say for free: Hell no!.
If they see eye to eye and let the developer be, it can be done for free. If they try to treat said developer as their employer who works for internet cookie points, now we have a problem.
The GPL can't solve the FOSS funding situation, its relatively easy to comply with, and still not send any money (nor code) back upstream to maintainers.
As our resident GPL expert, you're right, but the reality differs a bit, with all the respect.
Companies doesn't like GPL because it mandates them to show hang their laundry outside. In turn, this creates a code quality pressure which companies doesn't want to pay for. Also, this visibility creates another, more psychological pressure on companies by exposing the external stuff they are using.
As a result, companies become more vulnerable to external pressure since somebody can point out what they are using without supporting and calling them out on it.
This can potentially send more money to developers, but this will not create value for the shareholders. Because having another yacht is more important than a pesky person's mental health and living conditions.
The GPL doesn't mandate public disclosure of code, just offering code to your users, who probably won't even know what source code is, let alone download it, tell anyone about it, modify it or redistribute it.
The EU CRA law is going to start creating the code quality pressure you mention too, with financial and other penalties. So they will have to do the right thing eventually. Hopefully that will make the GPL more acceptable to them.
The external pressure thing applies to the permissive licenses too, since companies have to provide attribution as part of the MIT/BSD/etc licenses, usually by having copies of their copyright notices in the system settings of their devices, for example curl is permissively licenced, all the car companies use it, none of them sponsor curl, and curl is now complaining about that. Of course, its extremely unlikely any of those companies care. The CRA might make them care though.
> The GPL doesn't mandate public disclosure of code, just offering code to your users...
That's the theory, and it's correct. We have discussed this with you before. However, a SaaS running AGPL code has to put it "out there", or mail to any user as soon as they register, so in this case it's moot.
Considering many GPL software is also distributed over the net, the code has to be "out there", again, in practice. Unless you are RedHat and selling the GPL software in question, which is perfectly fine.
> The external pressure thing applies to the permissive licenses too,...
Finding the copyright notices buried at the bottom of a text with the length of a Hollywood movie end-credits roll which is in turn buried 5 levels of menus is practically impossible if you don't try it. I can argue that GPL's condition is "in your face" when compared to permissive licenses.
Also, who will dig and find that I have used a specific library if I conveniently forgot to add its copyright line to this already long wall of text? "What will they do? Sue me from their mother's basement?" the companies think 99% of the time.
busybox has a tool to detect their inclusion in an embedded image, but that's GPL to begin with.
The GPL and BSD notices are usually in the same place, in the Settings -> About -> Legal notices dialog or similar.
> Also, who will dig and find that I have used a specific library if I conveniently forgot to add its copyright line to this already long wall of text?
People will still find out. The router I have violates both the BSD license, and the GPL. It simply has no copyright notices at all. The only indication it violates both is the web server 404 page links to the micro_httpd homepage, and the network filesystem feature uses the word samba. Thats probably more common than deliberately incomplete copyright notices. Even more common is wilful deliberate GPL violations.
More realistically, users are going to say "Hey Company X, this feature is broken." They won't know or care about libY. I would have replied with "There's no warranty whatsoever. Please submit a bug report and we will prioritize it accordingly. We do accept pull requests."
The bug might have low impact in most cases but doesn't work with how Company X is using libY, so it might not get fixed for a while. If this is hurting them, they can fix it themselves and submit a PR. Or they can work with them to prioritize their bug, which puts them on the other foot. If it's a huge problem that affects half the web, then Mr. Z will be working on it anyway.
If I were Mr. Z, I would know the problems Company X will have replacing libY with libW, and wish them the best of luck if they bring it up. No one's paying me, if they want to use something else, good riddance. Especially if they are threatening me. But I get it, people are different.
I'm sorry, but what kind of fantasy is this? Here's how it works in reality:
- Customers: Hey Company X, this feature provided by libY is broken.
- Company X: This makes us lose money, but it's complicated. Tell Mr. Z.
- Customers: We don't care who Mr. Z is or who is responsible. If your company does not fix the problem we are going to fucking murder you.
No paying customer will ever accept that a company tries to shift the blame to somebody else. So Mr. Z is free to ignore anything that company asks from him, reputation intact.
This I would strongly dispute. I’ve seen it first hand many times that developers who ignore such things are definitely finding the negative consequences of it. It takes very careful maneuvering not to get burned, either by reputation damage or to burn out.
So your "reputation" among a bunch of parasites takes a hit? Who cares about what they think? They're not giving you any money anyway. They're just using you.
It's like if a group of bums in the park think I'm a cool guy because I give them cigarettes when they ask. Great. And if I stop giving them free cigarettes then they say amongst themselves "man, that guy is a real jerk". Ok, should I care about what a bunch of free loading bums think?
Of course I understand that I will be down voted for this. Because people who love being victimized hates when people point out that they're being taken advantage of.
While you might see them as parasites, their community reputation may be very different. To fit into your scenario, you may need to get work from the other bums.
If people demand that you work for free for their monetary benefit and badmouth you if you don't, then that's not a "community". Those are people you want nothing to do with. Most businesses understand that they have to pay for every benefit or service they get from third parties.
I agree that open source infrastructure needs to be funded. I think first there needs to be a mindset shift in who's responsible for open source.
Currently when new vulnerabilities pop up (i.e. xz-utils compromise, log4j shell), people are quick to blame the maintainers for it. Why shouldn't companies instead be responsible for these vulnerabilities?
Currently, companies treat open source code as someone else's, so they don't bother to audit, maintain it, or fund it.
Clearly, this is wrong, and reflected in the oss license, which states that code is solely consumer's responsibility.
> Currently when new vulnerabilities pop up (i.e. xz-utils compromise, log4j shell), people are quick to blame the maintainers for it. Why shouldn't companies instead be responsible for these vulnerabilities?
They are. I've never seen a single example of a company that was able to dodge legal liability for something bad that happened as a result of an open-source software package that they used.
The problem is that software companies generally aren't liable for anything that happens as a result of their software. If you store the code to a safe with $100k in OneDrive and Microsoft deletes that file by accident, they have zero legal liability - regardless of whether the fault was in Microsoft's proprietary code or some open-source library that they use.
That's the more fundamental problem that needs to be addressed first - that tech companies have extremely few responsibilities to their users, in a way that's unlike most other industries that have come before.
What are the penalties? Will they crack down on the buggy WiFi routers which often times have open source software that they never maintain?
Also I see this as a benefit for the major commercial Linux Distribution like Red Hat, Ubuntu and maybe SuSe because small companies can't provide that level of assurance.
"Failure to comply with vulnerability reporting, cyber incident reporting, or essential cybersecurity requirements could trigger administrative fines of up to €15 million or 2.5% of global turnover. Other obligations include €10 million or 2% of global turnover."
Apart from fines, "Beyond financial penalties, non-compliant products may also be prohibited or restricted from being made available on the EU market, or authorities may order their withdrawal or recall. This can lead to significant reputational damage and loss of market access."
There is more to it than just reporting, "essential cybersecurity requirements" presumably would include fixing issues, hardening to reduce impact of issues etc.
sure. But companies believe that open source developers owe everything to the them (i.e. fixing bugs, contributing to feature requests, critical security releases ...).
For me, I don't think that the application is public exposed is really the problem (i.e. not in intranet).
I think the real problem is that these applications (Entra ID) are multi-tenant, rather than a dedicated single-tenant instance.
Here, we have critical identity information that is being stored and shared in the same database with other tenants (malicious attackers). This makes multi-tenancy violations common.
Even if Entra ID had a robust mechanism to perform tenancy checks i.e. object belongs to some tenant, there are still vulnerabilities.
For example, as you saw in the blog post, multi-tenant requests (requests that span >= 2 tenants), are fundamentally difficult to authorize. A single mistake, can lead to complete compromise.
Compare this to a single tenant app. First, the attacker would need to be authenticated as an user within your tenant. This makes pre-auth attacks more difficult.
The problem of trying to ensure that each parser behaves the same for all input is twofold:
- JSON and XML specifications are complex, lots of quirks. So not feasible.
- Does not solve the fundamental issue of the processing layer not using the same data that is verified in the verification layer.
Note: the processing layer parses the original input bytes, while the verification layer verifies a struct that is parsed using another parser.
The patches need to fix a systemtic design flaw (which seems like you are trying to do).
You are eligible even if you are a contributor:
> Q: I'm a core developer working on one of the in-scope projects. Do my own patches qualify?
> A: They most certainly do.
Additionally, github has: https://resources.github.com/github-secure-open-source-fund/
Companies have changed after seeing the log4j incident and are open to funding open source security (but we still need more)