This, of course, only works on little-endian machines. On big-endian machines, c has to be bytereversed.
Interesting advantage of little endian!
This, of course, only works on little-endian machines. On big-endian machines, c has to be bytereversed.
Interesting advantage of little endian!
I think that’s actually an MIT license violation?
I think that's probably fine actually since the place they are distributing the binary from (Codeberg releases) has a copy of the licence easily available.
the MIT license has no requirements about avoiding ambiguity
Err yeah of course not. The issue with creating ambiguous or conflicting legal requirements is that they might not get applied how you'd like if it went to court. For example Amazon might fork Forgejo and keep it closed source, saying "we copied the individual source files and those are MIT licensed" and they might win. The license text doesn't have to say anything about that for it to be true.
The problem is that there's ambiguity if you add new code to those files because the file header says it is MIT licensed but the project licence says it is GPL3. It's contradictory.
I believe they could have resolved the issue by deleting the file headers and including a copy of the MIT license in LICENSE
with a note saying something like "Code at this commit is fully licensed under the MIT license which is reproduced here; subsequent code is licensed only under the GPL3. Both licenses must be respected."
But they haven't done that, and it doesn't seem like they've even thought about it.
Yeah... But that's even more confusing since they didn't change it to "MIT AND GPL3". So now the whole project is GPL3 but individual files are MIT?
I think they should speak to someone who understands copyright law.
Yes but it doesn't let you remove the MIT license:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Doesn't look like they are complying with those terms to me.
How did they get permission from all previous contributors to do this? It doesn't have a CLA. Seems sketchy.
It requires you to sign into a Microsoft account (which I assume most non-nerds do, given how hard they make it to avoid) and have hardware that supports it... But yes Windows enables full disk encryption by default now.
When you first sign in or set up a device with a Microsoft account, or work or school account, Device Encryption is turned on and a recovery key is attached to that account.
Oo hello. Didn't know that's what you were doing these days! Hope it goes well, though I'd be nervous about a realistic business plan.
Anyway, yeah bit too late for Python.
Well this isn't a standard library either then. But seeing as it is literally called that I'd say your unusually restrictive definition is nonsense.
I'm not sure hardware-based full disk encryption counts as a "highly specialized requirement". It's enabled by default on Android, iOS, Mac and even Windows usually. It's a basic requirement for businesses.
they wouldn’t have made a different tool altogether if it was really a 1:1 replacement
Why not? It's 10x faster.
I think it might have some other new features but you don't need to use those.
i doubt one person on the team could be using uv while everyone else sticks to pip
This is exactly what we do at work. There's no way I could convince everyone to switch to uv
so I just switch between them based on an environment variable.
It even supports random stuff like pip install --config-settings editable_mode=compat --editable foo
which is required for static tooling to work (e.g. Pyright).
Yeah...