> It is of particular importance for manufacturers to ensure that their products do not contain vulnerable components developed by third parties.
> Manufacturers shall, upon identifying a vulnerability in a component, including in an open source component, which is integrated in the product with digital elements, report the vulnerability to the person or entity maintaining the component.
EDIT: Also, I concur the poster below. It's developers who oppose against management to allocate time for bugs and technical debt instead of new features.
TBF there is a lot of things “free of charge” connected to commercial activity, e.g. Android, .NET Core, MongoDb, ElasticSearch, even RedHat with Linux …
I understand need to somehow include them, but the line should be at the for-profit companies and exclude non profits and individual developers.
How to formulate it without easy loopholes is no easy task.
The trick of course will be to have the software offered as a paid product by a non-profit, while having a for-profit outfit develop the software as a custom/consulting engagement for the non-profit. You can thank me later.
You are asking how requiring open source with no money to satisfy plethora of regulations along with legal liability (I.e. making it a commercial grade) makes it less likely for open source be made?
There is some hope for individual developers in EP amended version https://www.europarl.europa.eu/meetdocs/2014_2019/plmrep/COM... article 10c:
> Developers contributing individually to free and open-source projects should not be subject to obligations pursuant to this Regulation.
Actually it’s an improved version. Hopefully it will make it through consolidation with EC version.
Thank you for providing that, didn't knew about that amended version. This only includes individual developers though and if you are employed this is already a problem again: (10a) "[...]Similarly, where the main contributors to free
and open-source projects are developers employed by commercial entities and when
such developers or the employer can exercise control as to which modifications are
accepted in the code base, the project should generally be considered to be of a
commercial nature." A small step in the right direction, but not quite there yet. Companies that want to just release (old) projects would also be more hesitant now. Recurring donations from companies would also contaminate the project.
Professional does for money, by definition. That doesn’t apply for most open source. RedHat employee contributing to Linux kernel is an exception, not a rule.
> The majority of open source contributions are people making commits while at their paid jobs.
Do you have any evidence to back up this seemingly wildly speculative assertion?
And, even if it were true, "while at their paid jobs" doesn't mean at all they're getting paid as developers at all, let alone as developers on those projects that they are contributing to.
Also, empirically, many of the most popular open source projects are published by commercial companies, who hire developers to maintain them. If you review the commit history for these projects, you will see that many of them are, unsurprisingly, employees.
There is inevitable overlap of commercial activity with popular open source software. Either it was a commercial piece of software to begin with, or because it is popular, it now has commercial value and garners commercial attention. Something like React falls into the former, and something like Linux falls into the latter.
There's a lot of community open source software too, but it trends towards smaller hobby projects with few users.
First, I like how you included “popular” adjective. That alone disqualifies 99% of projects. These are the projects “hacked” by non-paid devs.
Second, some proof would be nice. I live in .net/nugget ecosystem and other than libraries backed by MS, most popular projects are not (at least ones I know of).
The 'popular' qualifier is important, because these are the ones that important infrastructure are reliant on. These are the ones that should meet professional standards. And by most accounts, they are being developed by professionals who should be subject to such expectations.
I think it's okay if a hobby project is unsuitable or unreliable for important tasks. They should also not be used in critical infrastructure or commercial products.
To put it bluntly, it means a significant risk when creating any open source project. It’s a common knowledge that there is no money in open source, but suddenly I am liable. Half of open source licenses is disclaimer of liability. Also a lot of other yet to be defined requirements (harmonised regulations it is called I believe).
Linux, World Wide Web… not worth the risk.
So I am making something in my free time, as a hobby, no monetary gain and suddenly I can easily get sued to oblivion. I need to at least buy insurance. My library is used left and right in commercial activity.
The impact assessment for CRA is a total lie. It assumes 100% decrease in cyber damages and laughably low compliance cost and very small amount of impacted entities (only companies, not individuals and each company makes one product).
TBF, version amended by EP explicitly excludes individual developers, hopefully it makes it through trialogue.
Edit: basically imagine authors of log4j. Remember that security flaw that impacted half the internet? That is what’s called liability. Did they use ‘ apply effective and regular tests and reviews of the security of the product with digital elements;’? Better make it industrial grade product, with no money, in their free time.
That assumes that new humans can be only by women.
There is no reason, why artificial womb, possibly with multiple selection box for genes, is not a very realistic possibility, along with state funded child rearing services. (see Norway)
1. Reproduction is already heavily subsidized in many countries, be it direct grants, tax breats and so on. This is nothing new.
2. Most people actually want children. Getting someone to actually procreate with that will share burden.
3. Investing in children should hel to fund future pension payments. There is pretty good case for self-interest.
4. China won't care, neither will Russia or other parts of world.
5. Countries that will do that will have a better outcome than countries full of retirees. Unless AI takes over, natural selection will take care of rest
If this happens, I assume Chinese breeding facilities will optimize for producing children with high cognitive ability. Via selective breeding, embryo selection, or genetic engineering.
Maybe, but normal developer interracts with sane parts.
Honestly, the biggest problem with git is sane environment for merge conflicts and that is out of scope of git CLI. In most cases, imposing rule for small PRs/feature branches will solve it.
git add, git commit, git log, git blame, git push, git rebase -i --onto. That is 95+% of what developers use (maybe an option here or there, like -m or --amend). Merges are done on CI after it passes.
There are a lot of arcane parts and switches. git-send-email is likely used a lot on kernel development, but very rarely in the rest of the world.
> I've got 10 years in it and it still bites me in the ass.
Can you give some examples? I had some problems in the beginnings, but it was because i tried to be "smart".
After I embraced KISS, everything works nicely. As long as I keep "public" branches protected, any splash zone is very small and at worst, just redo it(synergy with small PRs).
Important bits (10c and around):
* Libraries/non-end products are fine, unless monetized.
* Employee contributions seem to be fine.
* Foundations seem to be fine.
* Non-core developers are fine
Seems like significantly better version.