Gregor "Little Detritus" Bransky – Fair Share Cost Tokens #FOSSBack

This talk presents an innovative approach to funding open source software stewards, emerging from discussions at FOSDEM. The speaker addresses the challenges of sustainable trust and financing models for open source projects within the European Union, particularly in light of the Cyber Resilience Act. This act introduces product liability concepts for software, affecting economic operators and incentivizing them to support open source projects. The speaker proposes using fair share cost tokens to facilitate micro-donations, ensuring legal accountability and transparency in resource allocation. He emphasizes the necessity for fitting incentives, legal frameworks, and the automation of donation processes to improve the financial viability of open source initiatives. Ultimately, the session aims to foster discussions on how to distribute resources effectively across the open source ecosystem while maintaining fairness and accountability.

Thank you all. So, uh today I would like to present an idea whose earliest parts and concepts were born at FOSDEM backstage 2024. Uh thanks to talks of Mirko Böhm and Shankar Kunan about the FOSDEM of life and how to who funds FOSDEM foundations. And um the idea is to put forward a way to fund open source software stewards. Even though the word token is in the

name, this is not a blockchain talk. There have been confusions about this. So, um let's start with the agenda. Um I try to lay out the problem that comes from our perspective as a civic tech organization and light note the approach. I'll look at the Cyber Resilience Act from a supply chain perspective. Look at the economic operators and the incentives they have in the ecosystem. Look what

fair share cost tokens have to do with this. And why they might eventually be a part of a future European digital ecosystem. So, the problem that FOSDEM has by wide-ranges of adoption outside of the software industry um is the question of sustainable trust. If you have a classical vendor, you can pay them. If you have a FOSDEM project, this might be maintained by either a private individual,

a private company, a industry consortium of private companies, or if you're lucky, a 501c3. So, there's currently no sustainable financing model for FOSDEM projects in the European Union that on an institutional level makes them reliable to stakeholders not involved in their governance. Um this might be considered to be a problem. Uh the approach to solve this is legal accountability because we need more lawyers. Uh especially the

idea is to give FOSDEM a legal a legal design that allows them to be held accountable to what third parties if they derivate from their mission statement um and that allows for pay-per-use micro donations. Which is fair share cost tokens. This is a very narrow question. I am happy to everybody who endured talking to me to get it that narrow. So, if you look at it from

the Cyber Resilience Act perspective, the goals of the Cyber Resilience Act are to reduce vulnerabilities in digital products, uh allow for cyber security throughout the product's life cycle, and empower users to make informed decisions. Given that the following thing is that it basically introduces the concept of product liability for all products that include software and the corresponding supply chains. More or less. at this point I have

to admit that I took the program dependency graph from Wikipedia because I would not be able to discuss a program dependency graph of any proprietary product without violating NDAs. So, in principle, you can say there's a product that's put into the market by a manufacturer. And they used the work of two open source projects to build upon. And also used uh the work of a bunch of

other manufacturers that also build on open source. And uh then there's the open source infrastructure that lies all below that, programming languages and whatnot. So, this is one of the more simple program dependence graphs. Uh what you basically want is you want security to go up. And to order to get security up, you need resources to go down. Uh the slides will be made available after the

talk. So, as we learned this morning, Deutsche Bahn uses 103,821 FOSDEM projects. As Maximilian Cornelius told us this morning in their talk getting real with the supply chain from SBOM data to action. So, if you look at that, the Cyber Resilience Act defines economic operators, which are either manufacturers that are natural legal persons that develop or manufacture products with digital elements, and they market them for payment,

monetization, or free of charge. So, there's been some discussion what this means for open source software stewards, which are natural or legal persons other than a manufacturer and also are not natural persons. That will be fixed. Systematically provide support for free and open source software and market them not for payment and not for monetization and not of free of charge but free of charge. This has been

subject to debate for a while. Uh thank you to the commission at this point for the guidance on the Cyber Resilience Act where you can find the um decision tree whether or not you're a manufacturer or motor or software steward. Uh one of the questions in there is are you a not-for-profit organization? If you say yes, you can become a steward. If you say no, you're a

Uh there's a caveat. I'm not a lawyer. And if you look at the commission's guidance, after 69, it gets a bit confusing, at least to my little theoretical physicist brain. Uh I'm not entirely sure if we have figured the rest out yet. The debate is ongoing. So, if you look at this, you basically get a for-profit {slash} commer- commercialization boundary. I have not been able to learn

to how to pronounce this word yet. You could basically take your graph and you could uh bisect it uh depending on the role of the legal entity that's supporting the code you're using. you have the happy land of regular manufacturers where you have service level agreements, licensing, and all that. And if you look at the guidance by the European Commission, you have the tools available to finance

