Super-unnecessarily-complex License (SML-2.0.0)

This marks the start of Super-unnecessarily-complex (SML-2.0.0)

0.) Copyright and Style

Copyright Notice

Fields in Expiration marked Optional are only valid when EXPIRATION YEAR is set to NEVER, otherwise its required.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

© (DAY), (MONTH), (YEAR APPLIED) – (OPTIONAL DAY), (OPTIONAL MONTH), (EXPIRATION YEAR / NEVER)

(Organization or Holder)

Founder(s): (Founders)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Style Guide

1.) Core Concepts Of This License

Definitions

The following bolded terms when associated with a term in bold will be referenced back to throughout this License. In all cases it will explicitly-unless otherwise specified-mean the same thing as defined below.

• License - This document in which you are currently reading.
• Sub-License - Any license applied in addition to this License, outside of those in which would act as primary above this License.
• Parent-License - Any license that acts as primary above this License.
• CLL - The Cecil Libraries License used within Cecil Libraries Organization products.
• Original License - The License as you first received it, including any Addenda already attached.
• Universal License - The License in its original state before Addenda were applied.
• Effective License - The License after all Addenda's and the Node System applied to it have been resolved.
• Copyright Notice - The Copyright Notice in which is included within this License.
• Rights - The legal rights granted to the user under this License.
• Organization - The entity listed as the Organization or Holder in the Copyright Notice.
• Founder - Whoever is listed under the Founder section of the Copyright Notice.
• Year - The year the Copyright Notice took effect.
• Expiration Year - The year the Copyright Notice ends, unless set to NEVER, in which case the Copyright Notice never ends.
• Day - The Day listed in the Copyright Noice.
• Expiration Day - If included the Day listed for Expiration in the Copyright Notice.
• Month - The Month listed in the Copyright Noice.
• Expiration Month - If included the Month listed for Expiration in the Copyright Notice.
• Date - The Day, Month, Year of the Copyright Notice in form of DD/MM/YYYY.
• Expiration Date - The Expiration Day, Expiration Month, Expiration Year of the Copyright Notice in form of DD/MM/YYYY, if Expiration Year is NEVER, this is set to NEVER.
• Addenda - Additional terms attached to this License to cover specific needs of the Organization or Founder.
• Substantial Content - Content that defines how this License functions.
• Non‑Substantial Content - Formatting, punctuation, capitalization, and other cosmetic elements.
• SaxbyMod - The author of this License, known as Chaosyr as of 2026.
• Mandation Period - The period of time between the mandation Date and its Expiration Date.
• Active Mandation - The Mandation Period during which the License is in effect.
• Renewed Mandation - A new Mandation Period applied after expiration.
• Initial Mandation - The original Mandation Period before expiration.
• Dead Addenda - An Addenda that has expired and no longer applies.
• Public Archival - The act of storing a Dead Addenda in a publicly viewable form.
• Creation Age - The age in which the Proceeding or Receeding depending on usage was first created.
• Third Party - Refers to any content in which stems from a Party Outside those mentioned in the Universal License and Copyright Notice.
• Patch - Essentially any peice of a Addenda in which would Override functionality of another Addenda or Patch.
• Node System - This refers to the system of Nodes in which is utilized as a Resolution step for Addenda.
• Node - This refers to a Item within the Node System.
• Nodes - This refers to a collection of the Node entrys within the Node System.
• Node Resolution Order - The order by which Nodes are to be rendered into affect.
• Node Position - A property defined as apart of the Node System in which acts as a Integer to determine where in the Node Resolution Order the Node resides, Typically following a incremental index such as 0 -> 1 -> 2 -> 3 etc.
• Resolution Layer - A System in which handles conflicts between 2 different Addenda be it children, siblings, parents or anything else in the tree, conflict in the form of 2 items that violate eachother's implemented scope to be precise, this system acts as a Resolver.
• Resolver - Provides ways in which to resolve confliction between parts of this License.

Phrases

The following italicized terms when associated with a term in italics will be meant to mean what is defined below when utilized. In all cases it will explicitly-unless otherwise specified-mean the same thing as defined below.

