On 2 Jan 2025, at 12:05, Ilu <ilulu@xxxxxxx> wrote:My feedback on the flowchart:
> "10. ... Do I have a committer license agreement ..."
I do not think mixing up license aggreements with CRA is a good idea.
They follow a completely different legal regiment that have nothing to
do with each other. Statements like "you are almost certainly fine" or
"introduce a CLA" are dangerous under these conditions. Especially (but
not exclusively) for the reader.
So can we refine this in a set of better questions; e.g. to match the example of your other email:
"If you are a hobbyist without commercial activity or financial interest
in software development of any kind or form and without a team around
you, the CRA is not for you.
(where I would add 'single' before hobbyist. > "20: Are you maintaining or operating a public software repository ...
> Yes: You are probably fine"
No? This question is confusing because in both cases you get "goto 30".
The thinking behind this is that quite some of the know entities asking these questions -ALSO- operate some sort of repository or distribution site with a lot of third party code that is not theirs.
> "30: Are you developing ppen source software in the course of a
> commercial activity ?
The first quesion is correct and the answer "yes" would need "Go read
the CRA. This flow chart is not for you."
> i.e. is it placed such that others (downstream)
> can use it in lasting ways as these downstream parties go about their
> lives or business ?"
But the 2. question/explanation does not match the first question. These
are completely different things. The dev putting something on github can
never know whether anybody uses the software for whatever.
So the issue I am struggling with is the case where software walks & quacks like a duck - but the developer says it is not.
I.e. where everything is done in terms of release engineering & handling issues/tickets that shows that the whole group of people involved it the creation is well aware of this software being essentially in the market (i.e. outside their own companies).
So very open to suggestions how we deal wit this.
Actually, No 30 is the most complicated thing for any dev (who also
somehow makes a living from being a dev) anf the main course of fears
and it cannot be solved by a general questionaire.
Agreed. No 50 adresses the stewardship issue we discussed in another thread.
Since national law might be involved and nobody knows what the European
market authorities are going to say this needs to be said very
cautiously. Larger groups should definitely get legal advice because
ramifications of wrong decisions are plenty.
Would you have some text suggestions ? I can understand that you want to give easy guidance but the whole
situation is not easy and in many cases outright complicated and it does
not help to pretend. I do not like answers like "you will be fine", they
can be misleading.
Right - but the goal here is to see if we can do enough to help people at the next FOSDEM.
It is fine to conclude this is far too complex still. And guidance is needed from the EC.
However I fear that the EC & the way modern public policy/law is made is far too `lazy'.
There is a tendency to simply throw things over the wall and have companies, lobbyist and normative bodies then deal with the mess - with a solid serving of expensive big4 consulting on the side to `explain it all' and arrive at `industry good practice'.
I rather define that industry good practice here before that happens :) And that way determine what the defacto guidance is. Because once 80% of this problem is solved by a 20% effort in the big package/open-source ecosystems; it is essentially a done deal. Just like like cannot get a horse to drink or IPv6 deployed :)
This sounds all very negative so I'm going to finish here and start a
new thread with a more positive outlook.
Thanks for that one !
Dw. Am 20.12.24 um 23:30 schrieb Dirk-Willem van Gulik via open-regulatory-compliance: Here is my attempt at a more flowchart form for natural persons (mostly in reaction to some private questions).
Mainly to see if this teases out other questions/issues.
I’ve been a bit black and white/over the top in below; somewhat intentional to see if this helps us get better boundaries for the vague areas; and if there are things we can simply take as right — and we can focus on the ‘indicators’ for these.
Dw.
10: Do I personally contribute to an open source project ?
E.g. do I sent in patches or do I post bugfixes to an Open Source project ? Or do I do a pull request ?
No: Do I contribute to that open source project as part of job; because my boss wants it ?
I.e. in the boss his time (also if I am my own boss - where it is part of what I deliver to my customers) ?
Yes: Generally - the CRA is not your problem, but your bosses their problem.
This flowchart is not for them.
goto 20
No: goto 20
Yes: Do I have a committer license agreement (CLA) with that open source Project and do you contribute under that license ?
Or do you contribute to a project with an implied contribution agreement that is part of the projects open source license ?
Yes: While it depends on the minutiae; you are almost certainly fine if it is one of the many typical ASF variations of a CLA.
goto 20
No: you are probably fine; but would be good to introduce a CLA
goto 20
20: Are you maintaining or operating a public software repositories of open source ?
Yes: You are probably fine
goto 30
No: goto 30
30: Are you developing ppen source software in the course of a commercial activity ?
i.e. is it placed such that others (downstream) can use it in lasting ways as these downstream parties go about their lives or business ?
Yes: goto 40
No: You are probable fine
So you are a pure hobbyist; no one really uses your code; or others if so - and if they do so - it does not result on something lasting that exposes it to other people beyond the person who you directly shared it with.
END
40: Are you monetising the work you do on this open source ?
For example you XXXX?
Yes: Go read the CRA. This flow chart is not for you.
END
No: goto 50
50: Is there a group of people and/or legal persons that you are part of, where there is the shared objective or purpose to create, maintain, publish that open source licensed code ?
A typical indication is that you call yourself a group; have a website; have a SCM you all have access to; may have created a more formal legal vehicle; such as a foundation, society or similar, practice some software/release engineering and that you create some forms of processes and rules.
Yes: > hit the superset or either/or issue of legal/natural person <
goto 60
No: You are probable fine - depending a bit on the answer to above super/subset issue
END
60: Is the purpose of that open source such that it is intended; or quite possibly, to be used `downstream’, including by others in a commercial setting ?
Typical indications of this are things like a SCM, release notes, versions numbers, READMEs, makefiles, including in repositories, systemd scripts to start/stop, an FAQ, A manual, a bug database, non directly involved developers submitting bugs or asking questions, etc.
Yes: goto 70
No: You are probable fine - and you and a few mates are working on something very internal; such as the open source code for a large model transit you are building together
END
70 Is there an aspect of a sustained basis & ensuring longer term viability of the product.
So think proper release engineering, fixing bugs, doing risk-based triage, responsible disclosure, filing CVEs, disclosing unsolved vulnerabilities in the release notes, peer review of the releases, timely releases, etc ?
Yes: You are probably an open source steward.
END
No: You probably want to step up your organisational maturity. So that your software is generally `fit for purpose’; and some abandonware does not catch anyone of guard by accident. E.g. much like you would not leave a razorblade where a child could find it.
As the CRA was designed to clam down on exactly this type of situation.
END
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
|
