This is the opportunity to write a wish list

Posted Jan 8, 2026 15:17 UTC (Thu) by paulj (subscriber, #341)
In reply to: This is the opportunity to write a wish list by kleptog
Parent article: European Commission issues call for evidence on open source

I guess open-source projects should have a commercial entity that sells licences for the software (GPL, MIT, whatever the project licence is), plus support (with a best effort SLA). Purchase orders, recurring billing, etc. This would potentially make it much much easier for people to put through a "purchase" for essential software + support via normal processes within their companies.

to post comments

This is the opportunity to write a wish list

Posted Jan 8, 2026 17:08 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

Bear in mind, it's impossible to sell a licence for FLOSS software if you're not the copyright holder or appointed representative thereof. Which means it's pretty much impossible to sell a licence full stop.

But there is nothing to stop you offering support and maintenance contracts. And as mentioned elsewhere, if a company needs a "CE for software" mark, and you're the maintainer, brilliant (if that's what you want)! Sign a maintenance contract that says "you pay me £X, and I'll take care of the legal headache".

Which basically means providing a few important documents about how you intend to handle bug reports, how you will handle security problems, etc etc. Just remember that those documents (which you wrote) now have legal binding force over you. And the company will probably say "if you're not dealing with bugs, we expect you to deal with (our) feature requests".

Cheers,
Wol

This is the opportunity to write a wish list

