Hacker News Reader

Comment by icameron | Hacker News Reader

This looks quite useful! Is uv a safer choice to use for deploying a python based project long term? I’m referring to the anaconda rug pull that happened- using it for managing dependencies about 5 years ago, but then they changed some rules so that any of my clients who are organizations with over 200 employees are no longer free to use anaconda. They must pay a commercial license

View on HN

uv is licensed under either MIT or Apache-2.0[0]

They can always stop developing or fork to a different license and all future work belongs under that license, but you can't back date licenses, so what exists is guaranteed Open Source. If you're super worried, you can create a fork and just keep it in sync.

But this is essentially true about any other OSS project so I wouldn't be concerned. As far as I'm aware, conda was never open sourced and had always distributed binaries.

[0] https://github.com/astral-sh/uv?tab=readme-ov-file#license

Just because something is open source doesn't mean it will be maintained. With uv there is the slight peculiarity that it's written in Rust rather than Python. So you need to count on there being an active group of Rust devs who care about Python.

Because it uses PyPI I'm happy to use it as a package manager and dev tool. The worst that can happen is I have to switch back to pip etc. But I wouldn't use it as package runtime dependency. Use pyinstaller for that.

The use case for this kind of trick I think is developer utility scripts in repos. I wouldn't want to tie any of my personal utils to uv. If it needs dependencies I'll just make a package, which is dead easy now.

The really great thing is that the inline metadata format is an accepted PEP spec, so even if uv goes down the tubes there will be other tools that can be dropped in to support it.

I think anaconda's rug pull was on the repository (you can still use packages from conda-forge for free).

uv just uses pypi, so it would be just a question of changing from uv to pip, poetry or whatever, all packages would still be coming from the same place.

As I understand it, relicensing is possible when a project has a Contributor Licensing Agreement (CLA) which says that you're signing over your copyright to your contribution to the project's owners. (Who will eventually be bought out by the worst rich person you can think of - Yes, him.)

I peeked in uv's contributing guide and issues and didn't see any CLA. In PyTorch the CLA was mentioned at the top of the contributing guide.

Although, there should have been a community fork of the last FOSS version of Anaconda. That's what happened with Redis, and Redis uses a CLA: https://github.com/redis/redis/blob/unstable/CONTRIBUTING.md...

Don't ever sign a CLA, kids. Hell, only contribute to copyleft projects. We get paid too much to work for free.

Not having a CLA prevents relicensing but open source licenses aren't revokable anyways.

That's not been tested much in the courts. Recent rulings suggest OSS at least has consideration and thus can't be blanket terminated without some justification, but the USC provides that justification (with some onerous requirements -- 2-10 years of notice, has to happen in a certain time window, ...), even for licenses stating irrevocability.

Reply on news.ycombinator.com