uh open source projects, which are either contributions, membership fees, or donations. And then you have two questions arising. If you have two ecosystem, as how do you get resources across the boundary between them? And how do you get resources handled through the open source project's supply chain? there are some questions to be asked. I'll try to rush through that part. In principle, there are details to be

discussed at length. So, uh how to answer those two questions? The best practices we have is upstreaming stuff. SMEs have engineers commit to the project that they use. Corporate entities might have open source program offices where they actually have engineers on staff or somehow interact with these resources they use. I do doubt that Deutsche Bahn has 103,000 engineers that they have commit to all the open source

project they use. I'm quite certain actually that to the best of my knowledge, Deutsche Bahn does not have 100,000 uh engine- uh people who do white-collar jobs. Then there's a challenge to upstreaming. I also bet that even open source companies do not have do not upstream to every project that Uh open source projects are picky whom they want to work with. Um I assume that all of

you who've run an open source project have come subject to people who really, really want to contribute because they're seeing some deeper insight into your code that no one but them sees even though you've been maintaining this for 20 years. And even though you still refuse their merge request. And there are non-software companies who still want to use software. If they're big, they can be called Deutsche

Bahn, but also there might be small and medium enterprises that want to use software and eventually produce objects with digital elements. For example, industrial production companies. And they don't have usually engineers that are up to the task to keep up with the rapid speed of open source projects and the way that they develop it. the other question is if you want that, how do you create legal

accountability for third party uh so that the open source product is accountable for people who are not included in their governance. So, what you need, if you want to have a resource distribution mechanism, and you want to talk designing an economy or a market, you need fitting incentives for all stakeholders. So, let's take a look at the stakeholders we have. Those are, in the simple terms, the

manufacturers. And there is one sentence that really comes out in the commission guidance a lot. If the manufacturer integrates FOSDEM into its product, it needs to exercise due diligence in accordance to Article 13(5). You will read this sentence a lot if you go through all the 70 pages. As we learned from Marcus today, there is penalties and there is liabilities that happen if you don't do due

diligence. The penalty is 50 million euro or 2.5% of your total worldwide annual turnover, whichever number is higher. That is the maximum penalty you can receive. And there is liabilities that come product liability directive. The assumption for the last 2 years is that this might have been driving pouring money into open source. And the idea is to basically create an excess wall for all this risk-induced financial

pressure. FOSDEM project FOSDEM projects, according to the uh commission, are able to accept donations without the intention of making a profit. Those should not be considered a commercial activity. So, you can actually get money. People can give you money and tell you to do your thing as long as you don't plan to enrich a venture capital fund with that. So, FOSDEM projects want to be able to

get donations with as little overhead as possible. Donating platforms are explicitly mentioned in the guidance. And eventually, FOSDEM project likes transparency because they like to work with each other and they like to trust put everything out in the open because they're open people. So, the incentives in the ecosystem is the question is what is due diligence? Um there have been various discussions about what helps with due

diligence. And there is the minority opinion currently that it might be sufficient to get bio code from happy first projects uh the same way that you could bio milk from happy cows. You could use projects like the chaos metrics to measure whether or not a first project is actually a happy or if it's not. And if you can document that this might lead to easing your due

diligence having happy projects you harvest your first from. And then there's article 25. That explicitly foresees a mechanism to empower first projects to ease the burden of due diligence on the side of the manufacturers and others using their And this might become the bedrock this following concept can be built upon which is if you finance you finance easing due by getting the resources down the supply chain

what you would need is a scalable process because we're talking about open source projects being working in the spirit of open source. So, it needs to be automatable, serviceable, and fair because uh if you imagine you're running a I don't irrelevant piece of open source software like curl, we recently learned that this is used at least by 10,000 other I'm not entirely sure if that said project

has a legal department which is able to handle the contract management for 10,000 clients. I do doubt it. If we want to force open source projects to actually have contracts for that, we will get even more lawyers in open Maybe not. It needs to be efficient. There should be little overhead. We had the pleasure of learning from the artists who are in the situation that those who

are said to collect resources on their behalf to redistribute them collect up to 95% of the money collected. If you want to have scaling digital processes, maybe do it digital try to cut out the overhead. And now that it should also be effective, it should reach the people who do the work. We don't want big four to go ahead and do a dollar big four fork of

an open source project and sell that the fact that they audited it by turning into the commercial project to their clients and thus basically block the resources getting down into the open source underbelly. So, the proposal idea is that you build fair share cost tokens. Um so, basically what you did is if you have an open source software package, you include some pointer into metadata on where

to is where to get a fair share cost token which is a little piece of cryptogra of cryptographically signed information that includes a unique ID a time stamp some payment information where resources could be routed to a fair share cost indicator which will one of the finer discussions to be had about how to design a crypto key and a pointer where you one can find an announcement

