|
|
Log in / Subscribe / Register

Consultation strategy

Consultation strategy

Posted Jan 7, 2026 21:13 UTC (Wed) by alx.manpages (subscriber, #145117)
Parent article: European Commission issues call for evidence on open source

I'll paste the 'Consultation strategy' section, which I think is quite relevant:

 This call for evidence aims to gather feedback from different interested stakeholders,
to enrich the strategy with various perspectives.

More specifically, stakeholders are invited to reply to the following questions:

1. What are the strengths and weaknesses of the EU open-source sector? What are the
main barriers that hamper (i) adoption and maintenance of high-quality and secure
open source; and (ii) sustainable contributions to open‑source communities?

2. What is the added value of open source for the public and private sectors? Please
provide concrete examples, including the factors (such as cost, risk, lock-in, security,
innovation, among others) that are most important to assess the added value.

3. What concrete measures and actions may be taken at EU level to support the
development and growth of the EU open-source sector and contribute to the EU’s
technological sovereignty and cybersecurity agenda?

4. What technology areas should be prioritised and why?

5. In what sectors could an increased use of open source lead to increased
competitiveness and cyber resilience?

The call for evidence will remain open for four weeks and will be promoted through
the Commission’s institutional channels, including on social media. 


to post comments

This is the opportunity to write a wish list

Posted Jan 7, 2026 22:06 UTC (Wed) by hailfinger (subscriber, #76962) [Link] (43 responses)

If your favourite FOSS projects needs compute power, hosting, source code scans for security bugs, infrastructure, publicly funded developer meetings, documentation, migration scripts to help users convert from a proprietary product to your project, an awareness campaign, someone helping you navigate the legal hurdles of public procurement or anything else, write it down.

The European Commission (together with the European Parliament) can and will improve laws, and they are very willing to invest boatloads of money in anything which improves the FOSS ecosystem in general and lots of projects in particular.

- Your favourite open source project needs a high-performance buildbot service for the CI pipeline? Tell the European Commission, they could establish a free (as in freedom and in money) buildbot service for FOSS projects.
- Someone should (I know, right) finally write easy-to understand documentation for your project and all the developers are too busy? Tell the European Commission, they could establish a Technical Writer Task Force providing a free service to FOSS projects.
- The marketing of your project is non-existing or sucks badly? You solve the same thing as a proprietary piece of software, but nobody knows about your project? Tell the European Commission, they could help you get listed on one of the public "FOSS alternatives from Europe" websites curated by government agencies.
- There is a feature gap you want to close to become a viable alternative to some proprietary product and someone would have to spend half a year full-time to get that done? Tell the European Commission, they could either establish a new funding mechanism for that or direct you to one of the existing EU/national funding mechanisms.
- Maintenance of your project is lacking because all developers focus on new features instead? Tell the European Commission that having a part-time maintainer (or funding for it) would improve software quality. They could either establish a new funding mechanism for that or direct you to one of the existing EU/national funding mechanisms.

If you agree with even a single point above, use that public consultation to be heard. No, reading my text is not the same as submitting such an idea yourself. Don't delay, this is your chance to get something implemented in the whole EU instead of facing an uphill battle in every single EU member state.

This is the opportunity to write a wish list

Posted Jan 7, 2026 23:16 UTC (Wed) by cen (subscriber, #170575) [Link] (41 responses)

You are over complicating things, we just need Sovereign tech Fund and NLNET Foundation type of thing x100 to fund good projects.

This is the opportunity to write a wish list

Posted Jan 7, 2026 23:21 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (40 responses)

NLNET is not good IME.

It's goal-oriented, but most of the work we need is not goal oriented. Maintenance of projects isn't goal-oriented.

FWIW, they refused a submission from me for maintaining shadow-utils and improving its source code. The only feedback I got from them was something like "why don't you rewrite from scratch in Rust?". That's terrible. If EU wants to be serious, it needs to give money to projects without telling projects how to spend it.

This is the opportunity to write a wish list

Posted Jan 8, 2026 0:16 UTC (Thu) by josh (subscriber, #17465) [Link] (1 responses)

I think there's room for both. There's room for paying maintainers to do what they're already doing, and there's room for paying maintainers to do things they might not otherwise have done if not financially supported to do so.

This is the opportunity to write a wish list

Posted Jan 8, 2026 1:01 UTC (Thu) by alx.manpages (subscriber, #145117) [Link]

Agreed. Once vital support is guaranteed, some work might need to be incentivized.

This is the opportunity to write a wish list

Posted Jan 8, 2026 11:24 UTC (Thu) by coriordan (guest, #7544) [Link] (35 responses)

> If EU wants to be serious, it needs to give money to
> projects without telling projects how to spend it.

Kinda. But they do have to have criteria for giving money to people and there has to be a mutual agreement on how the money will be spent. They have obligations to be careful in spending tax money.

They might have made a bad decision in the case you mention, and maybe they need to learn more about dealing with free software, but we can also improve our position by learning to better deal with them.

There are consultancy firms that are expert in writing funding applications. If good free software projects give up due to frustration, then that just means more and more funding goes to specialists in writing funding applications.

This is the opportunity to write a wish list

Posted Jan 8, 2026 11:38 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (33 responses)

> Kinda. But they do have to have criteria for giving money to people

The criteria should be pay for projects that you use or intend to use. You use the linux kernel? Pay its (European) maintainers. You use GNU coreutils? Pay its (European) maintainers. Etc.

> and there has to be a mutual agreement on how the money will be spent. They have obligations to be careful in spending tax money.

Do they ask $BIGCOMPANY how it spends license money when they pay them?

It's essentially the same: you want to use some software, and you pay the people responsible for that software. In the end, the main difference is that they get to see the source code they use in the case of free software.

> There are consultancy firms that are expert in writing funding applications. If good free software projects give up due to frustration, then that just means more and more funding goes to specialists in writing funding applications.

I think that's perpetuating the problem. IMO, the solution is to fail quick and fail hard. That should show them that they're not doing the right thing.

It should be project users who do the work of paying project maintainers and making sure they're doing well.

Asking volunteers to demonstrate that they're doing a good job seems wrong; they already show by the fact that their project is working and being used.

This is the opportunity to write a wish list

Posted Jan 8, 2026 12:26 UTC (Thu) by coriordan (guest, #7544) [Link] (1 responses)

> Do they ask $BIGCOMPANY how it spends license money when they pay them?

No. But maybe they should.

They should have criteria about what they get for their money when they buy licences, and those criteria include that they want to be able to audit and adapt the software to meet their needs. I.e. it should be free software.

My point is that poor procedures around the purchase of licences doesn't necessarily imply that they should stop being picky about how they allocate grant money.

Abstaining from these grant procedures won't make the grants fail. It'll just mean we get less money for free software.

This is the opportunity to write a wish list

Posted Jan 8, 2026 12:53 UTC (Thu) by coriordan (guest, #7544) [Link]

(I just noticed that this thread started with a comment about NLnet but my replies were about EU funding. But the issues are often similar: if your application for funding gets rejected, by whoever, its usually better to look at ways to improve future applications.)

This is the opportunity to write a wish list

Posted Jan 8, 2026 13:02 UTC (Thu) by ebee_matteo (guest, #165284) [Link] (30 responses)

> Do they ask $BIGCOMPANY how it spends license money when they pay them?

Absolutely yes, they do. It might not be as direct as "I give you 100 EUR, hire 10 programmers". But they still set priorities and ask for things to be implemented, in terms of SLAs for instance. Most enterprise contracts also include fines if SLAs are not met.

I helped write public tenders. If people want money, they need to provide a certain level of service. There is no "here some money, do with it as you please, see you next year".

Even big companies like Microsoft and Apple. They are paying sums that makes them relevant customers whose requirements are taken in account. And when they don't behave like the EU wants, with taxpayer money, they enforce laws and apply fines.

This is the opportunity to write a wish list

Posted Jan 8, 2026 13:46 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (29 responses)

Of course if you contract some service you get some SLA for it.

But we're not talking about contracting services, we're talking about funding free software. The main problem in free software is (most often) not lack of features or lack of service. Companies and entities aren't donating to projects to get services from them or new features. They're donating to allow them to keep them working as they're currently working. The problem is that programmers are not paid to do what they do, and they only do it as much as they have free time to donate.

When companies want new features (e.g., kernel), they do hire programmers to implement specific features. But when companies/individuals/entities donate to some project, they just want it to survive; they don't ask for features or services or anything.

Similarly, when someone buys a basic software license, they're just paying to be able to use it. Of course, you may pay extra to get service from the provider, but that's not a basic license, and that's not what should be asked of free software projects to get grants.

Requiring the programmers to do bureaucracy is just wasting their time and energy.

> There is no "here some money, do with it as you please, see you next year".

I'll quote exactly what $SOMEFAANG said to me when they offered funding for the Linux man-pages project a couple of years ago (after <https://lwn.net/Articles/989215/>):

"I just saw your announcement on LWN. How much would you need to continue the work you've been doing?"

Just as simple as it looks.

This is *exactly* what I think should be done. If you (in this case EU) depend on a project, go to its maintainers, and ask them what they need to continue doing what they do.

This is the opportunity to write a wish list

Posted Jan 8, 2026 14:07 UTC (Thu) by euclidian (subscriber, #145308) [Link]

The issue is that the goal of buying the license isn't to keep the project healthy but to get access to the software. While you can charge for a license there is nothing stopping someone else undercutting you unless you add something extra like maintenance.

When governments (within the EU) give out grants to (for example) keep industries alive it normally comes with quiet a few strings attached and requires some feedback or proof of what it is going towards.

This is the opportunity to write a wish list

Posted Jan 8, 2026 14:24 UTC (Thu) by kleptog (subscriber, #1183) [Link] (24 responses)

> we're talking about *funding* free software.

> They're *donating* to allow them to keep them working as they're currently working.

Herein lies the problem. When buying licenses there's a contract with terms. But the language here: "funding", "donating" is all implying giving money with no strings attached. And I get it that people working on free-software would like to just receive money every month without having to justify to anyone what they are doing. I mean, that sounds like everyone's dream-job.

Getting that kind of money is really hard, looks at all the experiments in UBI. It's precarious because you're permanently getting people asking what you're doing. Your funding could be cut next year because you can't show you're producing any value.

If instead you reframe the discussion: you get money and in return you promise to patch any vulnerabilities reported to you, distribute the results and work on features by popular demand. Now you're providing a service. You're not getting funding anymore, you're getting paid to support critical infrastructure. Suddenly you're a strategically important industry for supporting digital sovereignty. People/businesses/governments can now send you money without having to fill in grant forms and justifying why you want to send 100 euro to some guy to do what they're doing already. They're now buying a service, or if you like, a CE mark.

As long as free-software depends on governments donating money we're not going to make progress.

This is the opportunity to write a wish list

Posted Jan 8, 2026 14:32 UTC (Thu) by ojeda (subscriber, #143370) [Link]

I may be missing context here, but "funding" in the general case doesn't imply giving money with no string attached, and in fact some funding in open source happens based on actual contracts, possibly with reporting requirements etc.

This is the opportunity to write a wish list

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

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.

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]

> 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.

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/ ;)

This is the opportunity to write a wish list

Posted Jan 8, 2026 21:25 UTC (Thu) by hailfinger (subscriber, #76962) [Link]

> This is *exactly* what I think should be done. If you (in this case EU) depend on a project, go to its maintainers, and ask them what they need to continue doing what they do.

That's how I'm interpreting this call from the European Commission. Except that they know that if they talk to individual maintainers, they are going to miss some crucial (but pretty much invisible) project, so they published that call instead of asking projects individually.
And given that some maintainers do read LWN, this call is already reaching some of the right people.

This is the opportunity to write a wish list

Posted Jan 9, 2026 9:43 UTC (Fri) by joib (subscriber, #8541) [Link] (1 responses)

> I'll quote exactly what $SOMEFAANG said to me when they offered funding for the Linux man-pages project a couple of years ago (after <https://lwn.net/Articles/989215/>):

> "I just saw your announcement on LWN. How much would you need to continue the work you've been doing?"

> Just as simple as it looks.

> This is *exactly* what I think should be done. If you (in this case EU) depend on a project, go to its maintainers, and ask them what they need to continue doing what they do.

I mean, ideally yes, and I'm happy it worked out this way for you. But that's not generally how the public sector, or the EU in particular, works. If you boycott their way of giving out money, they will just give the money to somebody that plays by their rules. Which might, or then might not, be particularly helpful to the FOSS cause.

This is the opportunity to write a wish list

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

> I mean, ideally yes, and I'm happy it worked out this way for you.

Thanks! :-)

> But that's not generally how the public sector, or the EU in particular, works.

> If you boycott their way of giving out money,

I'm not saying I'll boycott their way of giving out money. I'll indeed write to them and provide my point of view. Hopefully, they'll take it into account. I believe they can learn. I was stating that I don't like how NLNET is acting, but the EU might be better; we don't know yet.

> they will just give the money to somebody that plays by their rules.

However, if they ignore me, I certainly won't play by their rules. At that point, it's up to them to evaluate if what they do will benefit them or not. After all, they're the interested client looking for a provider.

> Which might, or then might not, be particularly helpful to the FOSS cause.

I believe FOSS is in a strong position. Just imagine if a non-negligible amount of maintainers decided to stop doing volunteer work for a year. The world would certainly notice.

This is the opportunity to write a wish list

Posted Jan 9, 2026 8:27 UTC (Fri) by rwmj (guest, #5474) [Link]

The trouble is even if the OP did the (unnecessary) "rewrite the project in Rust", the new code will still need maintenance after that, and who is going to provide that?

NLnet

Posted Jan 9, 2026 11:07 UTC (Fri) by Gladrim (subscriber, #45751) [Link] (1 responses)

In my experience, feedback from NLnet aims to guide you towards something they can fund given the terms of the funding they manage from the EU.

They don't want to tell you what to do, but they do push back to check that you know what you are doing, that you have considered alternatives, and to try to fit what you want to do into one of the active funds. They WANT to fund projects, but each fund has guidelines. Some funds have specific requirements from the EU, such as improving security, and perhaps they might have been able to move your project into such a fund if they had an angle such as memory safety to work with.

Of the projects I've seen fail to get funded, many have become frustrated and given up at the second round of questions.

I'd strongly encourage you to apply again. Talk to them about what you want to do. They are very flexible.

NLnet

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

I'll give them another chance. Thanks!

This is the opportunity to write a wish list

Posted Jan 9, 2026 10:36 UTC (Fri) by fermigier (guest, #12330) [Link]

I (co)wrote one last year, with 70 ideas, see my comment https://lwn.net/Articles/1053421/

Consultation strategy

Posted Jan 9, 2026 10:22 UTC (Fri) by fermigier (guest, #12330) [Link]

70 propositions from the European Alliance for Industrial Data, Edge and Cloud, written in part by yours truly (in early 2025, i.e. before the "Trump effect" was in full force) and published by the Commission in July 2025:

https://ec.europa.eu/newsroom/dae/redirection/document/11...

The document is also known as "The “Open Source Way to EU Digital Sovereignty & Competitiveness” thematic roadmap".

Here is the complete list of proposals from the roadmap, translated into English and organised by pillar.

### Pillar 1: Technological Development

- Define technical specifications as open standards for European Open Source cloud, edge and IoT environments.
- Fund interoperability pilot projects that prioritise the use of European Open Source technologies.
- Require all EU-funded digital infrastructure projects to adhere to these interoperability standards.
- Promote and enforce the implementation of open standards throughout the EU.
- Create a ‘European Open Source Sovereignty Fund’ (EOSSF) dedicated to essential projects. [NB: this would now be called the EU-STF].
- Offer targeted grants for the security, maintenance and strengthening of the sovereignty of Open Source projects.
- Foster in-depth collaboration with European academic institutions and Open Source Programme Offices (OSPOs).
- Develop a practical guide for public procurement managers to evaluate European Open Source solutions.
- Create sector-specific reference architectures based on European Open Source technologies.
- Launch large-scale demonstration projects to illustrate the practical benefits of European Open Source solutions.
- Produce and distribute comprehensive ‘playbooks’ for the deployment of European Open Source solutions.
- Implement policies to actively encourage the adoption of these reference implementations in public procurement.

### Pillar 2: Skills Development

- Organise industry-focused training workshops with a European emphasis on Open Source tools and platforms.
- Offer targeted training grants to SMEs and public sector organisations for European Open Source skills development.
- Launch certification programmes for mastery of European Open Source technologies and standards.
- Establish EU-funded retraining programmes to help professionals transition into European Open Source roles.
- Collaborate with industry partners to create hands-on learning and placement opportunities in Open Source.
- Offer financial incentives to companies that participate in retraining programmes and use European Open Source.
- Develop a European Open Source resource platform that brings together training materials, best practices, and case studies.
- Integrate European Open Source principles into STEM (Science, Technology, Engineering, and Mathematics) curricula from secondary school to university.
- Support the creation of European Open Source ‘centres of excellence’ in universities.
- Develop EU-wide coding competitions and hackathons focused on European Open Source solutions.
- Introduce training on European Open Source business models into vocational training.
- Create vocational training modules for European Open Source project management.
- Establish certification for mastery of European Open Source business skills.

### Pillar 3: Public Procurement Practices

- Launch a consultation with public sector bodies and Open Source providers to identify challenges related to public procurement.
- Make ‘Public Money, Public Code, Open Source First, European Preference’ policies mandatory in public procurement.
- Develop comprehensive guidelines for public procurement to evaluate and select European Open Source solutions.
- Fund demonstration projects showing the success of replacing proprietary systems with European Open Source.
- Establish clear criteria for defining what constitutes a ‘European’ Open Source solution.
- Provide a practical guide for public procurement managers to evaluate Open Source solutions.
- Collaborate with industry and standardisation bodies to develop accessible evaluation criteria for Open Source.
- Create a public directory of recommended European Open Source solutions.
- Encourage public sector organisations to adopt solutions developed under the Next Generation Internet (NGI) initiative.
- Launch cross-border pre-commercial procurement (PCP) projects focused on European Open Source.
- Create knowledge-sharing platforms for feedback on PCP initiatives and Open Source best practices.
- Actively involve European Open Source providers in the co-design of solutions in the PCP process.
- Publish guidelines to help public sector organisations manage and support European Open Source.
- Promote the active participation of public sector representatives in European Open Source communities.
- Support training programmes for public sector staff on project management and Open Source compliance.
- Engage stakeholders to collaboratively refine and simplify procurement practices for Open Source.

### Pillar 4: Growth and Investment

- Create a European Open Source Investment Platform (EOSIP) to centralise information on funding.
- Organise information workshops for European SMEs and start-ups on how to obtain investment.
- Establish partnerships with private investors to form a network of venture capital funds focused on European Open Source.
- Expand the Next Generation Internet (NGI) initiative with a focus on Open Source cloud, edge and IoT.
- Regularly assess the impact of funding programmes on community growth and market adoption.
- Allocate dedicated funding to high-impact European Open Source projects that meet strategic needs.
- Develop co-investment models that combine public funds with European private sector investments.
- Launch accelerators and incubators specifically designed for European Open Source technologies.
- Develop an EU-wide branding strategy to highlight the quality and sovereignty of European Open Source.
- Showcase European Open Source successes on international platforms through marketing campaigns.
- Form strategic partnerships with European industry organisations to increase project visibility.
- Establish public-private R&D consortia on European Open Source for high-priority projects.
- Offer incentives for private sector contributions to critical European Open Source initiatives.
- Develop platforms for knowledge exchange and cross-sector collaboration within the European ecosystem.

### Pillar 5: Governance

- Conduct vulnerability assessments for critical European Open Source projects.
- Collaborate with European cybersecurity agencies to develop threat models for Open Source environments.
- Publish findings and best practices from security assessments to the European ecosystem.
- Offer tailored compliance advice to help European Open Source projects navigate EU regulations.
- Facilitate accessibility to Cyber Resilience Act (CRA) certification for European Open Source projects.
- Provide resources and support for the documentation and auditing of European projects.
- Ensure stable, long-term funding for core European Open Source infrastructure.
- Establish mentoring programmes focused on developing European talent for critical projects.
- Create a European Open Source Advisory Board to oversee project funding and direction.
- Require EU-supported European projects to adhere to transparent governance and accountability practices.
- Support European community involvement in Open Source project governance.
- Facilitate community input into European Open Source policy development.
- Publish guidelines on best practices for managing the lifecycle of European Open Source projects.
- Provide resources for responsible maintenance and end-of-life support for European projects.
- Encourage comprehensive documentation and knowledge sharing within the European ecosystem.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds