Ah yes, woke, the word used to describe something disliked.
That's a misrepresentation of what's actually going on in the R4L project. Volunteers are enabling support for it within the kernel to allow for rust drivers in a way that explicitly does not require existing maintainers to change how they maintain their parts of the kernel. Maintaining rust support and the APIs consumed by Rust is the job of R4L and doesn't require any work from the existing maintainers who are allowed to make changes to their C that breaks Rust where the Rust will then be adjusted accordingly.
Unfortunately yes, they'll send you a C&D if you pop up on an Oracle lawyer's radar. A coworker of mine had a course named "Rust for JavaScript developers" and received a C&D from Oracle.
1. I can pin my json parser dependency and literally never update it again
2. And how many times have we seen 20 lines of C backfire with some sort of memory safety issue.
3. First off, i'd go out on a limb and say the number of attacks from a well-established (or even a naive one) rust json parsing library is dwarfed by the number of attacks from adhoc config parsers written in C with some overlooked memory safety issue.
4. Usually being the key word, tons of adhoc config formats have weird shit in them. With json (or yaml/toml) you know what you're getting into and you immediately know what you're able and unable to do.
It works great for 90% of use cases, but getting that last 10% to work is really really hard so Bun (and node 22 which supports the same thing with an experimental) just throws an error in those cases. The most notable thing is `require`-ing an async ESM module from CJS, because require is a synchronous call you cant just async-ify it trivially.
Mostly curious, why do you care about the readability of the generated JS? Surely if you need to debug something for a production bundle you can use source maps.
One thing I'm not sure about when reading their policy is what'll happen in another kik situation. If someone were to claim the scope Microsoft (for example) that had no relation to Microsoft and then Microsoft came along and wanted the scope what would happen?
If MS got the scope what would happen to the packages in that scope, or if MS didn't get it what is done to clearly communicate that this is an unofficial account (presumably) asking on MS' behalf? In this early on period I'd expect a lot of people to claim the scopes of notable companies and these companies might take issue with that if they choose to use jsr down the line.
We do intend to take a more editorial approach to scopes, and assign scopes to users in a way we think is more intuitive for end users of JSR. We have reserved some obvious scope names already, but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name).
So in the case that a user published "@cocacola/foo", previously published versions of "@cocacola/foo" would remain available indefinitely (unless they were found to be malicious), but we would likely be willing to assign ownership of the "@cocacola" scope to a representative from that brand/company if they asked for it and we could verify their identity. The original author of "@cocacola/foo" would need to publish the module going forward under a different scope.
> but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name).
It would be great to find a way of structuring these registries/repositories in a way so there wouldn't be any name collisions, and also avoid the built-in support for companies to take names away from individuals.
Thankfully JSR won't be capable of a left-pad situation where packages can be unpublished - published packages are immutable[1].
As for the potential for disagreements over whether or not a scope should be transferred, that is a big reason why we want to figure out community involvement in governance sooner rather than later. We are gathering potential volunteers who want to discuss becoming a community moderator - if anyone would be potentially interested, they can sign up to join that conversation[2].
2. Use some pre-existing centralized name registry (e.g. domain names).
I don't know why the JS ecosystem is so resistant to either solution. Both are proven options (#1 used by COM, #2 used by Java). They do mean longer package names, but surely that's a small price to pay for a resilient future-proof solution? And besides, who really cares about long dependency names and why?
In the example of "@cocacola/foo" would it allow for the "@cocacola/foo" package to be updated with new versions by the new owners? Or would the foo package essentially be archived and read-only from this point on?
Domain expiration is rare, and virtually only happens when the related projects are dead anyways; freeze existing packages (no more updates until the original key for the domain comes back online, with manual override by registry administrators for edge cases) and have a reasonable waiting period (a couple of months to a year) before allowing the new owner to use the namespace (with different project names within).
Use URN instead of just a domain name. A domain name (with some schema) is obviously a subset, but anyone who doesn't want or need one can then use uuid: URNs.
The XML ecosystem did it that way for namespaces, and I think that it is still the most flexible and the most future-proof approach, since you can always add new schemas as needed.
Not if the system is built for DNS first. If a company/individual/organisation has a domain name, they are expected to use the domain. It is much less of an issue if someone has kik.users.registry.com when the company publishes packages under kik.com.
Even with their constraints they could have made this nicer, especially around the default formatter. Always requiring an explicit formatter is a classic example of Java being unnecessarily verbose, `\{ ` already wasn't permitted by previous java compilers as it was an unknown escape sequence so we could have nicer templates for the stock formatting like "\{foo} bar".
People have reasons, personally I don't like placing the burden of a viral license on people. I don't write code to further a copy-left cause, I write it to build things and make it easier for other people to build things.
But by doing that, you don't protect the users. If a commercial entity writes software that depends on e.g. an LGPL library. Then I as a user totally benefit from the fact that is it LGPL. Maybe it can even allow me to update the dependency myself, be it for security reasons, or for compatibility reasons (I could patch something in the library that would make the whole project work on my machine).
By not using copyleft, you make it easier for others to make proprietary products with your code. But is that what you want? As a user, are you happier with a proprietary Windows or an open source Linux?
I think the problem with this argument is that you think the user wants the source code. I agree that would be great ideologically but 99.999% of the people using computers couldn't care less. Not just non-developers but even the best programmers would rather just pay money to not have to fix someone else's bugs. Nobody wants to waste their time replacing libraries. They just want to use software. If we're being pragmatic about what is good "for the user" then the best thing for the user is that there are as few obstacles as possible for developers to create products for the users to use.
If we consider the dichotomy of use the viral license or make no software, then the user will always prefer to have software that exists in proprietary form than having no software at all. If a company doesn't like GPL, they'll simply not use GPL code, and maybe not using GPL means their product is not viable anymore because they have to rewrite everything themselves, and now something that was going to be made isn't going to be made because they can't get free labor. Is that good? According to GPL and FOSS, yes. According to the user that wanted to use that piece of software, no.
I have to add this feels so awkward because every time there's a thread about AI you'll find someone saying that the fact that data is copy-able renders copyright a thing of the past, and then you turn around and you see GPL and no-no-no-no-NO! You want to copy MY source code, my LABOR, and use it for free in your proprietary products? That's completely unfair! And next week there's a new OpenAI lawsuit and everyone's like "if you didn't want to get scrapped, shouldn't have posted it on the internet." It's so awkward.
> I think the problem with this argument is that you think the user wants the source code.
I want the source code, so I want developers to push for copyleft. I am a developer, so I push for copyleft on my end, for the others who want the source code like me.
> even the best programmers would rather just pay money to not have to fix someone else's bugs
I regularly need to patch some (open source) software I use. I probably couldn't pay for it (not sure if anyone would fix it for me), so I don't have a choice. The proprietary alternative is that I just can't have the damn software fixed.
> If we're being pragmatic about what is good "for the user" then the best thing for the user is that there are as few obstacles as possible for developers to create products for the users to use.
When you make it as easy as possible for developers, you end up with ElectronJS crap and similar. With proprietary protocols, nobody can write a different client (e.g. to make it more accessible). I don't consider this good for the user.
> If a company doesn't like GPL, they'll simply not use GPL code, and maybe not using GPL means their product is not viable anymore
First, there is not only GPL. The weakest copyleft I know is MPLv2, which requires to share the modified files. If a company's product is not viable under those conditions, then that product is simply worthless.
Second, as an open source developer, I don't really give a shit if another company that is not paying me is not viable with my copyleft license. I am not working to help them make money while making the world less convenient for me.
> I have to add this feels so awkward because every time there's a thread about AI you'll find someone saying that the fact that data is copy-able renders copyright a thing of the past
It's not weird: I don't want AI to train from my code without permission. BigTech can abuse my licenses because they are too powerful for me to do anything about it. It's just a shameful workaround, and I am hoping that new licenses will come out that explicitly forbid ML training, so that I can update my licenses.
> everyone's like "if you didn't want to get scrapped, shouldn't have posted it on the internet."
I surely don't say that. People who say that have no idea how copyright works, there is nothing worth discussing there.
That's a misrepresentation of what's actually going on in the R4L project. Volunteers are enabling support for it within the kernel to allow for rust drivers in a way that explicitly does not require existing maintainers to change how they maintain their parts of the kernel. Maintaining rust support and the APIs consumed by Rust is the job of R4L and doesn't require any work from the existing maintainers who are allowed to make changes to their C that breaks Rust where the Rust will then be adjusted accordingly.
reply