Posted Jan 8, 2026 17:33 UTC (Thu) by paulj (subscriber, #341) [Link]

Well, the point is the service can be minimal and equivalent to what the buyer would get just downloading it. So the contract will be "I supply you with the GPL software for you to further develop and/or deploy in your own system, and I will support it for X time including giving you the updates on a best-effort basis". (This obviously doesn't preclude having other offerings, with more meaningful SLAs).

You don't have to do much. You just have to do something minimal, and fit in with standard corporate purchasing processes.

To wit: Signing off on spending (say) €200/annum to purchase some necessary software (inc. as per above) could be something a fairly low-level manager has the authority to sign-off on within the standard processes of the company. Where "donate €200 to a Free Software developer each year" would be something not covered in those processes and require an exceptional process to be followed, that ends up on the desk of a VP or higher.

Make it easy to do within standard corporate processes, and maybe more will do it?

This is the opportunity to write a wish list

Posted Jan 8, 2026 17:36 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (19 responses)

The problem with that would be that CRA would then apply to the project in its entirety.

That's something that most programmers are probably not interested in.

In general, I think users (including the EU) should consider two separate things:

- Feeding the bees that produce software.
- Hiring companies for support.

Whether the programmers are happy to be hired for support beyond maintenance is orthogonal and secondary.

This is the opportunity to write a wish list

Posted Jan 8, 2026 18:06 UTC (Thu) by paulj (subscriber, #341) [Link] (8 responses)

The entity offering the best-effort support "make corp processes easy" thing (and whatever else) could be a separate entity from the project, couldn't it?

If there is no way to supply software on corporates on a commercial basis without becoming encumbered by the CRA (can you not have a contract that says "this is supplied on R&D terms, and CRA obligations wrt any product on the market are yours"?), I guess then dealing with those becomes part of the offering (with whatever costs you need to add).

This is the opportunity to write a wish list

Posted Jan 8, 2026 23:58 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

> can you not have a contract that says "this is supplied on R&D terms, and CRA obligations wrt any product on the market are yours"?

Of course you can! Everything is down to what the contract says! And if the contract says you work on an hourly R&D basis or whatever, and don't provide CRA guarantees, then the regulator will look at that and say to your customer "your supplier explicitly disclaims responsibility, it's down to you to sort it". If that means they have to throw money at you or get their own staff to do it, well if the contract says those are the terms then the regulator will enforce those terms!

Chances are your customer won't accept those terms, but that's down to them ...

Cheers,
Wol

This is the opportunity to write a wish list

Posted Jan 9, 2026 0:14 UTC (Fri) by alx.manpages (subscriber, #145117) [Link]

> Chances are your customer won't accept those terms, but that's down to them ...

That's the problem. I hope the EU --the customer here-- realizes that free software is essentially beekeeping. You need to make sure the bees are happy, giving them flowers and forest; in return, the bees will give you honey and even pollinate your vegetables. You can't sign a contract with them trying to regulate the amount of honey they must produce, or negotiate how many flowers you are willing to provide them. Of course, if the bees don't produce honey after some time, you may consider finding other bees; but as long as the bees do their job, one should just keep them.

Of course, the EU needs to make sure which projects it should protect, to not waste taxpayer money.

This is the opportunity to write a wish list

Posted Jan 9, 2026 14:26 UTC (Fri) by paulj (subscriber, #341) [Link]

> Of course you can! Everything is down to what the contract says! And if the contract says you work on an hourly R&D basis or whatever, and don't provide CRA guarantees, then the regulator will look at that and say to your customer

Ok, then if that's the case, and the CRA obligations can be kept devolved to your commercial customer by contractual agreement, then... that's a pretty simple option for a developer/maintainer who wants to provide a procurement-process-friendly "it's a purchase, not a donation, see" best-effort support option that doesn't entangle said dev in CRA obligations.

Perfect.

(Course, handling CRA obligations for customers may be a good way to get more customers).

This is the opportunity to write a wish list

Posted Jan 9, 2026 0:42 UTC (Fri) by raven667 (subscriber, #5198) [Link] (4 responses)

I think in some cases the CRA could provide the motivation for an ambitious developer to start a small company around their software and accept contracts with downstream companies which use their code in commercial products, accepting the liability with proper insurance as well, if the downstream companies are willing to pay. Maybe a number of developers could come together and share overhead costs. The liability of the CRA might make companies selling products chock full of FOSS more likely to open up their wallets and negotiate with _all_ the developers which make their products work, since they are going to have to put more resources into maintenance in any case.

This is the opportunity to write a wish list

Posted Jan 9, 2026 11:03 UTC (Fri) by paulj (subscriber, #341) [Link] (3 responses)

To the extent the CRA obligations are basically turning the job that good Free Software maintainers do into something that is legally required by commercial operators, it may well be a very good thing for said maintainers. Previously, commercial operators attached little to /no/ value to Free Software maintenance, and it was a thankless task and difficult to get funding for. If the CRA attaches a value to it, then that may change that situation for the better.

This is the opportunity to write a wish list

Posted Jan 9, 2026 11:21 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (2 responses)

The thing is, programmers have fun programming. They might not have so much fun doing bureaucracy. In some cases, they might, and that's fine for those. But maintainers shouldn't be discriminated because of that.

Maintainers should be funded by what they do already, which is valuable and should be paid.

If some maintainers are happy to take more work for some extra money, that's great, and more money could be paid to those. Some maintainers may also be interested in consulting about their projects for extra money.

But programmers that just want to maintain their projects should still be funded, as long as their projects are depended upon, as they're doing valuable work.

Also, consider that the bureaucracy might take time from other maintenance tasks, so you may want to have more people. Some dedicated to programming, and others that will help with the bureaucracy and other tasks.

Consider for example kernel maintainers. They usually work for companies, to implement features, which uses time that they could otherwise use to improve robustness and safety of the source code.

This is the opportunity to write a wish list

Posted Jan 9, 2026 15:21 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

As i understand it donations don't trigger obligations from the CRA, only commercial sales and contracts, so a hobbiest volunteer who isn't maintaining a software project in a commercial professional capacity should be clear of liability to whoever finds it on the internet and decides to integrate it into a commercial product. That's why I tried to be clear that this may be an opportunity for those developers who _want_ to commercialize their software maintenance activity, by prodding their downstream commercial integrator to put more value on it and maybe be willing to pay to exchange the liability. European insurance providers should research what a cyber-insurance policy should look like for a small FOSS maintainer who makes this kind of business arrangement, what's the risk and what's the liability, because an actuary can probably put some solid numbers around that, so a FOSS maintainer knows what they need to charge to continue maintenance and make their downstream whole if they make a mistake. The real-world cost of a CVE in some library is not generally infinite.

This is the opportunity to write a wish list

Posted Jan 9, 2026 16:17 UTC (Fri) by paulj (subscriber, #341) [Link]

To be honest, many (most?) Free Software projects would be at little risk from the CRA, even if they fell under its obligations. Given those obligations appear generally to be "Follow good development practices" which many Free Software projects do anyway. The most onerous obligations would be the requirements to provide security reports and updates for X years (is it 10?!!!).

There's been much discussion about the CRA here on LWN, but I'm still unclear as to exactly what the worst-case/hardest to meet obligations are, for any project that happened to be swept up in it somehow.

This is the opportunity to write a wish list

Posted Jan 8, 2026 23:53 UTC (Thu) by Wol (subscriber, #4433) [Link]

> The problem with that would be that CRA would then apply to the project in its entirety.

And?

The point is, (a) only the entity that agreed to provide the support contract would be on the hook, and (b) they would only be on the hook to the customer they signed the contract with! In other words, (a) it's opt-in, and (b) other people can't be co-opted in if they don't want to be!

If I decided to sign a contract to provide support for ScarletDME, yes the CRA would bite as far as I am concerned, but if anything happens, the regulator would go to my customer and say "Scarlet is broken, what are you going to do about it", my customer would point to the contract and say "there is my support contract", and the regulator would come after me. I'm then on the hook to provide a fix, BUT MY FELLOW PROJECT MEMBERS CANNOT BE TOUCHED. (Unless I have a formal deal with them, of course.)

As a FLOSS project, me and my fellow collaborators would be "Open Source Guardians" under the CRA, so they cannot be touched as Guardians; and because *I* signed the support contract, in my capacity as a freelance programmer, it's only *me* that has any real obligations under the law - signing the contract means I voluntarily resigned my status as a Guardian and took on the status of a commercial provider.

Cheers,
Wol

This is the opportunity to write a wish list

Posted Jan 9, 2026 13:59 UTC (Fri) by kleptog (subscriber, #1183) [Link] (8 responses)

> The problem with that would be that CRA would then apply to the project in its entirety.

That's not how it works. The CRA applies to a contract between two parties, not to a project. It's perfectly possible for someone other than the project maintainers to supply a CRA-marked version of software. In fact, if some business started selling a version of Debian Trixie with a CE-mark, I could probably convince management to pay for it. Even if it were literally standard Debian Trixie with a stamp on it. Because buying a software is a standard procurement process, donating money to a free-software project is something I've never gotten approved ever (and I've tried a few times).

Of course, I would prefer that money actually went to the Debian project (or even the maintainers) but it seems unlikely the Debian project itself is going to provide this service any time soon, so I'd want to find a middleman who promises to send some of the money to Debian (and/or the maintainers).

> - Feeding the bees that produce software.
> - Hiring companies for support.

The thing is, we don't need support for many of the open-source projects we use. What we need is an assurance it will be maintained and issues will be fixed. Simply donating doesn't give us that.

This is the opportunity to write a wish list

Posted Jan 9, 2026 14:21 UTC (Fri) by alx.manpages (subscriber, #145117) [Link] (6 responses)

> > - Feeding the bees that produce software.
> > - Hiring companies for support.
>
> The thing is, we don't need support for many of the open-source projects we use. What we need is an assurance it will be maintained and issues will be fixed. Simply donating doesn't give us that.

It is not sufficient, but it is necessary.

You could give the money with a contract that says the maintainer should do a good effort to maintain the project and fix issues. FWIW, I have such a contract at the moment with the three companies that give me money for maintaining the Linux man-pages project. That's something reasonable to ask when giving money.

But I would consider it unreasonable if the contract said I had to maintain stable branches with some conditions (maybe 5 years of support, for example). I decide what's best for the upstream project, and a contract must respect that. This falls into what I consider "support", and which must be bought separately, and possibly through a different supplier.

This is the opportunity to write a wish list

Posted Jan 9, 2026 22:44 UTC (Fri) by kleptog (subscriber, #1183) [Link] (5 responses)

> But I would consider it unreasonable if the contract said I had to maintain stable branches with some conditions (maybe 5 years of support, for example)

But that's fine. It's a negotiation, you say what you offer for what price and the buyer can take it or leave it. If you don't want to maintain a branch for 5 years then don't offer that. If I'm looking for that then I'll find someone else (or not).

The CRA is just the beginning of the process. What are maintainers willing to offer? At what price? What do businesses actually want from them? Which part do they want maintainers to do, and which parts themselves? How can we organise all this to minimise the overhead? This all needs to be worked out.

As a company we use hundreds, maybe thousands of open source packages, we can't go negotiating individual contracts for each one...

This is the opportunity to write a wish list

Posted Jan 9, 2026 23:07 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> As a company we use hundreds, maybe thousands of open source packages, we can't go negotiating individual contracts for each one...

Radio stations solved that via mechanical rights. Each time a radio station plays a song, they pay a small fee to an organization that represents the collective rights of musicians. It then redistributes the fees as royalties.

It's going to be more complicated for OpenSource, but perhaps something like this is the future.

This is the opportunity to write a wish list

Posted Jan 10, 2026 0:59 UTC (Sat) by euclidian (subscriber, #145308) [Link] (1 responses)

I do see it as a possibility of a number of open source projects pooling together so you can buy a single CRA license and it covers all the projects in the pool and all the dependencies.

For example GNU could run a pool containing all the applications / libraries under it's general banner.

This might encourage a slightly tighter control of dependencies as well. As you would have an advantage to all your dependencies being in the same pool as you.

This is the opportunity to write a wish list

Posted Jan 10, 2026 13:28 UTC (Sat) by paulj (subscriber, #341) [Link]

> This might encourage a slightly tighter control of dependencies as well.

Not sure about the social logistics of projects pooling together. However, regardless, it sounds like the CRA makes tighter control of dependencies valuable. (Which would generally be good).

This is the opportunity to write a wish list

Posted Jan 10, 2026 14:27 UTC (Sat) by kleptog (subscriber, #1183) [Link]

> Radio stations solved that via mechanical rights. Each time a radio station plays a song, they pay a small fee to an organization that represents the collective rights of musicians. It then redistributes the fees as royalties.

Except in the US notably. But yes, that is one solution, generally with some statutory basis (mainly, radio stations don't need to ask permission). It would be awesome if something similar existed for movies/series so you wouldn't need to figure out which streaming service has which movie. But I digress.

> It's going to be more complicated for OpenSource, but perhaps something like this is the future.

I don't see that happening for software though. There are simply way more businesses using many more pieces of software than the number of radio stations. And music has a clearer definition of "released" and "ownership".

But who knows, we're just at the beginning of the process, who know where this will go.

This is the opportunity to write a wish list

Posted Jan 10, 2026 15:53 UTC (Sat) by Wol (subscriber, #4433) [Link]

But! And I don't know whether it describes the way things work in America, or over here, or both, but there have been plenty of studies that show mis-reporting by people playing music is rife. "We played this music by that artist on the other channel" - except that what is reported never happened when you check up (and the agencies never check, it's far too much work). It's not deliberate, people don't make notes at the time, and memory is fallible (don't I know it!!!)

This almost always favours the big artists. Then of course, there's the collection agencies fees and expenses - which are mostly flat rate. So little artists never get a penny because their royalties don't add up big enough. On top of being gouged by mis-reporting.

So this mechanism is probably going to seriously fail that lone developer in Nebraska, which probably covers 90% of the guys doing the work and needing support, and is much more likely to benefit the big guys who - frankly - probably don't need it.

It's going to have to be something like the little guys band together and form a collective, so they can appoint a collections agent with the authority (and ability) to say "I have a team of ten programmers (each with their own project) who have banded together to jointly offer a software CE mark on their projects". The agent can then distribute the money according to how much work everybody is doing (including themself :-), and everybody is on the hook to pile in and help should a CRA vulnerability arise.

Cheers,
Wol

This is the opportunity to write a wish list

Posted Jan 9, 2026 14:22 UTC (Fri) by paulj (subscriber, #341) [Link]

You are exactly the scenario I was describing in: https://lwn.net/Articles/1053329/ ;)