Hopefully not the end

[latk]

Earlier today, commit dbeeb1e was pushed, which declared the intention to end development of croniter and to maybe unpublish it in the course of 2025. This is due to the maintainers' worries about the EU Cyber Resilience Act, which will enter into force in phases between 2026-06-11 and 2027-12-11.

Indeed, the CRA had received massive criticism when initially proposed, though subsequent lobbying by the Open Source community has reduced some of the impact. But as Felix Reda discusses on the GitHub blog, there are still many question marks about what the CRA will mean in practice, even if it does seem to exempt Open Source projects that aren't developed in the course of a commercial activity.

It is completely understandable if you, @kiorky, don't want to bother about any of this.

But it would be unnecessarily destructive to unpublish or otherwise remove a package with ~46 million monthly PyPI downloads (source). Please consider an alternative, like passing on control to another maintainer. I am not interested in doing this, but would commit to the bare minimum maintenance if the alternative is that this package enters the eternal /dev/null.

[kiorky]

Thanks for starting this discussion.

First, I recently spent lot of time documenting my self about EU CRA.
My actual and humble understanding is that as a natural person, i would not be liable for CRA specially for croniter amongst all my other numerous OSS contributions that i maintained mostly on my spare time FOR FREE and for many (10y+ for croniter, and a lot more including others) BUT
because I also used to work in IT field, boundaries were/are/will be way (too) thin to easily let me fall in the COMMERCIAL course, whatever the qualification would be (at best OSS steward, or the others), and then i will just not able to comply as a natural person.
For this same reason, accepting any donation/funding was/is/will not be possible.
And even passing the torch is very delicate, specially fearing a malicious user of doing Evil.

All my contributions including croniter were made with the fundamental OSS philosophies in mind: FREELY read/use/modify/distribute/share/educate. As most free licenses, croniter's one writes this in BOLD: """users have to take THEIR own responsibilities whenever they decided to use it""".
As in essence, CRA now undermines most of those liberties by shifting the responsibility from the user to the developer, I took this very difficult decision to retire while it is still allowed during the transition window. This has to be done as early as possible and so before the first phase in 2026, in order to demonstrate good faith. Maybe, there are other ways to circumvent it and continue my FREE VOLUNTEER maintainer role. But as I'm a tech guy, so not a Lawyer, i can't financially, nor have the time right now to deal with that, and had to find a more pragmatical solution working for me.

My current plan if it stays under my umbrella (no transfer) includes:

• Archiving soon croniter repo, and then as as-is it should not be considered to be included in any current commercial activities.
• Doing no more contribution in croniter development, nor engage in commercial activities around it (i did never anyway).
• I'm still waiting to see if any clarification pops up to attest how to deal with the compliance of already released packages before wiping OR NOT something from Pypi. Indeed, I don't know if the already released packages on pypi/dockerhub/whateverPackagesDeliverablesPlateform are liable OR NOT. And if different Packages natures would have different treatments (eg: Python code is not always binary on Pypi, VS docker images mostly contain binaries). Because, if they fall in the NOT LIABLE case, we could then keep them on Pypi arguing that croniter was marked as stopped in 2025. Plus, no further release that would then be maybe "CRA eligible" are planned to be done. Plus, it would clearly be preferable for the previous releases to stay online, because it would do more harm than good to remove them. On the contrary, and if pypi packages seems to be tied to CRA, and I do not transfer croniter in the meantime, i will have no choice than removing them from pypi.

Still the users have now been warned to promptly upgrade to another lib/fork as croniter will for now never be able to receive EU "CE Marking" label.

Please feel free to share any remarks or ideas, as I am confident that your input will help us find the best solution.

[potiuk]

I really think it's a bit too drastic of a move, but I am willing - as part of the "Airlfow Beach Cleaning" project https://airflowsummit.org/sessions/2024/security-united-collaborative-effort-on-securing-airflow-ecosystem-with-alpha-omega-psf-asf/ to help to address some of the concerns raised here by @kiorky.

