Hello everyone 👋

I’d like to introduce PTGPL v3, a copyleft license I’ve been working on for the past months.

In modern system-scale projects, it’s common to have both:

- network/service components (typically AGPL scope)

- reusable libraries (typically LGPL scope)

In practice, combining AGPL and LGPL can create significant boundary and compliance friction: unclear license boundaries, difficult compatibility, and the need for additional exceptions to make things work cleanly.

PTGPL v3 is an attempt to address this by unifying both models into a single license:

- AGPL-like network copyleft (modified software used to provide functionality over a network must offer source)

- LGPL-like library / combined work model (independent components can remain flexibly licensed)

- No need for additional exceptions to make the system coherent

It also expands the definition of Corresponding Source to include build, deployment, and configuration, aiming to ensure real reproducibility—not just access to code.

The license has been submitted to OSI for review. I’m sharing both the rationale and the license text for feedback.

I’d really appreciate technical and licensing feedback.

Mehmet Samet Duman

License steward, Project Tick

PART 1: RATIONALE AND NON-PROLIFERATION JUSTIFICATION

Rationale and Non-Proliferation Justification

Document purpose.

This document explains why Project Tick created the Project Tick General Public License v3 (“PTGPL”), what problem it solves that is not adequately addressed by existing OSI-approved licenses, and how PTGPL is designed to comply with the Open Source Definition (OSD) and OSI license review expectations.

Guiding constraints.

PTGPL was drafted under three constraints:

1. OSD compliance first. PTGPL must grant the core OSD freedoms: use for any purpose, study, modify, and redistribute, without discrimination.

2. Minimize ambiguity. Reduce “policy language” and subjective terms to lower compliance friction and improve community adoptability.

3. Avoid unnecessary proliferation. Create a license only if it provides a meaningful, concrete, and operationally testable improvement over existing licenses in the specific context of Project Tick.

4. Problem Statement: What PTGPL Must Achieve

Project Tick is building an OS-scale ecosystem spanning:

• operating system components and “Main Components” (kernel/userland/toolchain), and

• reusable “Library Work” components intended to be linked into independent programs.

This ecosystem has recurring friction with existing license choices because Project Tick needs a single coherent copyleft policy that simultaneously:

1. Closes the SaaS/Network distribution gap for modified versions without turning every network interaction into a vague compliance debate.

2. Defines “Corresponding Source” in a modern systems context, explicitly covering build and deployment/configuration material needed to reproduce, modify, and run a work, while excluding System Libraries and unrelated third-party components.

3. Permits widely used linking patterns (static/dynamic, ABI/API linking) without collapsing the entire combined system into one license, while preserving copyleft on the library itself and ensuring relink/replace capability.

4. Keeps enforcement simple and non-discretionary: no field-of-use restrictions, no “public hosting” mandates, no subscriber gating mandates, no identity-based conditions, no anti-enterprise clauses.

PTGPL is a systems-oriented license designed for reproducible, portable, redistributable software where “source” is more than a tarball of .c files: it is the coherent set needed to actually build, install, and run the work in a developer-usable form.

1A. Intended Adoption and Reusability

PTGPL is intended for first-party adoption within the Project Tick ecosystem,

including MNV, MeshMC, CoreBinUtils, and other Project Tick projects planned

for release or relicensing under PTGPL.

PTGPL is also offered as a generally reusable copyleft license for software

projects that share the same structural characteristics: network-deployed

modified works, reusable libraries intended to be combined with independent

software, and a need to express those reciprocity obligations in one license

text rather than through multiple adjacent copyleft licenses.

PTGPL is therefore presented as a license that is not structurally limited to

Project Tick, even though Project Tick is its initial intended steward and

first planned adopter.

1B. Drafting and Legal Review Status

PTGPL was drafted in the course of Project Tick’s internal architectural and

licensing work to address recurring compliance questions arising from network

deployment and reusable library composition.

The current legal review status of the text is straightforward: the draft was

prepared internally and has not yet been reviewed by outside counsel.

That status is disclosed here so that reviewers may assess the text with

appropriate context.

1. Why Not Use an Existing License?

OSI reasonably discourages new licenses when existing ones suffice.

Project Tick evaluated GPLv3, AGPLv3, and LGPLv3 because PTGPL is intentionally positioned in that family of copyleft licenses.

