Maybe we should establish a "maintenance.md" practice just like "readme.md" or "LICENSE" where you just clearly outline the amount of maintenance the project/development team are planning to put into the code base and under which conditions.
-
"I will not maintain this code at all. Use fully at your own risk" is valid.
I think it's just important to make that clear.
@tante But that's what most open source licenses already say: PROVIDED AS IS
For me that's as clear as I can be. Of course that also means I won't try to convince people to use my code. Or if I ever do that and present at a conference, my talk will mention this part of the license.
-
The CRA asks Open Source Software Stewards to do something like this.
Genauer heisst es hier: "
(19) [...] (open-source software stewards), should be subject to a light-touch and tailor-made regulatory regime. [...], siehe:
https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
Das Brötchen hat die Körner in Articel 25 bei den Voluntary Security Attestations:
Damit balgt sich gerade die Open Regulatory Compliance Workinggroup, siehe:
Die würden als ne Art CE Kennzeichen an Code diesen auch "wieder" voll nutzbar machen im open source Sinne.
-
Maybe we should establish a "maintenance.md" practice just like "readme.md" or "LICENSE" where you just clearly outline the amount of maintenance the project/development team are planning to put into the code base and under which conditions.
I have seen that a few times but maybe it should be more of a standard.@tante https://www.tc54.org/contributing-yaml/ although I think all of these file types end up going stale pretty quickly
-
Maybe we should establish a "maintenance.md" practice just like "readme.md" or "LICENSE" where you just clearly outline the amount of maintenance the project/development team are planning to put into the code base and under which conditions.
I have seen that a few times but maybe it should be more of a standard. -
-
@tante But that's what most open source licenses already say: PROVIDED AS IS
For me that's as clear as I can be. Of course that also means I won't try to convince people to use my code. Or if I ever do that and present at a conference, my talk will mention this part of the license.
@odoruhako that's the legalese framing (which is mostly a "we don't wanna be sued" solution). But projects _do_ act differently and bigger projects do - voluntatrily - to way more: Defined release cadences, support windows, etc. And that is to a certain degree the expectation that people have been trained on - even though it does not scale especially not to single developer projects.
-
"I will not maintain this code at all. Use fully at your own risk" is valid.
I think it's just important to make that clear.
@tante
In this blessed month of mercy and giving,In Gaza, children are not asking for much… just a small moment of joy and a real smile.
Our children deserve the best.
With a simple donation, you can make a true difference in a child’s heart.Never underestimate a small gift… for them, it means hope. 🤍
-
"I will not maintain this code at all. Use fully at your own risk" is valid.
I think it's just important to make that clear.
@tante I think this is the baseline unless anything else is explicitly stated.
(The reverse timeline algorithm led me to this only after the previous post.)
-
In the Nebula project, we have a project status section at the end of https://nebula-plugins.github.io/documentation/plugin_overview.html that addresses some of this stuff.
-
Maybe we should establish a "maintenance.md" practice just like "readme.md" or "LICENSE" where you just clearly outline the amount of maintenance the project/development team are planning to put into the code base and under which conditions.
I have seen that a few times but maybe it should be more of a standard.@tante There is http://unmaintained.tech/
-
R ActivityRelay shared this topic