I understand there is a lot of uncertainty about CRA scope and impact (mostly because it is not yet translated into actual law and standards - this is going to happen over the next 2.5 years) - but I think we can together work on making the whole ecosystem prepared better for what's coming (and I am even willing to spend quite some effort to help).

Discussing this using private channels

[kiorky]

TL;DR;: This stays AS-IS and rephrasing my previous comment but there are no changes:

• A final deadline of End of March 2025 has already been set to assess options.
• The EU Cyber Resilience Act (CRA), effective since November 2024 and enforceable from 2026, imposes heavy obligations on all Maintainers, including those of FREE SOFTWARE, FOR FREE / UNPAID, including:
  • Responding to security inquiries within 24 hours.
  • Providing fixes within 30 days.
  • CE marking (at least self-assessment with filling materials available, and continuously updating this documentation and dependencies to stay compliant).
  • At least 5 years of support for every release.
• The CRA’s penalties of up to €15M, combined with its demands for UNPAID AND INDEFINITE LIABILITY, make it untenable for me to continue maintaining this project as a natural person, regardless of my personal situation now and in the future.
• As a natural person maintaining this software voluntarily, I cannot guarantee:
  • 24/7 availability indefinitely.
  • Managing the extra workload required, especially since all of this work must legally be done FOR FREE.
  • Bearing the legal liability for others' use of this software, which was not part of its original licensing terms, moreover when this will be on ME as a natural person, with all the possible consequences on ME and my family.
• Although I have been deeply involved with free software from a very young age, both personally and professionally, I must make the PRAGMATIC decision to stop all my OSS projects, including croniter, while I still have the chance.
• Roadmap for addressing this situation:
  • Transferring responsibility to an umbrella (e.g., a company not in MY NAME or an NGO). This would require legal consultations, trust in the recipient to avoid malicious users, and significant time for legal paperwork, which I currently lack. Alternatively, options include publicly archiving the repository, or as a last resort, removing public access entirely.
  • I will cease all contributions to these volunteer projects to ensure I can no longer be considered a Maintainer.
  • Unpublishing distributed versions (PyPI, DockerHub, Ansible Galaxy, etc.) without hesitation as a last resort if the CRA’s risks remain disproportionate.
  • A key concern for me is liability for previous releases, and if I can let them online:
    • Versions released before CRA effectiveness in 2024.
    • Versions released during the transition period (2024–2026).
    • (If you have serious legal insights on this specific aspect, please share them before I proceed with removing these versions from PyPI.)

[fukami]

Not sure what makes you think that you put a product on the market under the CRA, I don't see any indicator of a manufacturer-type engagement. A project like this is clearly exempt, and that means the only thing that you may consider if you want to is Art. 15 (Voluntary Reporting), or best practices. But that's about it.

[kiorky]

Not sure what makes you think that you put a product on the market under the CRA, I don't see any indicator of a manufacturer. A project like this is clearly exempt, and that means the only thing that you may consider if you want to is Art. 15 (Voluntary Reporting), or best practices. But that's about it.

As i already said: as working in IT barrier is thin between volunteer time & work, so it can be at best seen as part of my portfolio, and even worse if found in any of my downstream projects. In any cases, it can be seen as COMMERCIAL. Check mate.

[fukami]

No, the commercial activity alone doesn't make it a product. If your code is used in a product by a manufacturer, they have to comply, not you. The CRA doesn't assign ANY obligation to you, only to the manufacturer that put the product on the market. If you don't care there is NOTHING that they can do from the viewpoint of the CRA, and there is nothing a manufacturer should ever expect from a project if not explicitly stated otherwise by it. For what you consume you are not responsible under that rule because you don't have a product, so none of the provisions apply. If you follow best practices you have already reached way more than the CRA can ever expect from you. The amount of open source projects that fall under the full scope of the CRA is very small, for the rest it's basically voluntary.

[kiorky]

1/ this regulation breaks my definition of free software (see above), and therefore the original LICENSE of croniter becomes obsolete without my consent.

