CRA open source exemption: when free WordPress plugins are still in scope

What the regulation actually says

Recital 18 of the CRA states that free and open source software “developed or supplied outside the course of a commercial activity” should not fall under the regulation. The key phrase is outside the course of a commercial activity. The exemption is not about your licence (GPL, MIT, Apache). It is not about your price tag. It is about whether commercial activity is involved anywhere in the supply chain around your software.

The regulation goes on to clarify what commercial activity means in this context. The mere fact that software is hosted on an open repository or distributed for free does not make it non-commercial. What matters is whether the development or distribution is connected to any form of commercial intent.

For WordPress developers, this distinction is everything. WordPress itself is GPL. Every plugin in the WordPress.org directory is GPL. But GPL licensing does not trigger the exemption. Commercial intent does.

What counts as commercial activity

The CRA and its recitals give several signals that push a product into “commercial” territory:

• Charging money for the software. This is the obvious one. If you sell a premium version, a pro add-on, or charge for licences, you are in scope. No ambiguity.
• Charging for support services. You offer a free plugin but charge for priority support, custom development, or installation services? That is commercial activity tied to the product.
• Monetising through advertising.Your free plugin displays ads or your plugin’s website generates ad revenue? That connects commercial intent to the software.
• Accepting donations beyond operational costs. This one surprises people. More on it below.
• Developing the software as part of a business.If a company maintains the plugin as part of its product offering, even if the plugin itself is free, the company’s commercial context pulls it into scope.
• Processing personal data for commercial purposes. A free plugin that collects user data and monetises it (analytics, tracking, data brokering) is commercial.

The test is not “does the user pay for the plugin?” The test is “is there commercial activity connected to the development or supply of this software?”

WordPress-specific scenarios

Let us walk through real situations WordPress developers face and how the exemption applies. These are based on our reading of the regulation and published guidance from the EU Commission, OpenSSF, and legal analyses. They are not legal advice.

Free plugin with a premium tier (freemium)

In scope. No question. The premium tier is commercial activity. The fact that the free version is on WordPress.org under GPL does not change this. The free version and the premium version are the same product with different feature levels. Both are in scope.

Free plugin maintained by a company

In scope.If Acme Inc builds a free plugin as part of its business operations (to drive traffic, build brand awareness, support its paid products, or attract clients), the plugin is developed in the course of a commercial activity. The company’s commercial context applies to the software.

Free plugin by a solo developer with no monetisation

Likely exempt, if genuinely non-commercial. No ads, no donations exceeding costs, no premium tier, no paid support, no company behind it. A hobby project built and maintained purely for the community. This is the narrow window where the exemption works.

Free plugin that shows affiliate links

In scope. Affiliate revenue is commercial activity. Your plugin recommends hosting providers and earns a commission? That connects the plugin to a revenue stream.

Free plugin that recommends your own paid products

In scope. If your free plugin exists to funnel users toward your paid theme, your agency services, or your SaaS product, that is commercial intent baked into the software.

Free plugin with a “Buy me a coffee” link

Grey area. See the donations section below.

Free plugin sponsored by a company (but developed by volunteers)

Likely in scope.If a company is funding the development, the development is happening within a commercial context, even if the developers themselves are volunteers. The sponsor’s commercial intent flows through to the product.

Plugin developed for a client, then released as open source

In scope. The original development was a paid engagement. The product was created in the course of commercial activity. Releasing it on WordPress.org afterward does not retroactively remove it from scope.

The donations question

This is where the regulation gets into genuinely tricky territory. Recital 18 says that accepting donations “without the intention of making a profit” does not automatically make something commercial. But it adds a qualifier: donations should not exceed the costs associated with designing, developing, and providing the software.

In plain terms:

• Donations that cover server costs, domain fees, and development tools? Probably fine. These are operational costs.
• Donations that exceed what you spend on the project? That starts looking like profit, which looks like commercial activity.
• A GitHub Sponsors page where you earn $500/month for a plugin that costs $20/month to host? That $480 surplus is hard to classify as non-commercial.

The regulation does not define a specific threshold. There is no “under EUR 5,000 you are safe” line. It is a judgment call, and until enforcement guidance is published or case law establishes precedents, the answer is: it depends.