channel to access privileged information. This will all make sense in a moment. And then the user can basically take their fair cost token look at the cost they're indicated to the way they want to use this thing uh and make a donation and eventually provide the token ID. Like the heart is optional. So, what you would get out of that is that you can build this in

a scalable way if you look at the standards that are currently developed in the skid working group at IETF where you basically can have rubber stamp statements created to help a supply chain security. Uh you can make this self-serviceable with GitHubs and RSS feeds and all the tools that we have to automate things on the web. And the question is how do you get that fair? Fairness

is going to be tough one. You want to get it efficient. You want to get as little overhead, so you need to establish best practices. We have been doing that with open source licenses. It's a debate we can have, we should have, and if we're not having them amongst the open source communities, someone else will be having them for us. Probably the insurance industry. I'd like us

to have our own ideas. And it should be effective and thus there two points where this might help which is you have those big question marks to solve how do you get across the boundary and how do you get down between the open source projects? So, you want donations by use. You want actually to contribute to your supply chain. And you want it to be continuable, so

you want the open source projects to hand them the resources to each other because if your open source project is one of those golden rim everybody uses me, but I'm built on a mountain of stuff projects, you might want to actually downstream to your own supply chain as an open source project. So, the win-win that you could gain for the ecosystem from implementing this is that a

problem becomes solvable with throwing money at the problem. For most open source people, this might sound ridiculous because we've been trying to push people to do OSPOs and to integrate open source knowledge into their organizations. But believe me, there will be companies out there who just will not be able to do that because either they have a completely different area of expertise like example building industrial machinery.

Or they're even a non-technical that still wants to use open source software. And I am not sure how much experience you have with web design agencies, but most of them don't have people who can do secure coding that needs to happen to close the last vulnerability in your rest implementation. Uh and also if you build it that way, you could go and get paper use and what

I would call paper due diligence coverage to to indicate what you're paying. For the first project, it allows you to get unilateral contracts. So, you don't have scaling overhead because you don't have to sign 10,000 little contracts with different people. You can basically go ahead and you can say these are our bylaws because we are a public benefit entity and you can donate to this project and

then will we use the money you donate to work on this project. And we're actually going to be bound by the tax regulation of our member state we reside in. So, you can basically make a unilateral offer the same way that most of us are used to what you would call scalable online products where you basically go to the website of some service and say, "Hey, great.

I would like to have I don't know 10 GB of data and I would like to be able to run this kind of compute to do this machine learning on the data that I get from there." Being able to self being able to do self-service has been the secret to scaling business models. And you might get in some transparency And if you want this to be a

future part for the digital ecosystem, you need a legal pathway for first projects to be recognized as public benefit entities and thus allowing to receive donations which are leading to legally binding accountability. For example, if you received a million euros to I don't know support curl it might be weird if on your billing there is 6 months vacation in the Caribbean. Don't get me wrong. All the

great free time to the people working there. But maybe spend the money that in a in a way that works well. And also this guy should get a vacation. if you somehow find a way to establish a fair pricing best practice that might be useful because otherwise otherwise other ones will find them for And this is a benefit for the cybersecurity nerds amongst us and an open

question to be had if you get basically the version of a securities.txt 2.0 because I have no idea who of you has a security.txt with your project. Okay. 1 2 3 4. Great. Uh who of you have not received a ice blob yet? So, there are people with security.txts and security at addresses out there who have not yet received ice blobs. Other projects actually have taken down

their security at email addresses because they've been drowning in ice blob. So, this would allow to create a so to speak side channel for trusted entities. So, what will you do is you would start to allow first projects to either associate or become a public benefit implement a cybersecurity strategy that might include or might not have to include voluntary attestations with a cost plan which you make

public. Uh how to do this? Uh Transparency International has made various ways how non-government organizations can actually create accountable cost plans to the public. Then the open source office stewards provide tokens with the unique ID which are time stamp the payment info the fair share cost indicator the crypto key and the pointer to an announcement channel. Then the users pay their fair cost eventually they provide the

ID. They might just be happy to say that they provided the cost indicated and show it to their insurance company. This will be up to debate. that's the cybersecurity extra kicker. Uh what could happen is that open source projects could try to tackle what's currently known as uh a problem around CVEs. As soon as a CVE is released, a special artificial intelligence agent networks are now quicker

than building the attack vectors than the people are to fix them. If an open source project would basically have a list of token IDs with a communication channel, they can blast information out before making it entirely public, this might give their users a head start. If this is a desirable practice to follow, is a discussion you can have multiple positions on for various sides. There are some

people from the critical infrastructure area who argue that if you run a critus setup, you might want to know about a CVE before it gets public in the spirit of a responsible disclosure. Um there are others who believe that open source should be open and it would be unfair to give early access to information. This will be a debate to be had. It's not going to be

an easy one. Someone's going to lose. So the open question is does the possibility of sanctions and does the Cyber Resilience Act in the absence of established due diligence and patent implementations for foss use force manufacturers to site to set aside provisions in their balance sheets? Um I have had this theory for 2 years and I had last week talks with uh insurance companies who are I

think the German word is "zurückversicherer". Those who actually insure insurance companies and they're pretty certain that this is the case. They will have to get into King's Throne on all of that because no one ever has quantified risk that comes from open source because we don't have metrics. Second question is to address liability for products with digital elements. What kind of best practices do insurance companies ask

from manufacturers to offer liability to offer liability insurance? Some of you might have heard that cyber insurances will not be around. And at this point, the question is if you want to put a product with a digital element on the market, almost every company I know that puts a tech product on the market has some insurance on it because that helps them with security, especially if they're

medium or smaller enterprises. and then the question is what do they ask for? Do they have to be voluntary attestations? Is bio is using bio code enough? We will have to see that. And we might work come up with offers. And the third one is using bio code owner from happy foss projects enough or voluntary attestations necessary? Where will be the gray lines? What will help? What

will not help? I do believe that depending on the risk that's associated with the product you're offering to the people will go like, yeah, you know, bio code is fine because, you know, you're the equivalent of a lemonade stand on the internet. Uh because I don't know, you are the local heavy metal nerds forum and this is where we post in the open when the next concert's

going to be and how got how hammered last night. Or you might want to have to be forced to people might be in agreement that voluntary attestations would be a really good idea because you're actually the management system of a hospital. Or running any other kind of digital complicated critical infrastructure. So yeah, those are the open questions I would like you to join the fray for. Uh

become an ort. Talk attestations. There's the open regulatory compliance working group with the Eclipse currently. It's really nice. Also, I would like people to join me there because so far Reggie, our mascot, has been banned to be building a body sledgehammer and I do think that orcs should be able to live in their natural habitat. Or if you prefer more peaceful discussions, you can join Avis uh

cyber resilience attestation project. Thank you. THANK YOU. THANK YOU, GREGOR. AND WE'VE GOT 5 MINUTES FOR some questions. Thank you for the presentation. Um I didn't 100% understand whether manufacturers would only get the attestation if they're paying the token. No. But okay, but um for the privileged information, it seems your proposal relies on the fact that uh open source projects can receive donations. So if you only

get the privileged information if you pay, is it then still a donation in a legal sense or are you paying for a service? Uh so that's that's that's that's a discussion to be had. Um and it's the most critical one. That's also why I left it in brackets and Um the point is that on the one hand side, the Cyber Resilience Act asks you to enforce cybersecurity

and giving heads up information in the spirit of a vulnerability disclosure to critical infrastructures might count as such. Um the question whether or not this is linked to payment or if critical infrastructures can basically go to open source projects and go like, hey guys, we use your stuff. Please tell us. Or if this will be routed through the market surveillance authorities, is a question that is, I

believe, up for debate and will be a finer nuance I would believe that for critical infrastructures, the path is that critical infrastructures are registered with the market surveillance authorities. Um there are some uh technologies for uh secure multi-party computation that might actually allow the market surveillance authorities to have a list of the S-bombs of the critical infrastructure providers without actually knowing the S-bombs because I don't want

our market a single point of failure, which is the S-bombs of all critical infrastructures in said country. I I know that some people might like to have a list of that, but I believe it should not exist because it's a really juicy target. but you could have a routing through the authorities. You could have a one-to-one routing. That's that's something that you have to work out. I

tried to get that from the Maybe maybe not. Some open foundations are better than others at getting donations at the moment. Yeah. And some of them seem to spend a lot of money on running their foundations. How do we make sure that they don't claim that they need 99% of the money as their fair share of the token? so there is some work in the guidance there,

which basically shows you limits to what's considered to be non-profit. Um there seems to be a provision in like reasonable expenses for costs before used to the non-profit cause. This will be an interesting, painful, and juicy discussion. Um because people will want to discuss whether or not they're used to your salaries or not in Europe or how this is going to run. But as with all the

questions earlier, I believe we should have the discussions amongst ourselves and not have them had for us. Because the manufacturers will want us no overhead open source foundations. And I also believe that people who do get work might actually be expensive to hire. So maybe there should be some leeway. This will be not easy. Uh Gregor, I don't have a question. Can I actually answer the last

one? Sure. the the guidance that you stopped in 69, further down it does answer this. Um yeah, so some service fees, some uh like clearly says products can charge money for services so long as all revenue goes to non-profit objectives, including reasonable cost of living expenses for not just developers, but also people who do UX, documentation, uh staff support, all of those things to run a supporting

foundation can come out of the revenue generated by the open source. Gregor, thank you.