Preventing 'Extend, Extinguish': via License rules for specs + protocols

CW: E3 / defense against sabotage.


What about a license that requires any/all

  • … [footnote 1]

to only operate provided all the following conditions are met:

  1. Affero GPL; and
  2. Rust-style license (or similar)

which
ensures consistency & interoperability with a “base spec” [1, again],
and
does neither {modify, extend, customize, operate, **express intent nor condition(s) nor possibility(ies) nor option(s) to (operate nor behave nor customize) ** … etc legalese}
in any way(s), shape nor form which could possibly/potentially hinder the future ability of {BASE SPEC} and {“YOUR” implementation or spec} to have full total current and any/all possible FUTURE interoperability.

###Downside:###
Inhibits possible innovation.

Q:
Is there a way to do this in a way which would NOT prevent innovation?

Maybe a consensus among all?

Trial & prototype periods of 18months per new feature;
no more than 1 new feature at a time per the whole FEP?
(lol)

I have no idea.

[1]
“including but not limited to:

  • apps
  • clients
  • servers
  • software
  • hardware
  • policies
  • license agreements
  • features
  • protocols
  • implementations
  • instances
  • etc

I apologize as
i. I’m new at this; and
ii. I’m new at this.

Are you proposing to change the open definition and therefore the definition of an open standard?

If so you may be interested in the ongoing process Updating the Open Definition to meet the challenges of today.

2 Likes