Our practical advice: if you accept donations and want to stay exempt, keep clear records of your project expenses and donation income. If donations consistently exceed costs, treat yourself as in scope.

The open source steward role

The CRA introduces a new concept: the “open source software steward.” This applies to legal entities (foundations, companies, non-profits) that systematically provide support for the development of open source products with digital elements intended for commercial use.

Think of organisations like the WordPress Foundation, the Apache Software Foundation, or the Linux Foundation. They do not manufacture products, but they support products that end up in commercial use.

Stewards have lighter obligations than manufacturers. They need a cybersecurity policy, cooperate with market surveillance authorities, and report actively exploited vulnerabilities. But they do not need to do conformity assessments, produce declarations of conformity, or meet all the essential requirements in Annex I.

For most individual WordPress plugin developers, the steward category is not relevant. It applies to organisations, not solo developers. But if you contribute to a plugin maintained by a foundation or corporate sponsor, the steward obligations may apply to that entity.

What if you genuinely are exempt

If your plugin truly is non-commercial open source (no revenue, no company, no donations beyond costs), the CRA does not apply to you as a manufacturer. You do not need to file ENISA reports, produce an SBOM, or write a Declaration of Conformity.

But consider two things:

1. Your status can change. The moment you add a premium tier, accept sponsorship, or start earning enough from donations, you cross the line. Having compliance processes ready before you monetise is far easier than retrofitting them under time pressure.
2. Good security practices help everyone. A vulnerability disclosure policy, an SBOM, and a security.txt file are useful regardless of whether the CRA mandates them. They make your plugin more trustworthy, more maintainable, and more attractive to contributors.

The grey areas nobody can answer yet

The CRA was adopted in 2024, but enforcement does not start until September 2026 (for reporting) and December 2027 (for full compliance). That means there is no case law, no enforcement guidance, and no precedent for many edge cases. Here are the questions we see WordPress developers asking that do not have clear answers yet:

• What about a plugin developed as a personal project that later gets acquired by a company? When does the clock start?
• If a contributor to an exempt open source plugin is employed by a company that benefits from the plugin, does that make the plugin commercial?
• What about plugins distributed through commercial marketplaces like CodeCanyon, even if the plugin itself is free?
• How does the exemption interact with the WordPress.org directory, which requires GPL but hosts plugins from both commercial and non-commercial developers?

These questions will get answered as ENISA publishes guidance and EU member states begin enforcement. For now, the safest position is: if there is any commercial activity connected to your plugin, treat yourself as in scope.

Practical advice

We talk to WordPress developers about this every week. Here is what we tell them:

1. Run the scope assessment. The “Am I in scope?” decision tree walks you through the specific factors. Five minutes, clear answer.
2. When in doubt, comply. The cost of basic compliance (checklist, documents, security.txt) is a few hours of work. The cost of non-compliance is up to EUR 15 million. The risk calculation is not close.
3. Document your status. If you believe you are exempt, write down why. Record that your plugin has no commercial ties, no donations exceeding costs, and no corporate backing. If a market surveillance authority asks, you want a paper trail.
4. Watch for scope creep.Many plugins start as passion projects and gradually become commercial. A “Buy me a coffee” link turns into a Patreon, turns into a premium tier. Each step moves you closer to scope. Plan for it.
5. Start with the free tools.CRA Guard’s free tier includes the scope wizard, compliance checklist, document templates, and security.txt generator. That covers the basics whether you are in scope today or might be tomorrow.

Check your scope in two minutes

Not sure if the CRA applies to your plugin? CRA Guard includes a built-in scope wizard that walks you through the commercial activity test with specific yes/no questions about your distribution model, revenue, and corporate ties.

Get Early AccessView Pricing Plans

Sources

• EU Commission: CRA and open source
• OpenSSF: CRA brief guide for OSS developers
• GitHub: What the EU's new legislation means for developers
• Cyber Resilience Act full text

Disclaimer: This article is for informational purposes and does not constitute legal advice. The CRA open source exemption described here is based on Regulation (EU) 2024/2847 and published guidance from the EU Commission and OpenSSF. Consult qualified legal counsel for advice specific to your situation.