3 ms·

Slightly tangential, controversial thought: any source based package manager that doesn't enforce a legal right for the registry to forcefully take over maintai

Slightly tangential, controversial thought: any source based package manager that doesn't enforce a legal right for the registry to forcefully take over maintainance of published packages from their creators is doomed to have awful problems: neglect, malicious change, malicious removal, impostors... If a package is deemed important enough for the larger community, there needs to be a way to rip the package registry entry out of the original owner's hands and to make it point to a fork. Natually, such a move will often involve a lot of drama, but it can actively protect downstream users.

nerdponx 3y ago
The alternative is the Kik NPM problem. It's bad both ways.
vaylian 3y ago
> any source based package manager that doesn't enforce a legal right for the registry to forcefully take over maintainance of published packages from their creators ... This seems to be a non-issue. The beauty of open source is that you can fork it. The actual issue is that it requires time and effort to maintain an open source project and it's not easy to find someone else who has some time to spare.
- makerdiety 3y ago
  Yeah, finding free labor isn't light work. It's not trivial to externalize costs to unfortunate people. But the entities that succeed in this subjugation are the ones that are rewarded with some substantial wealth and power.
- gmueckl 3y ago
  No, there are issues in practice. I have seen many published libraries getting neglected by their creators. Unless the community is actively channeled in this case, the result is a set of lackluster forks by people who only make some random changes. As a potential new user, you don't know what to pick. In the worst case, you need to create another fork, because none of the existing ones fixed the issues you encounter. If you take that public, the mess only gets bigger. This chaos can be reduced with a single "blessed" fork that actively accepts reasonable maintainance patches. There are fewer incentives for competing forks and dependencies (direct and transitive) of the original package can automatically benefit, too, because releases are made under the original package name. This is good because the neglect problem can be several levels deep. There is the issue of manpower. There are two arguments here: one is that the bar for package takeover needs to be set such that community interest in a fork is high enough and the fork needs to be managed by the package registry owner for several reasons. One is that maintainers need to be appointed through the registry provider to keep the nodel functional. Maintainer appointments can be passed on after extended inactivity. The other argument is that a package registry provider puts themselves into a trusted position by default and has to actively maintain that trust. Thus, the burden of managing forks and fork maintainers shouldn't necessarily be seen as inappropriate.
JonChesterfield 3y ago
A source based package manager which steals ownership of its packages when it sees fit is one that should struggle to attract contributions. It appeals even less than the copyright model where all contributions are automatically owned by some specific group. Though an argument could be made that github is a host of free software dedicated to the copyright infringement of said software, at least it doesn't currently try to usurp the nominal ownership of the packages.
- gmueckl 3y ago
  Two counter arguments: The package registry entry isn't the package. At no time is the original creator deprived of their rights to their package. Any fork will have to respect whatever license the original creator assigned. Open source licenses are allow forking by design for a reason. Also, this whole thing needs to rest on a transparent process that doesn't make takeovers easy. There need to be clear criteria when takeovers can even be initiated, like extended inactivity (think 6 months or more) or unresponsive maintainers when serious issues are encountered. Also, there is not much harm in a mechanism for reclamation by the original package owner.
- pas 3y ago
  think of it as an NMU (non-maintainer upload) https://wiki.debian.org/NonMaintainerUpload https://wiki.debian.org/NonMaintainerUpload also, names in a registry should be "leased" not forever eternal perpetual immutable assigned to some guy
geodel 3y ago
> If a package is deemed important enough for the larger community, It may be done at package level at best but not at registry level. Since we are talking community it is not a customer/vendor relationship, most packages are just important enough to be available for free. It may also be at some humiliating amount like "here is 10 dollar/month now maintain 100K packages for us.
keybored 3y ago
The creators of Cargo didn’t want to have namespaces. That seems like the biggest mistake. Then you never get official-looking names just because they were the first ones to ask for them.
LadyCailin 3y ago
Not sure how this could actually work, what with trademark law and stuff. It would be extremely legally interesting.
- gmueckl 3y ago
  Well, every fork can get legally "interesting", depending on the circumstances. I don't see many additional complications here, but IANAL.
