Define "functional open alternatives" in indicator 4 about dpg-standard HOT 4 CLOSED

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.

from dpg-standard.

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.

from dpg-standard.

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.

from dpg-standard.

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

from dpg-standard.