Can I Fork Astral Tools? Understanding the Licenses for uv, Ruff, and ty

Mar 20, 2026

I opened Hacker News and saw the headline: “OpenAI to acquire Astral.” My stomach dropped.

uv has become my go-to Python package manager. Ruff is the fastest linter I’ve ever used. ty is my new favorite type checker. Now OpenAI owns them all.

My first thought: “Am I locked into OpenAI’s ecosystem now?”

Then I remembered—these are open-source tools. But what does that actually mean? Can I fork them? What rights do I have?

The Problem: Corporate Acquisition Anxiety

When a big company acquires a beloved open-source project, the community panics. It’s happened before:

Oracle acquired MySQL → MariaDB fork was born
Oracle acquired OpenOffice → LibreOffice emerged
Sonatype acquired the project → Jenkins forked from Hudson

The pattern is consistent. Corporate acquisition creates uncertainty. The community worries about:

Future stewardship of critical tools
Potential license changes
Loss of community-driven development
Vendor lock-in

With Astral’s tools being so fundamental to modern Python development, the stakes are high. I needed to understand my rights.

The Answer: Yes, You Can Fork

I went straight to the source—the licenses themselves.

Ruff and ty are MIT licensed. That means:

You can fork, modify, and distribute freely
Commercial use is allowed
No copyleft requirements
Just preserve the copyright notice

uv is dual-licensed under Apache 2.0 AND MIT. You pick which one applies. Both permit:

Forking and modification
Commercial use
Distribution

The verdict: These licenses explicitly protect your right to fork.

Understanding the Licenses

MIT License (Ruff and ty)

The MIT license is beautifully simple. Here’s what it actually says in plain English:

You can:
- Use it commercially
- Modify it
- Distribute it
- Use it privately

You must:
- Include the original copyright notice
- Include the license text

You cannot:
- Hold the authors liable
- Use their trademarks without permission

No copyleft. No requirement to open-source your changes. You could fork Ruff, make proprietary modifications, and sell it. (Not that I recommend that—the community would not be pleased.)

Apache 2.0 License (uv)

Apache 2.0 is more verbose but still permissive. It adds one critical protection:

Additional protections:
- Explicit patent grant from contributors
- If you sue over patents, you lose your license

Additional requirements:
- Include NOTICE file if one exists
- State changes you made to files
- Preserve all copyright notices

The patent grant is significant. If Astral (now OpenAI) has patents related to uv, the Apache 2.0 license grants you a license to those patents. This protects you from patent litigation while using the software.

How to Fork Properly

Let me walk through a proper fork. I’ll use uv as the example since it has both licenses.

Step 1: Clone and Verify

git clone https://github.com/astral-sh/uv.git
cd uv

First, I check what license files exist:

ls -la LICENSE* NOTICE*

Output:

LICENSE-APACHE
LICENSE-MIT
NOTICE

Good. All three files are present.

Step 2: Understand the NOTICE File

The NOTICE file is required for Apache 2.0 projects. Let me check its contents:

uv - Python package installer and resolver
Copyright 2024 Astral Software Inc.

