[License-discuss] Draft for discussion: Project Tick General Public License v2.0 (only)

[M.samet Duman]

Dear Pam,

Thank you for taking the time to provide such a detailed and substantive response. I genuinely appreciate the care you put into identifying concrete drafting issues and explaining why they matter from both a legal and OSI-approval perspective.

I want to be clear at the outset that I do not dispute your central point: drafting quality is not optional for OSI approval, and a license that has not been professionally drafted by a lawyer carries a very high risk of ambiguity, internal inconsistency, and unintended legal effect. That limitation is real, and I acknowledge it directly.

At the same time, I would like to clarify the intent behind the current text and respond to several of the specific issues you raised, not to argue that the draft is approval-ready, but to explain what the license is attempting to do and where the problems you identified arise from drafting technique rather than conceptual confusion.

First, regarding the preamble versus operative terms. I understand and agree with the principle that a well-drafted agreement should not place operative grants or obligations in the preamble. The intent here was not to create binding terms in the preamble, but to provide interpretive framing similar to that used in GPL-family licenses. That said, you are correct that duplicating concepts such as patent grants or future-version language in both the preamble and operative sections creates ambiguity risk. Any professionally revised version would need to strictly separate explanatory context from binding provisions.

Relatedly, the patent language appearing both in the preamble and in Section VIII was intended to operate at different levels: a high-level statement of existence versus a detailed operative grant. I accept your point that repeating grants, unless they are literally identical, is dangerous and can easily lead to conflicting interpretations.

On the issue of “future versions” versus “modified Works,” the intent was to distinguish between downstream derivative works conveyed by licensees and new versions independently released by the original copyright holder. As you correctly note, that distinction is not sufficiently explicit in the current text and creates an interpretive conflict as written.

With respect to the Explicit Network Use Notice mechanism, I want to emphasize that the design intent was not to create two licenses, but a single license with a licensor-controlled trigger for a narrowly scoped obligation. The goal was to avoid unconditional AGPL-style network copyleft while still allowing copyright holders to require source availability in network-service contexts when they affirmatively choose to do so.

That said, I fully acknowledge your point that the mechanism, as drafted, introduces significant compliance complexity and makes it difficult for users to determine which obligations apply. I also recognize the concern that, in practice, this can reasonably be perceived as creating two compliance regimes, which undermines clarity and adoption.

Regarding the definitions section, your criticism is well taken. The definition of “Compatible License” is insufficiently precise, and the definition of “Copyright” as written is flawed. You are also correct that definitions used throughout the document should be centralized rather than scattered across sections, except where a term is truly local in scope.

On the anti-gatekeeping and public-access provisions, the policy goal was to prevent models where source code is technically “available” but only to a restricted class of users, such as paying customers or contractual counterparties. I accept your point that, as drafted, these provisions may go beyond GPL requirements and risk overreach, including unintended implications around perpetual availability or internal lifecycle policies.

Finally, on technological measures, I appreciate your note that this section may actually be one of the more defensible parts of the license, and I agree that the question of reinstallability is an important and unresolved area in current copyleft enforcement.

In summary, I fully accept that the current text does not meet the drafting standards required for OSI approval and that professional legal redrafting would be essential for any serious approval attempt. At the same time, I hope it is clear that this draft is not casual or naive, but an attempt to explore unresolved issues around network-based operation, managed platforms, and practical copyleft enforcement in modern deployment models.

I appreciate the directness of your feedback and the seriousness with which you engaged with the text. Even where the conclusions are difficult, they are valuable.

Thank you again for your time and candor.

Best regards,  
Mehmet Samet Duman  
On behalf of Project Tick  
License Steward