• belongs to - Indicates legal ownership (copyright, authorship, trademark).
• consider - Must be taken into account when applying the associated rule.
• older - Having an earlier Creation Age.
• younger - Having a later Creation Age.
• age - The time since the subject was first created or first mandated.
• dead - No longer in effect; the Addenda becomes a Dead Addenda.
• mandated - The start of Active Mandation.
• remandated - The start of Renewed Mandation.
• removed from Mandation - After the end of Active Mandation.
• first created - The beginning of Initial Mandation.
• expire - To enter dead status.
• planned - Indicates a permanent intention (e.g., “not planned to return” = “permanently will not return”).
• parent - Indicates the parent of the proceeding Subject.
• children - Indicates the child of the proceeding Subject.
• tree - Indicates the tree of connection between the parent of the receeding Subject, receeding Subject, and children of the receeding Subject.
• clarifies - When something tightens the meaning of the proceeding or receeding Subject based on what is applicable.
• references - When something merely cites the proceeding or receeding Subject based on what is applicable.
• depends - When something requires what is established by the proceeding or receeding Subject based on what is applicable.
• extends - When something expands upon meaning of the proceeding or receeding Subject based on what is applicable.
• scope - The full extent in which the preceeding or receeding Suject covers based on what is applicable.
• relevant - The extent in which the preceeding or receeding Subject relates to the scope based on what is applicable.
• sibling - Indicates another item of children of the same parent of the proceeding Subject.
• loaded - In a state where it is active within the Effective License.
• load order - The order in which items are loaded under the Effective License.

2.) Universal License Rulings and Rights

Terms as a License

Terms as a Sub-License

Terms as a CLL Sub-License

Shared Terms Across All License Types

"The Addenda System", and "Public Archival System" are deemed to be apart of this section.

3.) The Addenda System

License Editing

You may not alter or remove Substantial Content of the Universal License.

You may add Addenda, as long as they follow the rules defined in this License.

License and Addenda Holders

The Universal License belongs to SaxbyMod.

Upon SaxbyMod's passing, ownership of the Universal License belongs to whoever SaxbyMod designates.

Each Addenda belongs to its Organization or Founder's unless the Addenda itself states otherwise.

What an Addenda Must Contain

An Addenda must:

1. Use Markdown consistent with the Original License.
2. Use the same header structure.
3. Include a Copyright Notice matching the Original License, with updated Organization, Date, Expiration Date, and Founder.
4. Contain terms relevant only to its own title, meaning it may not have terms outside the scope of the Addenda's title.
5. Include its own Definitions and Phrases sections.
6. Consider how it handles the Organization or Founder becoming unavailable.
7. Consider whether and how it may be edited.
8. Not depend upon its own children.
9. Define itself in accordance with the Node System provided, the definition it mandates may be edited by the Organization or Founder's based upon the current Node System which is in place.
10. In the case the Addenda is an Expansion to another Addenda it must be marked as such in the expansion specifications of the Addenda.
11. Consider any renewal related specifications.
12. Not alter in any way, shape, or form how Nodes, Node items, the Node System, the Node Resolution Order, or the Node Position work, function or behave.
13. Not alter in any way, shape, or form how a Node System's Definitions or Phrases work, function or behave.
14. Can utilize a Node System's Definitions or Phrases to define its own functionality.

Default Addenda Resolution Layer's

Each of the below within this section are treated as a Resolution Layer.

The Parent-License in the case of conflict with this License overrides the Universal License, Original License, and Addenda regarding Rights, only within its scope.

The Universal License always overrides all Sub-License's regarding Rights, only within its scope.

Addenda's are to always be resolved in the following order;

1. Expansion Priority - If Addenda A expands Addenda B, then A overrides B.
2. Age Priority - If unrelated, the older Addenda overrides the younger, in terms of Date.
3. Node Priority - If still unresolved, the Node System determines precedence.

When Renewed Mandation Is Allowed

Renewed Mandation is allowed only when the License or Addenda has expired, and the Addenda explicitly permits Renewed Mandation, and you are the Organization of the affected Addenda.

What Happens Upon Renewed Mandation

Only the Copyright Notice must be updated. Rights return to active status for the new Mandation Period. The gap between Mandation Periods is not retroactively covered. If a Dead Addenda is renewed, the Addenda's dead version must remain in Public Archival.

Removing Dead Addenda

Removal is allowed only when the Addenda has expired and is not planned to return, and the Dead Addenda is placed into Public Archival before deletion.

Addenda Expansion Rules

An Addenda expands another Addenda when the the Addenda adds new terms that depend on the earlier Addenda, or the Addenda clarifies or extends the earlier Addenda's scope.

If Addenda A expands Addenda B, Addenda A overrides Addenda B where conflicts occur, Addenda B remains valid where Addenda A does not conflict, Both Addenda remain active unless one expires.

Referencing another Addenda does not automatically make the Addenda a Expansion.

An Expansion based Resolution only applies for explicitly relevant parts of the Addenda in which modify their parent Addenda. For example if the original Addenda was "Commercial Sale Allowed" while the Expansion Addenda is "Commercial Resale Disallowed", than there is no Expansion resolution, rather the terms exist seperately. All Addenda which expand a parent Addenda are treated as children of that Addenda.