This product includes software developed at
Astral (https://astral.sh).

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

I must preserve this file in any distribution.

Step 3: Create Your Fork

# Rename the original remote
git remote rename origin upstream

# Add your fork
git remote add origin [email protected]:YOUR_USERNAME/uv-fork.git

# Push to your fork
git push -u origin main

Step 4: Document Modifications (Apache 2.0 Requirement)

Apache 2.0 requires you to state changes. I create a CHANGES.md file:

# Changes from Original

This fork is based on uv by Astral Software Inc.

## Modifications

### 2026-03-20
- Initial fork created
- [Future changes will be documented here]

For file-level modifications, I add comments:

# Copyright 2024 Astral Software Inc.
# SPDX-License-Identifier: Apache-2.0 OR MIT
# Modified 2026-03-20 by Your Name
#   - Description of changes made

Common Mistakes to Avoid

Mistake 1: Removing License Files

I’ve seen developers strip out license files to “clean up” their forks. This violates the license terms.

❌ Removing LICENSE files
❌ Removing copyright notices
❌ Removing NOTICE file (for Apache 2.0)

Keep them. It’s not just legal compliance—it’s giving credit where due.

Mistake 2: Ignoring the NOTICE File

For Apache 2.0 licensed code, the NOTICE file must be included in derivatives. This is often overlooked.

The NOTICE file should remain intact. If you add your own copyrighted content, you append it:

uv - Python package installer and resolver
Copyright 2024 Astral Software Inc.

This product includes software developed at
Astral (https://astral.sh).

---

Modifications Copyright 2026 Your Name
- Added feature X
- Fixed bug Y

Mistake 3: Not Stating Changes

Apache 2.0 requires marking modified files. I’ve seen forks that don’t do this.

From the license:
"You must cause any modified files to carry prominent notices
stating that You changed the files."

Use comments, a CHANGES file, or git commit messages—but document it somehow.

Mistake 4: Forking Without Community

A fork without users is just a repo. Before forking:

Check if a community fork already exists
Engage with other users on forums/Reddit/Discord
Consider contributing to an existing fork rather than starting fresh

The Python community is already discussing coordination:

"I'm just glad and grateful that uv and the other big Astral tools
are open-source and that the community can pick up the pieces if
things start falling apart. uv is a total game-changer for the Python
ecosystem and is too important to let it languish."

Why This Matters for the Python Ecosystem

These aren’t just any tools. They’re infrastructure.

uv replaced pip, pip-tools, poetry, and pyenv for many of us. It’s 10-100x faster. It solves dependency resolution problems that plagued Python for years.

Ruff replaced flake8, isort, pydocstyle, and multiple other tools. It’s written in Rust and is blazingly fast.

ty is positioning itself as a faster mypy alternative.

Losing these tools—or having them locked behind corporate gates—would set the Python ecosystem back significantly.

The licenses ensure this won’t happen.

What to Watch For

While the current licenses protect us, here’s what could change:

1. New versions could change licenses
   - Existing code stays under current license
   - Only new contributions would use new license

2. Trademark issues
   - You can't use "uv" or "Ruff" as product names
   - You'd need to rename your fork

3. Contributor license agreements (CLAs)
   - Future contributions might require CLAs
   - Check if a CLA exists before contributing

4. Stewardship quality
   - OpenAI might be great stewards
   - Or they might deprioritize non-AI use cases

The key insight: the code that exists today is permanently forkable. Only future contributions could have different terms.

Permissive vs. Copyleft Licenses

MIT and Apache 2.0 are “permissive” licenses. They allow proprietary derivatives. Contrast this with GPL:

Permissive (MIT, Apache):
- Fork → Keep closed source → Distribute commercially ✅

Copyleft (GPL):
- Fork → Must remain open source → Distribute ✅
- Fork → Keep closed source → Distribute ❌

Astral chose permissive licenses, which enables maximum adoption but also allows “take and don’t give back” scenarios.

Dual Licensing Explained

uv’s dual Apache-2.0 OR MIT licensing means you pick one:

You can use:
- Apache 2.0 → Patent protection, more requirements
- MIT → Simpler, no explicit patent grant

You pick one. You don't need to comply with both.

This is common for Rust projects (Rust itself is dual-licensed Apache-2.0/MIT).

The Bottom Line

Can I fork Astral tools? Yes, absolutely.

The MIT and Apache 2.0 licenses protecting these tools ensure the community can fork and continue development independently of OpenAI.

I don’t need to panic. I don’t need to migrate away from uv or Ruff. The licenses provide a permanent safety net.

If OpenAI becomes a bad steward, the community can fork. The tools are too important to the Python ecosystem to be held hostage by any single company.

For now, I’m watching and waiting. OpenAI might be great stewards—they’ve open-sourced significant AI tools before. But if things go south, I know my rights.

And that’s exactly how open source should work.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 uv - Python package installer and resolver
👨‍💻 Ruff - Fast Python linter
👨‍💻 Reddit: OpenAI to acquire Astral discussion
👨‍💻 MIT License - Open Source Initiative
👨‍💻 Apache License 2.0 - Open Source Initiative

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!