Hi Kim, thanks for creating the issue. I think it's fair to be more open about this.

I'll copy/paste my previous message via Signal that motivated this issue:

I've studied about this matter, and got quite a bit of advisory.

What I did was not a change of license - it's still BSD-3 Claude, and I have no intention to change it. I now understand that I actually hold the copyright of all the changes I merged over the years since I never signed a Contributor License Agreement - so it's within my right to be mentioned in the copyright. In fact, it seems the license doesn't acknowledge any of the contributors over the years, which they also hold the copyright of their changes, since they also didn't sign the CLA. We should add a "...and contributors" on each copyright line to be more accurate.

The license does have the Encode header in the first line, and the year, which states who created the project. I didn't drop that.

I'm happy to discuss this in the open (either issue or discussion), if you would like more community/exposure about this matter.

Rather than asking the license holder for consent, Marcello checked in with ChatGPT.

As I said on my previous message, I don't think I need to ask for permission when I already hold the copyright of my changes during those years. The idea was to reflect that. Also, notice on my previous message that we should also add "...and contributors".

(This is minor, but my name is Marcelo, not Marcello).

About the changes on: Kludex/uvicorn#2719, PyPI does put both "authors" and "maintainers" in the same category, I don't think it makes much difference, but since you felt it made sense to proper assign the roles, then I changed it back. I thought it wouldn't be a big deal.

I've requested the change be reverted: As the license holder, changes there require my consent.

I'm not changing the license content, I'm adding a copyright header.

I'm not changing the license content, I'm adding a copyright header.

Actually you raise a decent point there.

My feeling is that Copyright © 2018 Kim Christie, Marcelo Trylesinski & contributors. would strike a good balance.

As the author & license holder I'd at least expect "hey what do you think about..." for us to work through any changes collaboratively.

You removed my pypi ownership without request while both projects were under encode.

Although that's technically true for some hours, it was on the same day the transfer happened, and you had agreed on the transfer.

Your messaging on handover was oddly controlling. I don't really appreciate unnecessary attempts at optics control.

I asked you what was odd about it at the time, and that I would be happy to change the wording if I sounded ungrateful or anything that was not within your like.

Let's ensure maintainers are properly compensated.
Let's ensure works are properly attributed.
Let's ensure OSS digital infrastructure is well placed to serve the community.
Licenses should probably be meaningful.

We are in the same page.

My feeling is that Copyright © 2018 Kim Christie, Marcelo Trylesinski & contributors. would strike a good balance.

I'm happy with this. Legally speaking am I entitled to drop/change the "Encode" line?

I'm happy with this. Legally speaking am I entitled to drop/change the "Encode" line?

I've created this PR: #3043 - but it would be cool to know about the answer for the above.

My intent with 2 lines was to keep it clear that "Encode" was the first and author, and then having my name in second.

I think it's quite common to add an additional copyright holder when there's a new owner of the project, e.g., twbs/bootstrap#19936, and I don't think it requires the consent of existing license holders, though there is some legal ambiguity. I've seen this often enough that I am surprised to see this complaint.

I think the existing copyright line should be retained verbatim if a new line is added.

Alternatively, you could change the copyright line to "The Starlette Authors" and leave it at that. I think as the owner of "Encode", you can consent to that @lovelydinosaur, e.g., kubeflow/pipelines#5470.

Alternatively, you could change the copyright line to "The Starlette Authors" and leave it at that.

There's no such thing as "The Starlette Authors".
I am the author. It is my body of work.

I am also the license holder, and I'm not okay with the copyright being altered without consent.

• "I aSkeD CHaTGpT aND iT sAId Ok" is not a serious position regarding the license text change.
• "I removed @lovelydinosaur's PyPI ownership in an attempt to force a repo transfer" is not okay.
• "I listed myself as author, but I didn't mean it really. honest" is not okay.

What's so fucking frustrating here is that I've always been up for decentralising control here, and ensuring that whoever's maintaining the projects is in a good position to advocate for sponsorships. Marcelo has been fantastically consistent in his stewardship, so it's really tedious to have to set these things right.

I think as the owner of "Encode" , you can consent to that [...]

The license is copyrighted to Encode OSS Ltd. A UK limited company. No quotes.

There's no such thing as "The Starlette Authors".

There are 300 contributors to this project and they have not signed a CLA. They are all copyright holders for this project under the license. Are you saying they are not?

Are you picking at the word "author" specifically? — I merely used that as an example as it matches the change to the Kubeflow license which was certainly vetted by a Google legal team. I don't really mind what the word is.

Marcelo has been fantastically consistent in his stewardship [...]

Thanks.

so it's really tedious to have to set these things right.

