Conversation

Notices

1. Embed this notice
   Maarten Aertsen (maarten@techpolicy.social)'s status on Wednesday, 11-Dec-2024 17:30:28 JST Maarten Aertsen

   • Felix Reda

   @senficon wrote a very accessible guide to the #CyberResilienceAct for #foss developers on the GitHub blog. I recommend it for anyone figuring out what the #CRA means for their #opensource project:
   https://github.blog/open-source/maintainers/what-the-eus-new-software-legislation-means-for-developers/

   • Embed this notice
     mmu_man (mmu_man@m.g3l.org)'s status on Thursday, 12-Dec-2024 22:17:31 JST mmu_man

     in reply to

     • Felix Reda

     @maarten @senficon but that's the thing, even they can't. because they don't have access to the documentation that describes the thing that is implemented that they use.

   • Embed this notice
     Maarten Aertsen (maarten@techpolicy.social)'s status on Thursday, 12-Dec-2024 22:17:32 JST Maarten Aertsen

     in reply to

     • mmu_man
     • Felix Reda

     @mmu_man @senficon That is/would be bad, but I’m not sure that’s a conclusion I would draw from my own mental model of how the CRA works. But perhaps things are different, let’s find out.
     That integrator, should they be involved in a commercial activity, would likely be a manufacturer, regardless of licensing if they put their product on the EU market. At that point, they would need to conform to the CRA. I don’t think that necessarily affects upstream ffmpeg.

   • Embed this notice
     mmu_man (mmu_man@m.g3l.org)'s status on Thursday, 12-Dec-2024 22:17:35 JST mmu_man

     in reply to

     • Felix Reda

     @maarten @senficon we collectively built FLOSS to free ourselves from proprietary crap, but now we'd inherit their responsibilities over their own hardware? I can't stand it.

   • Embed this notice
     mmu_man (mmu_man@m.g3l.org)'s status on Thursday, 12-Dec-2024 22:17:37 JST mmu_man

     in reply to

     • Felix Reda

     @maarten @senficon more on that specifications topic here as I don't want to repeat myself:
     https://www.haiku-os.org/blog/mmu_man/2021-10-04_ok_lenovo_we_need_to_talk/

   • Embed this notice
     mmu_man (mmu_man@m.g3l.org)'s status on Thursday, 12-Dec-2024 22:17:44 JST mmu_man

     in reply to

     • Felix Reda

     @maarten @senficon

     Same for a driver, what if it destroys the hardware because it sends bogus commands to it, but we don't know because the vendor never published the specifications (which ought to be in the use manual, as when you need to write a driver for your own OS that's how you use the hardware)?

   • Embed this notice
     Maarten Aertsen (maarten@techpolicy.social)'s status on Thursday, 12-Dec-2024 22:17:46 JST Maarten Aertsen

     in reply to

     • mmu_man
     • Felix Reda

     @mmu_man @senficon
     > How can I certify that the software I wrote follows the documentation I never had access to, or that this protocol/hardware is devoid of bugs?

     I’m not sure that that’s a claim one needs to make for the CRA, to be honest. But I would like to better understand the problem you are describing.

     Is your proposal somewhere public? I’d like to understand what bits in the CRA you believe to be in conflict with what you (or others) are trying to achieve.

   • Embed this notice
     mmu_man (mmu_man@m.g3l.org)'s status on Thursday, 12-Dec-2024 22:17:46 JST mmu_man

     in reply to

     • Felix Reda

     @maarten @senficon let's say, as an integrator you put something like… ffmpeg in a DSL box, for some real case.

     ffmpeg implements so many file formats that never had proper public documentation (and I wrote a few lines of those).

     Now, unlike a stack overflow which depends only on the code we wrote, imagine someone uses it on a file that uses a feature we don't implement correctly, and it results in data loss, or something worse. Who's to blame about that?

   • Embed this notice
     mmu_man (mmu_man@m.g3l.org)'s status on Thursday, 12-Dec-2024 22:17:47 JST mmu_man

     in reply to

     • Felix Reda

     @maarten @senficon even companies who would want to, they cannot certify something they have no clue if it works like the original.

   • Embed this notice
     mmu_man (mmu_man@m.g3l.org)'s status on Thursday, 12-Dec-2024 22:17:49 JST mmu_man

     in reply to

     • Felix Reda

     @maarten @senficon well, OK but what about all those opensource things that were written not from specs but reverse-engineering of proprietary stuff ?

     How can I certify that the software I wrote follows the documentation I never had access to, or that this protocol/hardware is devoid of bugs?

     Things like ffmpeg, VLC, drivers… how can you certify something you can't verify?

     My talk proposal to FOSDEM didn't get through but the subject remains.