An Expansion can not depend on its own children in any way, shape, or form. This breaks this Expansion resolution, and thus forth, may not be allowed to occur at any point within this License. If such case still arises, all affected Addenda by way of which they are Expansions, are deemed to be Null and Void, anything unrelated to the Expansions are left. The parent Addenda in such case remains valid.

All Expansions behave like a Patch to a existing Addenda, it may extend, or clarify it, but in the end it merely works like a Patch. A Patch only covers the scope of the given Patch.

Sibling Addenda that do not directly conflict must be jointly applied within overlapping scope. A conflict occurs when two Addenda impose mutually exclusive conditions within the same scope.

Addenda Age Rules

Creation Age determines which Addenda is older or younger.

Older Addenda override younger Addenda only when no Expansion relationship exists. Age does not override the Universal License. Age does not override Rights.

Node System (Fallback Resolution)

If two Addenda do not expand each other, and are the same Creation Age or age is irrelevant, and still conflict, then the Node System resolves the conflict.

The Organization is required to define the exact Node System in use via the section provided below labeled "Node System Mandated", it must resemble a complete Node System according to the traits below. If the System changes, or expires it must be sent to Public Archival. There may only be ONE Node System per License. A Node System is not and will not be considered a Addenda, it is merely a System in which defines a Resolution Layer.

Node System's must have the following traits;

1. Node System's must ideally provide a Node Resolution Order based upon Node Position, there must be at least 1 Node.
2. Nodes must be grounded in standards that the governing jurisdiction explicitly recognizes as legally valid, enforceable, and compliant with all applicable laws and regulations.
3. You may not add more fields outside of what is provided within the provided Node System section.
4. Must rely upon its own Definitions and Phrases in the case it needs any additional terms, it may not utilize an Addenda's.
5. Use Markdown consistent with the Original License.
6. Use the same header structure.
7. Include a Copyright Notice matching the Original License, with updated Organization, Date, Expiration Date set to "NEVER", and Founder.

Nodes must have the following traits, in addition to the afforemention requirements for Node System's have required for Nodes;

1. The name of the Node.
2. The body of what the Node affects must be within the scope of its name.
3. How resolution functions for the Node.
4. Must have a unique real integer Node Position.
5. May only resemble a Resolution Layer, it may not treat itself as a Addenda.

All Nodes are ran in Incremental Order based upon Node Position of the Node, in the case that Node Resolution Order is unspecified.

How Expiration Works

A Addenda expires when the Addenda's Expiration Date is reached, or the Addenda explicitly states a condition that triggers expiration, or the Addenda is replaced by a newer Addenda through Expansion.

Upon expiration the Addenda becomes a Dead Addenda, the Addenda must be placed into Public Archival, the Addenda may not be removed unless not planned to return, the Addenda may be renewed only if explicitly allowed. children Addenda, and all children within the children Addenda's tree, are also rendered with the same treatment as the parent Addenda.

How Dead Addenda Work

Dead Addenda no longer apply to any active Mandation period.

Dead Addenda must remain accessible in Public Archival.

Dead Addenda may be renewed only if the Addenda or License explicitly allows Renewed Mandation.

Addenda and Rights

Addenda may remove, alter, or expand the Rights given by the Effective License, as long as they do not violate the terms of the Universal License, or if applicable Parent-License's, Addenda may not define, modify, or override any Node System.

Evaluating the Effective License

The order in which the Effective License is evaluated is as follows;

1. The Universal License
2. The Node System is rendered onto the License, Nodes are loaded based upon the Node System's Node Resolution Order.
3. The tree of Addenda's, starting with the parents, proceeding into the parent's children, resolving in the order of how they are presented within the document, if any children, have more than one parent in which the other parent hasn't resolved, the other parent must be resolved before rendering the children. Third-Party Addenda are rendered first in the order by which they are presented, followed by Organization Addenda in the order by which they are presented, followed by Founder Addenda in the order by which they are presented.
4. Additional context inputted into this License by any Sub-License's, resolved in order of how they are presented.
5. Any restrictions placed upon this License by any Parent-License's, resolved in the order of how they are presented.

Any breaches anywhere in the process are to be determined after the above steps are completed.

How Patches apply

All Patches are rendered in the order they are loaded within the Effective License.

e.g. License gets patched with the Addenda which gets patched with the Expansion Patch which gets patched with the next subsequent Expansion Patch which gets patched with the next subsequent Expansion Patch etc.