2.1 Why not GPLv3?

GPLv3 is excellent for distribution-based copyleft. However, GPLv3 does not uniformly trigger source-offer obligations when a modified work is operated over a network without distributing object code. In modern deployments, significant functionality is delivered as a service rather than shipped binaries. Project Tick’s goal is to ensure modifications remain shareable when value is delivered via network interaction, without inventing non-standard side agreements or governance mechanisms.

PTGPL addresses this through Section 3.2 (Network Interaction). Instead of stretching the traditional copyright definition of "Conveying", Section 3.2 establishes a direct condition: operating a modified work to provide functionality to users through a computer network requires an offer of Corresponding Source to those users. This mirrors the intent of AGPL’s remote network interaction clause without distorting core copyright terminology, while remaining consistent with PTGPL’s internal definitions and source scope.

2.2 Why not AGPLv3?

AGPLv3 solves the network interaction gap.

However, Project Tick’s ecosystem includes large quantities of linkable libraries intended for broad reuse. Using AGPLv3 across all such components can be over-restrictive for legitimate combined-work scenarios, and creates a tooling and compliance mismatch when some components are libraries and others are OS programs. Project Tick needed a single license whose text explicitly and consistently covers:

• modern definitions of Corresponding Source (including build + config material), and

• a library/combined-work model that preserves copyleft on the library while allowing independent works to remain independently licensed, provided relink/replace is possible.

PTGPL therefore integrates an explicit Library Work / Combined Work framework and a clear replacement/relink obligation for Combined Works (Section 8), while keeping the network copyleft trigger limited to modified versions used to provide network functionality. This combination is not provided by adopting AGPLv3 alone without adding external policy layers.

2.3 Why not LGPLv3?

LGPLv3 addresses library-linking scenarios well, but by itself does not create

a network-interaction source-offer obligation. Using LGPLv3 for libraries and

AGPLv3 or GPLv3 for the rest of a tightly related stack would require Project

Tick and downstreams to reason across multiple adjacent copyleft regimes and

their boundaries. PTGPL is intended to reduce that fragmentation by expressing,

in one text, both a network source-offer rule for modified deployments and a

library-combination rule for reusable components.

2.4 Summary: Why PTGPL is not merely a renamed existing license

PTGPL is not submitted as a renamed copy of GPLv3, AGPLv3, or LGPLv3. It is

submitted because Project Tick believes it combines, in one internally

consistent text:

• a network source-offer rule for modified versions;

• a reproducibility-oriented definition of Corresponding Source; and

• an explicit library/combined-work framework.

The claim advanced here is one of textual cohesion and compliance clarity,

rather than one of project-specific ideology or branding.

1. Design Choices That Reduce Ambiguity

PTGPL intentionally avoids language patterns that tend to create disputes:

• No mandatory public source publication. Source must be offered to the

relevant recipients or users when the License so requires, but PTGPL does

not require universal public hosting.

• No field-of-use restrictions. PTGPL permits use in all fields of endeavor,

consistent with OSD requirements.

• No discrimination against persons or groups. PTGPL contains no identity-based

restrictions.

• A concrete source-offer expectation for network use. Section 3.2 requires

that the source offer be made through a prominent and reasonably accessible

notice to the relevant network users.

1. OSD Conformance Mapping

This section maps PTGPL’s intent to OSD criteria.

1. Free Redistribution: PTGPL permits conveying copies, charging fees for physical transfer or services (Section 16), without restricting redistribution.

2. Source Code: PTGPL requires Corresponding Source for conveyed object code (Section 3) and defines Source Code as the preferred form for modification (Section 1).

3. Derived Works: PTGPL explicitly permits modification and conveying modified versions under the same license (Section 2).

4. Integrity of Author’s Source Code: PTGPL does not prohibit distributing modified source; it only requires prominent modification notices and dates (Section 2).

5. No Discrimination Against Persons or Groups: PTGPL contains no identity restrictions (Section 11).

6. No Discrimination Against Fields of Endeavor: PTGPL contains no field-of-use restrictions (Section 11).

7. Distribution of License: Downstream recipients receive rights automatically upon conveyance (Section 6).