2/ I work in IT, always around Free Software, and the boundaries between my personal and professional OSS contributions have always been blurred, as there was no regulation like this before.

Even if initially non-commercial, all my OSS projects, including croniter, will inevitably be tied to my portfolio (ARTICLE 22), OR either by voluntarily use (using them directly for my activities commercial or not, CRA ARTICLES 13,14,15), or involuntarily (by joining a project, commercial or not, that uses them (ARTICLE 20,21,22,23,24,25).

So with the CRA, I don’t see how I won’t be involved, whether as an OSS steward, manufacturer, or distributor (reading P28 of https://cnll.fr/media/CNLL_inno3_Guide-CRA_1.0.pdf).

3/ I can’t assume:

• ARTICLE 14: 365/24/7 availability for security inquiries (even if i have a 72h waiver instead of 24h): impossible.
• ANNEX1: Secure-by-design. How difficult would it be to handle 10-year-old projects without that constraint in their initial design...
• ARTICLE 13 & 32: Continuous updates & scanning: doable, but not for free as it is a lot of work !
• ARTICLE 13.8: 5 years of support, and 10 years of documentation maintenance: impossible, especially in AS-IS mode as stated in the license. I can’t even leave the project if I want to, for any reason, because of CRA obligations.

This Damocles sword of CRA hanging over me either as natural person, or sole trader, or Freelancer just shows that only larger structures can handle these obligations with peace of mind (ARTICLE 64).

4/ Non-risky options:

• Abandon or transfer under the umbrella of others.
• If no abandonment, and if I want to resume contributing to the same projects: salaried mission for a proxy entity where I can’t ever be linked again as a maintainer in my natural person.

5/ I still have no answer and would like to know how to handle distributed versions (for croniter: PyPI releases + CI/CD Docker images, and for other projects: old Debian packages, Docker images). Are they liable and require unpublishing for CRA compliance if published before 2024, and during the transition period (2025-2026), or only releases after 2026 will be ? For me, everything should torn down, specially what's distributed (see bold in the references at the end).
ARTICLES: 13.21, 19.5, 54 (54.[1,5])

references for the CRA articles: https://eur-lex.europa.eu/eli/reg/2024/2847

[JeffUssing]

The European Union is, of course, entitled to establish and enforce regulations as they see fit. For those affected, we invite you to consider using our fork of Croniter, available at https://github.com/USDOT-SDC/croniter, courtesy of the United States Department of Transportation.

[latk]

Kiorky, I respect that you don't want to deal with these matters, which is why I'd urge you to transfer control of the PyPI package instead of deleting it in left-pad style. (Which shouldn't be possible, but you can cause temporary damage by yanking all past releases.)

You have made up your mind about the CRA's burdens, but others might be willing to bear this risk. I assume that I'll have to navigate that subject either way, so I'd be willing to take on croniter if necessary – but someone who's more interested in cron patterns might be a better fit.

I don't want to convince you that the CRA is great all around (it isn't), but there are some relevant inaccuracies in the discussion so far:

• So with the CRA, I don’t see how I won’t be involved, whether as an OSS steward, manufacturer, or distributor (reading P28 of https://cnll.fr/media/CNLL_inno3_Guide-CRA_1.0.pdf).

  On that page 28, there's a decision tree. The critical question is whether the digital product is intended for commercial use. This is in line with the CRA's scope, which only applies to "economic operators". As I'll discuss in the following points, the CRA excludes many Open Source developers here.

  You cannot be an "OSS steward", that is a role that only legal persons (entities like corporations) can fill, whereas you're a natural person. Only the "manufacturer" or "distributor" roles could apply, but then still only if these are "economic operators".

• references: CRA: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022PC0454

  That document is not the CRA. It is a 2022 proposal for what became the CRA, and was widely criticized. The actual Act is here: https://eur-lex.europa.eu/eli/reg/2024/2847
  To illustrate the scope of relevant changes, mentions of "open-source" increased from 1 in the proposal to 57 in the final version.

  In an EU Regulation, we must distinguish between the introductory Recitals and the Articles. Articles are normative (binding), but Recitals provide explanation and serve to guide interpretation.

  Unfortunately, the CRA does not include an explicit Article that says "Open Source is out of scope if conditions xyz hold". Instead (highlights mine):

  • Article 2 "Scope" says: "This Regulation applies to products with digital elements made available on the market […]"
  • Article 3(22) defines: "‘making available on the market’ means the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge"
  • Recital 18 explains: "In relation to economic operators that fall within the scope of this Regulation, only free and open-source software made available on the market, and therefore supplied for distribution or use in the course of a commercial activity, should fall within the scope of this Regulation. […] the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity. […] In addition, the mere presence of regular releases should not in itself lead to the conclusion that a product with digital elements is supplied in the course of a commercial activity."
  • Recital 20 explains: "The sole act of hosting products with digital elements on open repositories, including through package managers or on collaboration platforms, does not in itself constitute the making available on the market of a product with digital elements."

  I interpret this to mean that my personal Open Source activities will be out of scope of the CRA, even if I publish packages that are subsequently used commercially.

• (CRA ARTICLE 16 > MANUFACTURER !), OR either by voluntarily use (using them directly for my activities commercial or not, CRA ARTICLE 11), or involuntarily (by joining a project, commercial or not, that uses them, CRA ARTICLE 14 & 15).

  You are citing articles of an outdated CRA proposal, not of the CRA as it was passed. The relevant articles are still there, but with other numbers and with some relevant changes.

  Article 16 of the proposal became Article 22 "Other cases in which obligations of manufacturers apply". However, the clause "and makes that product available on the market" was added. As discussed above, that phrase excludes many personal Open Source projects.

  The other mentioned articles do not seem that relevant (obligations of manufacturers, obligations of distributors, CE markings, vulnerability reporting requirements). They only matter iff the CRA applies.

• I work in IT, always around Free Software, and the boundaries between my personal and professional OSS contributions have always been blurred, as there was no regulation like this before.

  I agree that this is the greatest risk for people like us who maintain Open Source software, but also earn our living in the IT sector.

  Personally, I am satisfied that my own Open Source activity is sufficiently unrelated from my employment for any CRA liability to stick.

I suspect that the greatest CRA impact for projects like croniter will be the increased frequency of people that ask for extra documentation, like "do you have a conformance statement?" or "can I haz SBOM?". Similarly, I remember when someone complained that my Python code wasn't FIPS compliant because it used a non-cryptographic hash function. Such requests are annoying, but aren't the apocalypse.

[carpusherw]

Maybe a stupid question. I didn't read the CRA. Coud you simply put a disclaimer to waive the liability? Like,

This project is an open-source initiative and is provided "as-is" without any warranties or guarantees.
It does not comply with the EU Cyber Resilience Act (CRA) or any specific regulatory requirements. 

If you are using this project in a commercial product or a context where CRA compliance is required, we strongly advise against including it without conducting your own security assessments and ensuring compliance independently.
The maintainers accept no responsibility for regulatory or legal obligations arising from its use.

[kiorky]

Kiorky, I respect that you don't want to deal with these matters, which is why I'd urge you to transfer control of the PyPI package instead of deleting it in left-pad style. (Which shouldn't be possible,
You have made up your mind about the CRA's burdens, but others might be willing to bear this risk. I assume that I'll have to navigate that subject either way, so I'd be willing to take on croniter if necessary – but someone who's more interested in cron patterns might be a better fit.

As I have already mentioned, I am currently in private discussions transferring the majority of my public OSS contributions, including Croniter.
BUT if this doesn’t materialize, I will struggle to find a trustworthy candidate within the next three months, given the legal, administrative, and time constraints.
I have pressing personal obligations, and March 31, 2025, is a firm deadline for me.

but you can cause temporary damage by yanking all past releases.)

Come on, stop with this.
I'm fully aware of the potential disruption.
How could I not be after so many years in the Python ecosystem?
I’m doing everything I can to avoid it, which is why I made sure to communicate this issue clearly in the latest release disclaimer, ultimately prompting this very discussion. :)

That said, the regulations are in place, and for my part, it seems impossible to comply.
I’ve already explained why this situation is untenable for me personally (which I’ve reiterated here for clarity, though my original comments stand unchanged). Furthermore, I explicitly asked for guidance on whether there’s any way to legally keep older releases available while remaining compliant, but I have yet to receive a response.

I don't want to convince you that the CRA is great all around (it isn't), but there are some relevant inaccuracies in the discussion so far:

• So with the CRA, I don’t see how I won’t be involved, whether as an OSS steward, manufacturer, or distributor (reading P28 of https://cnll.fr/media/CNLL_inno3_Guide-CRA_1.0.pdf).
  On that page 28, there's a decision tree. The critical question is whether the digital product is intended for commercial use. This is in line with the CRA's scope, which only applies to "economic operators". As I'll discuss in the following points, the CRA excludes many Open Source developers here.
  You cannot be an "OSS steward", that is a role that only legal persons (entities like corporations) can fill, whereas you're a natural person. Only the "manufacturer" or "distributor" roles could apply, but then still only if these are "economic operators".
  [....]

Good catch, and my apologies for the misleading statement, so I heavily edited my previous comment to reflect the relevant articles that may apply to my situation.

That said, I already formed my opinion a few days ago after reading the latest regulation you mentioned (https://eur-lex.europa.eu/eli/reg/2024/2847).
Based on BOTH documents, nothing changes regarding the interpretation.
In fact, I arrived at the same conclusion for MY PARTICULAR SITUATION: I have a strong chance of being considered ENGAGED in commercial activities, and consequently, liable under CRA regulations.

• I work in IT, always around Free Software, and the boundaries between my personal and professional OSS contributions have always been blurred, as there was no regulation like this before.
  I agree that this is the greatest risk for people like us who maintain Open Source software, but also earn our living in the IT sector.²

For projects like Croniter and others, I own them directly as a NATURAL PERSON, which creates an inextricable problem.
This results in a compliance burden and associated risks that are TOTALLY UNACCEPTABLE AND UNBEARABLE for me. Whether I am salaried, freelancing, or unemployed, this issue persists until a transfer or abandonment is finalized.

Exactly, and this is the crux of the issue: my situation is inherently different due to the intertwining of my professional and personal OSS history, and the boundaries are blurred for most of the free software projects I’ve been involved with.
This is largely due to historical reasons, before this regulation, we all assumed FREE LICENSES applied, and we never questioned it.
Instead, we simply contributed FREE code.

Personally, I am satisfied that my own Open Source activity is sufficiently unrelated from my employment for any CRA liability to stick.

This is unfortunately not the case for me.

I suspect that the greatest CRA impact for projects like croniter will be the increased frequency of people that ask for extra documentation, like "do you have a conformance statement?" or "can I haz SBOM?". Similarly, I remember when someone complained that my Python code wasn't FIPS compliant because it used a non-cryptographic hash function. Such requests are annoying, but aren't the apocalypse.

CRA, and by extension, these requests, were never part of the original LICENSE or the expectations when Croniter was first published.
They fundamentally contradict the principles under which the project was originally shared.
Addressing them would create an ongoing and unacceptable workload, especially given that this regulation could evolve (or one another added), and further increase the burden.

So, I’m drawing the line here. With the new regulation changing the rules, I maintain that I can't and won't comply as long as I still have the right to make this choice.

My former comment still apply : #144 (comment) .

[kiorky]

Maybe a stupid question. I didn't read the CRA.

Part of the problem :)

Coud you simply put a disclaimer to waive the liability?

I would'nt ever take such a strong decision if a disclaimer would circumvent such a restrictive regulation.
This is why the only thing i can do i think at the moment (i am not even sure of that), is to let the repo ARCHIVED and ABANDONED online with the disclaimer added in the latest release.