skybrian 3y ago
These problems aren’t all the same. A frozen package means downstream dependencies may need to make a decision, but they have plenty of options, including vendoring. There’s lots of source code on the Internet that’s not maintained; it’s just as-is, one-and-done. Nobody is guaranteed updates for free code.

nerdponx 3y ago

The alternative is the Kik NPM problem. It's bad both ways.

vaylian 3y ago

> any source based package manager that doesn't enforce a legal right for the registry to forcefully take over maintainance of published packages from their creators ... This seems to be a non-issue. The beauty of open source is that you can fork it. The actual issue is that it requires time and effort to maintain an open source project and it's not easy to find someone else who has some time to spare.

makerdiety 3y ago
Yeah, finding free labor isn't light work. It's not trivial to externalize costs to unfortunate people. But the entities that succeed in this subjugation are the ones that are rewarded with some substantial wealth and power.
gmueckl 3y ago
No, there are issues in practice. I have seen many published libraries getting neglected by their creators. Unless the community is actively channeled in this case, the result is a set of lackluster forks by people who only make some random changes. As a potential new user, you don't know what to pick. In the worst case, you need to create another fork, because none of the existing ones fixed the issues you encounter. If you take that public, the mess only gets bigger. This chaos can be reduced with a single "blessed" fork that actively accepts reasonable maintainance patches. There are fewer incentives for competing forks and dependencies (direct and transitive) of the original package can automatically benefit, too, because releases are made under the original package name. This is good because the neglect problem can be several levels deep. There is the issue of manpower. There are two arguments here: one is that the bar for package takeover needs to be set such that community interest in a fork is high enough and the fork needs to be managed by the package registry owner for several reasons. One is that maintainers need to be appointed through the registry provider to keep the nodel functional. Maintainer appointments can be passed on after extended inactivity. The other argument is that a package registry provider puts themselves into a trusted position by default and has to actively maintain that trust. Thus, the burden of managing forks and fork maintainers shouldn't necessarily be seen as inappropriate.

JonChesterfield 3y ago

A source based package manager which steals ownership of its packages when it sees fit is one that should struggle to attract contributions. It appeals even less than the copyright model where all contributions are automatically owned by some specific group. Though an argument could be made that github is a host of free software dedicated to the copyright infringement of said software, at least it doesn't currently try to usurp the nominal ownership of the packages.

gmueckl 3y ago
Two counter arguments: The package registry entry isn't the package. At no time is the original creator deprived of their rights to their package. Any fork will have to respect whatever license the original creator assigned. Open source licenses are allow forking by design for a reason. Also, this whole thing needs to rest on a transparent process that doesn't make takeovers easy. There need to be clear criteria when takeovers can even be initiated, like extended inactivity (think 6 months or more) or unresponsive maintainers when serious issues are encountered. Also, there is not much harm in a mechanism for reclamation by the original package owner.
pas 3y ago
think of it as an NMU (non-maintainer upload) https://wiki.debian.org/NonMaintainerUpload https://wiki.debian.org/NonMaintainerUpload also, names in a registry should be "leased" not forever eternal perpetual immutable assigned to some guy

geodel 3y ago

> If a package is deemed important enough for the larger community, It may be done at package level at best but not at registry level. Since we are talking community it is not a customer/vendor relationship, most packages are just important enough to be available for free. It may also be at some humiliating amount like "here is 10 dollar/month now maintain 100K packages for us.

keybored 3y ago

The creators of Cargo didn’t want to have namespaces. That seems like the biggest mistake. Then you never get official-looking names just because they were the first ones to ask for them.

LadyCailin 3y ago

Not sure how this could actually work, what with trademark law and stuff. It would be extremely legally interesting.

gmueckl 3y ago
Well, every fork can get legally "interesting", depending on the circumstances. I don't see many additional complications here, but IANAL.

skybrian 3y ago

These problems aren’t all the same. A frozen package means downstream dependencies may need to make a decision, but they have plenty of options, including vendoring. There’s lots of source code on the Internet that’s not maintained; it’s just as-is, one-and-done. Nobody is guaranteed updates for free code.