8. License Must Not Be Specific to a Product: PTGPL is not tied to a specific product or platform; definitions are environment-agnostic.

9. License Must Not Restrict Other Software: PTGPL’s Combined Work model explicitly allows independent works to remain independently licensed, while enforcing obligations only on the Library Work and its modifications (Section 8).

10. Technology-Neutral: PTGPL imposes no technology-specific restrictions or delivery mechanisms.

11. Compatibility and Practical Compliance

5.1 Practical compliance: what a downstream must do (high level)

PTGPL is designed so downstream obligations are straightforward to implement:

• If you convey object code: provide Corresponding Source via one of the standard methods (Section 3).

• If you modify and operate the work over a network to provide functionality: offer Corresponding Source to the service users (Section 3.2), with an accessible notice.

• If you ship a Combined Work including a Library Work: keep the Library Work under PTGPL, provide its Corresponding Source, and enable relink/replace (Section 8).

5.2 Why “Corresponding Source” includes build/deploy config

In modern systems software, the ability to reproduce and modify is often blocked not by missing .c files but by missing build scripts, integration glue, packaging control files, and deployment configuration. PTGPL defines Corresponding Source to include the project-specific materials needed to build and run the work as intended, while excluding System Libraries and unrelated third-party components. This is intended to advance OSD #2 and OSD #3 in real operational terms, not merely theoretical access. Crucially, PTGPL does not attempt to claim ownership over a user’s proprietary

cloud infrastructure, generalized orchestration scripts, hardware provisioning definitions, or management planes (a common criticism of the Server

Side Public License). It strictly bounds "Corresponding Source" to the configuration specifically written to make the Work itself function, ensuring true

software reproducibility while respecting the user's independent system environments.

5.3 Illustrative compliance examples

The following simplified examples illustrate the intended operation of PTGPL:

Example A: modified network deployment.

If an operator modifies a PTGPL-covered service and uses that modified version

to provide functionality to users over a network, Section 3.2 requires that

those users be offered the Corresponding Source of that modified version under

PTGPL.

Example B: PTGPL library in a larger application.

If a PTGPL-covered Library Work is combined with an independent application,

the independent application is not automatically required to be licensed under

PTGPL merely because of that combination. However, the Library Work and any

modifications to it remain subject to PTGPL, and the recipient must be able to

modify and replace the Library Work as required by Section 8.

Example C: ordinary aggregation.

If a PTGPL-covered program is distributed alongside separate and independent

programs on the same medium, without derivation and without forming a Combined

Work as defined by the License, PTGPL applies only to the covered Work itself.

1. Why the OSI Should Consider PTGPL

OSI is right to treat new licenses skeptically. PTGPL is submitted only because

Project Tick believes it combines, in one text, obligations that otherwise

require multiple adjacent copyleft licenses and additional interpretation.

PTGPL is offered for consideration for the following reasons:

1. It combines a network source-offer rule for modified deployments and a

library-combination rule for reusable components in one license text.

1. It states Corresponding Source in reproducibility-oriented terms suited to

modern build, install, and run workflows.

1. It does not impose field-of-use restrictions, identity-based restrictions,

mandatory public publication, or business-model restrictions.

1. It is not structurally limited to Project Tick, even though Project Tick is

its steward and first planned adopter.

Project Tick therefore submits PTGPL as a proposed reusable copyleft license

for projects that need one coherent framework for network deployment,

reproducible corresponding source, and library-boundary reciprocity.

1. What PTGPL Is Not Trying To Do

To preempt common concerns in review:

• PTGPL is not intended to restrict commercial use, SaaS use, or enterprise use.

• PTGPL is not intended to require public hosting or deny subscription business models.

• PTGPL is not intended to impose additional contractual terms beyond the license itself.

• PTGPL is not intended to extend reciprocal obligations to independent works solely because they are combined with, aggregated with, or used alongside a PTGPL-covered Work, except to the extent expressly provided in Section 8.

1. Closing Statement

Project Tick respectfully submits PTGPL for review as a proposed copyleft

license intended to preserve the core OSD freedoms while addressing three

practical concerns in one text: network-deployed modified works,

reproducibility-oriented corresponding source, and reusable library

combination.

We welcome criticism both on OSD conformance and on whether PTGPL provides

enough practical distinctiveness to justify approval as a new license.