If a Patch is incompatible somewhere within that rendering, the Patch and all children of the Patch are rendered Null and Void. This case occurs after any applicable Resolution Layers of the Addenda's.

Addenda Ordering

All Addenda in which came from the Original License under Organization Addenda's or Founder Addenda's must be placed into Third-Party Addenda, before existing Addenda within that section, in the effective order they appeared in this License. This should mimic the load order it had when it was handed to you.

All Addenda's from the Organization and Founder's must be placed in Alphabetical order first, than by Date second, than by whichever Mandation Period is longest third. If there is still 2 identical entries, the latter found case should be placed under the prior. Organization Addenda must be placed under Organization Addenda, Founder Addenda's must be placed under Founder Addenda's.

Addenda Location

The Addenda's to this License section is where Addenda's active on this License are to be located. If the Organization or Founder mandating this License wishes it may also live entirely within a Sub-Document, with the same ruleset for Style, formatting, ordering etc. That Sub-Document must be linked to within the below Addenda's to this License section.

4.) Public Archival Terms

Public Archival Location

The Public Archival location must be linked within the Public Archival section. If there is more than one, link all of them.

Public Archival Requirements

Public Archival must:

1. If utilized keep track of when entries were added into the Archive in the form of a Date, Time (including seconds) and by Who.
2. List the exact unchanged wording of the Dead Addenda including its Copyright Notice.
3. Be maintained and kept up to date with any expirations within this document.
4. Remain Open-Source during the duration of this License and after, for historical proof of usage History.
5. This can be versioned as long as all versions are linked.
6. Any other requirements are up to Addenda definition.

5.) Node System Mandated

Copyright Notice

Fields in Expiration marked Optional are only valid when EXPIRATION YEAR is set to NEVER, otherwise its required.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

© (DAY), (MONTH), (YEAR APPLIED) – (OPTIONAL DAY), (OPTIONAL MONTH), (EXPIRATION YEAR / NEVER)

(Organization or Holder)

Founder(s): (Founders)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Definitions

The following bolded terms when associated with a term in bold will be referenced back to throughout this Node System. In all cases it will explicitly-unless otherwise specified-mean the same thing as defined below.

Phrases

The following italicized terms when associated with a term in italics, within this Node System, will be meant to mean what is defined below when utilized. In all cases it will explicitly-unless otherwise specified-mean the same thing as defined below.

Nodes

(DEFINE HERE ALL NODES IN WHICH WILL APPLY TO THIS LICENSE)

• Document Order
  • This node makes it so that all Addenda are to be rendered in the case of conflict in the order by which they appear within the Effective License, the origin Addenda of the conflict takes precifice over the conflict causing Addenda
  • Node Position: -1

Resolution Order

(DEFINE HERE YOUR RESOLUTION ORDER, A SAMPLE IS PROVIDED BELOW, IT IS RECCOMENDED TO CHANGE IT TO HOW YOUR NODE POSITIONS ARE MEANT TO APPLY)

All Nodes are to be loaded from Least Node Position to Greatest Node Position.

6.) The Template for all Addenda's

Template Addenda (TA-1.0.0)

Copyright Notice

Fields in Expiration marked Optional are only valid when EXPIRATION YEAR is set to NEVER, otherwise its required.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

© (DAY), (MONTH), (YEAR APPLIED) – (OPTIONAL DAY), (OPTIONAL MONTH), (EXPIRATION YEAR / NEVER)

(Organization or Holder)

Founder(s): (Founders)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Definitions

The following bolded terms when associated with a term in bold will be referenced back to throughout this Addenda or children of this Addenda. In all cases it will explicitly-unless otherwise specified-mean the same thing as defined below.

Phrases

The following italicized terms when associated with a term in italics, within this Addenda or children of this Addenda, will be meant to mean what is defined below when utilized. In all cases it will explicitly-unless otherwise specified-mean the same thing as defined below.

Terms when applied as a License

Terms when applied as a Sub-License

Terms when applied as a CLL Sub-License

Shared Terms Across all License Types

Founder/Organization Unavailibility Specifications

Editing Specifications

Renewal Specifications

Expansion Specifications

Node-System Specifications

Scope Specifications

Purpose Specifications

Expiration Specifications

Other Specifications

7.) In-Usage Addenda's

Third-Party Addenda's

Organization Addenda's

Founder Addenda's

8.) Public Archival

The following is where the Public Archival of Dead Addenda are stored, I understand that if this is left empty ALL Dead Addenda must remain on this License and this License must therefore remain Archived even after its usage:

• LINK
• REPEAT THIS FOR ALL APPLICABLE LINKS

This marks the end of Super-unnecessarily-complex (SML-2.0.0)