4 ms·

> it will open up a path for devs to get paid for the extra burden. The thing is, being paid for an extra burden doesn't make it any less of an imposition on d

by jauer 3y ago

> it will open up a path for devs to get paid for the extra burden. The thing is, being paid for an extra burden doesn't make it any less of an imposition on devs limited energy. Basically, if you want to accept donations so people can show their appreciation for what you share freely with the world, you open yourself up to demands that you do work that you don't enjoy on a hobby. That's really shit.

smarx007 3y ago
I don't think this legislation will affect hobby projects. The problem is that whether the project is hobby or not is judged from the side of the consumer, i.e. if the software is usable "in the course of a commercial activity" (for the user). I agree that this creates a certain amount of stress, esp. for individual devs, but I think it was necessary to make sure that projects like k8s, kafka, and other OSS projects consistently relied on by businesses cannot claim that the OSS version is not for commercial use. And with that run-around statement, be done with CRA "compliance".
- marcinzm 3y ago
  >The problem is that whether the project is hobby or not is judged from the side of the consumer, i.e. if the software is usable "in the course of a commercial activity" (for the user). Have you seen the dependency trees for commercial software? I'd be surprised if there's any non-trivial OSS project that hasn't been used as part of commercial activity.
  - smarx007 3y ago
    I've seen many things in my life I'd gladly unsee, including corp IT devs putting programs with "SNAPSHOT" (unstable) dependencies in production. But just merely having a corp use your software would not place the CRA burden on you. Your project needs to make such an impression. The most negative outcome of this legislation that I can see is that OS projects like Nix, Debian and others will start aggressively pruning their software repositories from packages where there is any indications that devs/packagers are not reacting to CVE reports (or do it too slow).
    - rad_gruchalski 3y ago
      I see you are very active on this topic. I have a question regarding an interesting point you're making: > But just merely having a corp use your software would not place the CRA burden on you. Your project needs to make such an impression. What does "needs to make such an impression" mean. Sloppy code and PRs with Fix, Fix, Fix, Another Fix commits are hobby projects? And having some integrity implies "you make an impression of commercial activity"?
      - smarx007 3y ago
        I just think our industry is long overdue for some regulation ( https://www.youtube.com/watch?v=Gv2I7qTux7g https://www.youtube.com/watch?v=Gv2I7qTux7g as an inspiration ) and I also found the CRA requirements on pp. 2 and 3 ( https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-34e9-11ed-9c68-01aa75ed71a1.0001.02/DOC_2&format=PDF https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-... ) quite reasonable. What shocked me is how nobody on the thread considered/appreciated those two things. Having said that, there is a chance CRA implementation will get bungled, but I hope for the better. Regarding the commercial activity: I found the screenshot of a 3-part test from a recent Eclipse call and I hope it's OK to post it ( https://imgur.com/a/70a6cQt https://imgur.com/a/70a6cQt ). I think it's important to understand that in a multi-part test, you typically need to seriously hit a few points to "pass" the test. Some examples of what I would consider passing each point (but not necessarily the whole test): 1. Rust with its 6-week release cadence will quite likely pass the 1 part. 2. Nginx, k8s, Ubuntu LTS will quite likely pass the part 2 of the test. 3. A project like Eclipse 4diac ( https://projects.eclipse.org/projects/iot.4diac https://projects.eclipse.org/projects/iot.4diac ) would quite likely pass the 3rd part of the test. That's the part of the test that worries Github and others, because receiving money and significant contributions from corporate will contribute to scoring high on this point. But then, Eclipse 4diac could claim that it's mainly an R&D project and thus not passing the part 2 of the test. And even part 1 of the test would be hard to establish with barely 1 release a year.
    - marcinzm 3y ago
      >Your project needs to make such an impression. And how much are the legal fees going to be if you are accused of this and need to defend yourself? Given the fees if found guilty this seems very much a safer to just not risk it type of situation.
- bonzini 3y ago
  Do you know if the requirement is: * that a project is developed AND supplied commercially? * or rather that a project is developed OR supplied commercially? For example if I write an experimental project at work which might have vulnerabilities (developed commercially), which my employer has no intention of selling yet (not supplied commercially), should I still follow the CRA processes in case someone reports a vulnerability? What if someone else decides to take my toy project and put it into their product?
  - smarx007 3y ago
    I was on the Eclipse Foundation call a few days ago regarding this topic and they said there was a well-established 3-part test for this in the EU courts. But I don't think I managed to take a screenshot, sorry. Here is a snippet from the EU Blue Guide linked the from the Eclipse blog post: "Commercial activity is understood as providing goods in a business related context. Non-profit organisations may be considered as carrying out commercial activities if they operate in such a context. This can only be appreciated on a case by case basis taking into account the regularity of the supplies, the characteristics of the product, the intentions of the supplier, etc. In principle, occasional supplies by charities or hobbyists should not be considered as taking place in a business related context." I would consider GCC or React to fit this definition, while a hobby project like https://github.com/rui314/chibicc https://github.com/rui314/chibicc not to fit it. Edit: I don't think you would have any obligations under CRA unless you make a project release available, whether commercially or on Github. The 3-part test I mentioned above only kicks in when there is a release of some sort in the first place.
    - jcranmer 3y ago
      That roughly tracks with my gut reaction from reading what appears to be the current draft: if you're doing any sort of formalized release process, you're probably at the point where you're doing commercial activity. By the time you're supporting old versions of the software, and cutting new point releases, you're almost definitely in commercial activity land. Definitely it looks like a higher bar than GitHub is implying--I don't see any indication that merely soliciting donations would qualify for commercial activity.
- arlcode 3y ago
  I probably missed it (or it's in one of the many documents on the ITRE page) but in the quoted Recital (10) on the Github Blog I'm not seeing a disctintion with regards to the use of a product. Commercial or not (within the context of the CRA) seems to be based on the development structure and the offering of related services. For example they explicitely allow for a dristributed model where "no single commercial entity" has full control. I'm not doubting that what you said is true, I'm interested to learn more, because in general this directive seems to be a big step in the right direction. Do you happen to have a link to where I can read the current ITRE draft in it's enterity?
  - smarx007 3y ago
    The full draft is under https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-34e9-11ed-9c68-01aa75ed71a1.0001.02/DOC_1&format=PDF https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-... , the body starts from page 14. Upd: the amendment from 18.4.2023 is available under https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52023PC0208 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52...
    - arlcode 3y ago
      Thank you very much. That seems to be the original draft of the Commission before the considerable changes added since then by the several committees
      - smarx007 3y ago
        Thank you for checking carefully! I updated my original message with the extra link for the 18.4.2023 amendment.
    - sam_lowry_ 3y ago
      These suckers badly need version control.
- thayne 3y ago
  So from what I understand, this means: - you can't accept donations, or other small payments for your side project anymore, unless you take on a substancial burden - you can't give commit access to, or possibly even accept contributions from employees of entities that use your side project in a commercial setting. And what if you work for a software company, but contribute to OSS on your own time, does the project need to comply with CRA then?
  - smarx007 3y ago
    I’ve heard this reading of CRA and I think it’s overzealous on purpose to rile individual devs (well done). But we will have the courts decide and I think they will draw a much more clear line than “any project that received 1 EUR donation or accepted a single corporate committer”. For example, Facebook was claiming that violating users’ privacy was a “legitimate business interest” under GDPR until courts ruled otherwise. I am not expecting projects that merely accept some patches or donations to be on the hook. But https://squidfunk.github.io/mkdocs-material/ https://squidfunk.github.io/mkdocs-material/, for example, would fit the bill (see "Trusted in the industry" on the homepage and https://squidfunk.github.io/mkdocs-material/insiders/ https://squidfunk.github.io/mkdocs-material/insiders/). At the same time, I think the rules laid out in Annex 1 [1] are quite reasonable to comply with for any production-grade software. Interested to see if it would accelerate adoption of Rust/Zig, as [1] requires the software "be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;" [1]: https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-34e9-11ed-9c68-01aa75ed71a1.0001.02/DOC_2&format=PDF https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-...
    - adunsulag 3y ago
      Saying let the courts decide when there is massive ambiguity for the small projects and developers just means that many of us (I know I will) will region block the EU until some one else deals with the court system and provides clarity for the rest us. It is way, way better for legislators to provide intent and clarity then to make things uncertain and ambiguous for the courts to decide. If they truly aren't going to care about a single corporate committer, then lay that out, or if there is a maximum donation threshold (indexed to inflation) of what can be considered reasonable corporate donations, then specify. Otherwise, those of us who can't afford to be caught in a legal battle on another continent will just shut things down. That results in less software overall for the EU to use and innovate on. Perhaps that will result in better battle hardened software for the EU in general, but considering how much OSS has a huge dependency chain problem (many of them small projects), I'm doubtful that will occur anytime soon.

by jauer 3y ago

smarx007 3y ago

I don't think this legislation will affect hobby projects. The problem is that whether the project is hobby or not is judged from the side of the consumer, i.e. if the software is usable "in the course of a commercial activity" (for the user). I agree that this creates a certain amount of stress, esp. for individual devs, but I think it was necessary to make sure that projects like k8s, kafka, and other OSS projects consistently relied on by businesses cannot claim that the OSS version is not for commercial use. And with that run-around statement, be done with CRA "compliance".

marcinzm 3y ago
>The problem is that whether the project is hobby or not is judged from the side of the consumer, i.e. if the software is usable "in the course of a commercial activity" (for the user). Have you seen the dependency trees for commercial software? I'd be surprised if there's any non-trivial OSS project that hasn't been used as part of commercial activity.
- smarx007 3y ago
  I've seen many things in my life I'd gladly unsee, including corp IT devs putting programs with "SNAPSHOT" (unstable) dependencies in production. But just merely having a corp use your software would not place the CRA burden on you. Your project needs to make such an impression. The most negative outcome of this legislation that I can see is that OS projects like Nix, Debian and others will start aggressively pruning their software repositories from packages where there is any indications that devs/packagers are not reacting to CVE reports (or do it too slow).
  - rad_gruchalski 3y ago
    I see you are very active on this topic. I have a question regarding an interesting point you're making: > But just merely having a corp use your software would not place the CRA burden on you. Your project needs to make such an impression. What does "needs to make such an impression" mean. Sloppy code and PRs with Fix, Fix, Fix, Another Fix commits are hobby projects? And having some integrity implies "you make an impression of commercial activity"?
    - smarx007 3y ago
      I just think our industry is long overdue for some regulation ( https://www.youtube.com/watch?v=Gv2I7qTux7g https://www.youtube.com/watch?v=Gv2I7qTux7g as an inspiration ) and I also found the CRA requirements on pp. 2 and 3 ( https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-34e9-11ed-9c68-01aa75ed71a1.0001.02/DOC_2&format=PDF https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-... ) quite reasonable. What shocked me is how nobody on the thread considered/appreciated those two things. Having said that, there is a chance CRA implementation will get bungled, but I hope for the better. Regarding the commercial activity: I found the screenshot of a 3-part test from a recent Eclipse call and I hope it's OK to post it ( https://imgur.com/a/70a6cQt https://imgur.com/a/70a6cQt ). I think it's important to understand that in a multi-part test, you typically need to seriously hit a few points to "pass" the test. Some examples of what I would consider passing each point (but not necessarily the whole test): 1. Rust with its 6-week release cadence will quite likely pass the 1 part. 2. Nginx, k8s, Ubuntu LTS will quite likely pass the part 2 of the test. 3. A project like Eclipse 4diac ( https://projects.eclipse.org/projects/iot.4diac https://projects.eclipse.org/projects/iot.4diac ) would quite likely pass the 3rd part of the test. That's the part of the test that worries Github and others, because receiving money and significant contributions from corporate will contribute to scoring high on this point. But then, Eclipse 4diac could claim that it's mainly an R&D project and thus not passing the part 2 of the test. And even part 1 of the test would be hard to establish with barely 1 release a year.
  - marcinzm 3y ago
    >Your project needs to make such an impression. And how much are the legal fees going to be if you are accused of this and need to defend yourself? Given the fees if found guilty this seems very much a safer to just not risk it type of situation.
bonzini 3y ago
Do you know if the requirement is: * that a project is developed AND supplied commercially? * or rather that a project is developed OR supplied commercially? For example if I write an experimental project at work which might have vulnerabilities (developed commercially), which my employer has no intention of selling yet (not supplied commercially), should I still follow the CRA processes in case someone reports a vulnerability? What if someone else decides to take my toy project and put it into their product?
- smarx007 3y ago
  I was on the Eclipse Foundation call a few days ago regarding this topic and they said there was a well-established 3-part test for this in the EU courts. But I don't think I managed to take a screenshot, sorry. Here is a snippet from the EU Blue Guide linked the from the Eclipse blog post: "Commercial activity is understood as providing goods in a business related context. Non-profit organisations may be considered as carrying out commercial activities if they operate in such a context. This can only be appreciated on a case by case basis taking into account the regularity of the supplies, the characteristics of the product, the intentions of the supplier, etc. In principle, occasional supplies by charities or hobbyists should not be considered as taking place in a business related context." I would consider GCC or React to fit this definition, while a hobby project like https://github.com/rui314/chibicc https://github.com/rui314/chibicc not to fit it. Edit: I don't think you would have any obligations under CRA unless you make a project release available, whether commercially or on Github. The 3-part test I mentioned above only kicks in when there is a release of some sort in the first place.
  - jcranmer 3y ago
    That roughly tracks with my gut reaction from reading what appears to be the current draft: if you're doing any sort of formalized release process, you're probably at the point where you're doing commercial activity. By the time you're supporting old versions of the software, and cutting new point releases, you're almost definitely in commercial activity land. Definitely it looks like a higher bar than GitHub is implying--I don't see any indication that merely soliciting donations would qualify for commercial activity.
arlcode 3y ago
I probably missed it (or it's in one of the many documents on the ITRE page) but in the quoted Recital (10) on the Github Blog I'm not seeing a disctintion with regards to the use of a product. Commercial or not (within the context of the CRA) seems to be based on the development structure and the offering of related services. For example they explicitely allow for a dristributed model where "no single commercial entity" has full control. I'm not doubting that what you said is true, I'm interested to learn more, because in general this directive seems to be a big step in the right direction. Do you happen to have a link to where I can read the current ITRE draft in it's enterity?
- smarx007 3y ago
  The full draft is under https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-34e9-11ed-9c68-01aa75ed71a1.0001.02/DOC_1&format=PDF https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-... , the body starts from page 14. Upd: the amendment from 18.4.2023 is available under https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52023PC0208 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52...
  - arlcode 3y ago
    Thank you very much. That seems to be the original draft of the Commission before the considerable changes added since then by the several committees
    - smarx007 3y ago
      Thank you for checking carefully! I updated my original message with the extra link for the 18.4.2023 amendment.
  - sam_lowry_ 3y ago
    These suckers badly need version control.
thayne 3y ago
So from what I understand, this means: - you can't accept donations, or other small payments for your side project anymore, unless you take on a substancial burden - you can't give commit access to, or possibly even accept contributions from employees of entities that use your side project in a commercial setting. And what if you work for a software company, but contribute to OSS on your own time, does the project need to comply with CRA then?
- smarx007 3y ago
  I’ve heard this reading of CRA and I think it’s overzealous on purpose to rile individual devs (well done). But we will have the courts decide and I think they will draw a much more clear line than “any project that received 1 EUR donation or accepted a single corporate committer”. For example, Facebook was claiming that violating users’ privacy was a “legitimate business interest” under GDPR until courts ruled otherwise. I am not expecting projects that merely accept some patches or donations to be on the hook. But https://squidfunk.github.io/mkdocs-material/ https://squidfunk.github.io/mkdocs-material/, for example, would fit the bill (see "Trusted in the industry" on the homepage and https://squidfunk.github.io/mkdocs-material/insiders/ https://squidfunk.github.io/mkdocs-material/insiders/). At the same time, I think the rules laid out in Annex 1 [1] are quite reasonable to comply with for any production-grade software. Interested to see if it would accelerate adoption of Rust/Zig, as [1] requires the software "be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;" [1]: https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-34e9-11ed-9c68-01aa75ed71a1.0001.02/DOC_2&format=PDF https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-...
  - adunsulag 3y ago
    Saying let the courts decide when there is massive ambiguity for the small projects and developers just means that many of us (I know I will) will region block the EU until some one else deals with the court system and provides clarity for the rest us. It is way, way better for legislators to provide intent and clarity then to make things uncertain and ambiguous for the courts to decide. If they truly aren't going to care about a single corporate committer, then lay that out, or if there is a maximum donation threshold (indexed to inflation) of what can be considered reasonable corporate donations, then specify. Otherwise, those of us who can't afford to be caught in a legal battle on another continent will just shut things down. That results in less software overall for the EU to use and innovate on. Perhaps that will result in better battle hardened software for the EU in general, but considering how much OSS has a huge dependency chain problem (many of them small projects), I'm doubtful that will occur anytime soon.