Define "functional open alternatives" in indicator 4

[Lucyeoh]

Indicator 4 in the standard allows open source projects that have a mandatory dependencies that create more restrictions than the original license IF the project(s) is able to demonstrate independence from the closed component(s) AND/OR indicate the existence of functional, open alternatives.

4. Platform Independence | If the project has mandatory dependencies that create more restrictions than the original license, the project(s) must be able to demonstrate independence from the closed component(s) and/or indicate the existence of functional, open alternatives.

The mention of “open alternatives” in indicator 4 should refer to working solutions, in order to avoid misleading adopters into thinking that something is a DPG because in theory it can be run on this OSS software whereas in practice it only runs on this other proprietary software.

Below are suggestions (to be discussed) on how this indicator could be improved to more clearly articulate the requirement for projects that may have a closed component where an open alternative exists but has not been implemented.

[Lucyeoh]

Lucy's thoughts & Suggestions:

1. I think it's important that the existence of theoretical open alternatives be allowed, even if they are not yet implemented because of the practical considerations that some projects do not have the money, or the open alternatives have issues, that make it difficult to avoid all open source dependencies.

2. I think it is important that the digital solution is set up such that someone who wanted to avoid the proprietary system but adopt or adapt the DPG could do so with reasonable ease aka. minimal changes to the original solution .

Therefore I propose the revision to indicator 4 :
If the project has mandatory dependencies that create more restrictions than the original license, the project(s) must be able to demonstrate independence from the closed component(s) and/or indicate the existence of functional, open alternatives that could be implemented with minimal changes to the original solution.

[prajectory]

Revision to indicator 4 - proposed after discussion:
If the project has mandatory dependencies that create more restrictions than the original license, the project(s) must be able to demonstrate independence from the closed component(s) and/or indicate the existence of functional open alternative that can be used without significant changes to the core product.

[prajectory]

We welcome inputs from the community on this particular change. We will revisit and close this 2 weeks from today. Thank you and look forward to hearing from you.

[prajectory]

#57 This change has been incorporated into the final text here. Closing this and we will keep tab of the changes in #57