I understand. I've reverted the changes on the license so we can focus more on the side of "what are the changes on the license that would reflect better the contributors?"

"I aSkeD CHaTGpT aND iT sAId Ok" is not a serious position regarding the license text change.

This upper/down case seems a bit rude if I understand the intention correctly, but okay. On this point, the suggestion from the LLM seemed valid, and again, after reading a bit more, and getting to talk to someone that understand more about the matter (as I mentioned on the first comment here), it still seems a valid change. I think the problem is more fundamental: the license needs to reflect the contributors.

"I removed @lovelydinosaur's PyPI ownership in an attempt to force a repo transfer" is not okay.

On the PyPI topic, I should probably have waited a bit, but you had agreed with the transfer - which in my understanding it also includes PyPI, otherwise why would you have PyPI rights but not GitHub?

On the more constructive side, you suggested the following above:

My feeling is that Copyright © 2018 Kim Christie, Marcelo Trylesinski & contributors. would strike a good balance.

But then the difference from what I did is the:

• replace Encode -> Kim Christie
• add "& contributors"

So it seems you would be okay to drop the reference to Encode (and that's something I can't really do without the consent of Encode).

Would you instead prefer the following, then?

Copyright © 2018, Kim Christie and contributors
Copyright © 2025, Marcelo Trylesinski and contributors

This one explicitly expresses the years of ownership.

I understand. I've reverted the changes on the license [...]

Thanks yep.

I'll have a think regarding your suggestions.

This is interesting, and I am still learning about copyright and OSS because the subject is too vast.
Well this is also surprising as I thought that adding copyright holders was already part of the discussion. And it turns out that this issue has arisen.

There are 300 contributors...

I think not all automatically has copyright. Do you consider typo fixes and other trivial contributions to have copyright? See: https://en.wikipedia.org/wiki/Threshold_of_originality
It is safer to confidently put our own (c) if the contribution is, for example, a new complete file that has been added.

While the change might be legally defensible, from Tom/Kim’s perspective it feels ethically inappropriate and personally hurtful.

It might be different when we are creating a fork or a new brand, where it is still elegant to add a holder without consent. It reminds me of MariaDB, which is a fork of MySQL:

/* Copyright (c) 2000, 2014, Oracle and/or its affiliates
   Copyright (c) 2009, 2020, MariaDB Corporation

Without denying the significant contributions of Marcelo and 300 others, the fact that Tom has been so flexible so far is remarkable. I tend to keep people like this from getting upset.

I hope yous can find a win-win solution for this. Without putting either side at fault.

Been getting pinged on github and thought I'd leave my 2c.

Early adopter of Starlette back in 2019 up to 2023, it's been heartbreaking to see where Starlette and Uvicorn ended up.

I highly appreciate Kim/Toms work and legacy for pioneering asyncio python for the web. Starlette and Uvicorn laid tons of important foundations and cool patterns to approach these problems.

Starlette has been touched by many hands but this really is Kim/Toms baby in the end and they should have the final say in any copyright or licensing- anything else feels like co-opting what is mostly Kim/Toms work.

it's been heartbreaking to see where Starlette and Uvicorn ended up.

I've been a maintainer for 5 years (3 of those you mention), and I tried to replicate Kim's philosophy over all those years. That's why we don't have many breaking changes over the years. Saying it's "heartbreaking" is a bit too much for the love I have given to those projects.

[...] they should have the final say in any copyright or licensing [...]

As per how open source works, each contribution holds their own copyright, since no one signed a CLA. Which means, everyone has the right to be mentioned in a way or another on the license.

I think this issue has been extended enough. Given the respect I have for Kim, I don't see the point on dragging this longer. The license stays as is.

Starlette and Uvicorn have evolved so little over that period of time you could revert to pre-2023 and have nearly identical projects (minus dozens of little dependency bumps/readme edits). Sure, some smaller bug PR's were merged in that time (getting rid of anyio was nice, never should have happened), but you're acting like you started the project (Kludex/starlette ... Kludex/uvicorn ...ok) when this is all just stolen authorship.

I never acted like that.

Starlette and Uvicorn have evolved so little over that period of time you could revert to pre-2023 and have nearly identical projects

And isn't it nice? 🤷‍♂️

I never tried to steal anything. In fact, the discussion of moving th projects happened multiple times before it actually happened.

The other course of action would have been forking those projects. I was not happy. How would that be better?

@gnat Comments like yours, make it seems that the hours that I spent in those project were not useful for the community. Which doesn't seem fair. Security advisory reviews, replying in discussions and issues, reviewing PRs, making sure the projects are stable (which is what people prefer from those projects), isn't it not work?

I never say I created those projects in any circunstance. In fact, I do correct people every time they make such a mistake.