Relicensing limitation

[rmg]

On receipt of payment, Developer licenses Intellectual Property Rights in the Project, as well as any future contributions to the Project published to the Repository, to Sponsor and the public.

This reads to me like the original author would be prevented from forking and relicensing their own project, even if they would otherwise be allowed under the terms of the chosen license.

Is this an intentional part of the value of sponsoring a relicense that should be highlighted? Or an ambiguity to be addressed?

[kemitchell]

@rmg, thank you for this issue!

I'd like to share the way that I read the relevant language, but want to make absolutely clear that if you can read the language in a different way, that's my bad, not your bad, and I should revise the terms to avoid the ambiguity.

I read the license to apply only to:

1. currently published work
2. work that gets published later to the same repository

Once someone's paid for relicensing, that leaves the developer free to either:

1. keep pushing commits to the repo for the project, in which case they have to be licensed under the same permissive terms
2. fork their project to a different repository, and push new work there

If the developer starts working in a separate repository, they're free to create a new License Zero project for that new work.

That gives the developer total practical control over what future work, if any, they release under permissive terms.

It would be easy to say that no new work falls under the permissive license, but as a practical matter, I think many developers and sponsors will see relicensing as a transition from L0-mode to permissive-mode, and expect future contributions offered on the same project, in the same place, to come under the same terms.

To support that, fundamentally, someone or something has to decide whether new work on a project also gets permissively licensed. I don't think that I can write a rule in the relicense agreement that's clear enough to work well for all or nearly all projects and situations. Giving the sponsor final say begs abuse, so I give the developer final say. But to make sure that say is clear, the contract requires the developer to document their decisions clearly, by putting new work in the same repo or a new repo.