New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Taking over and/or giving back Gems #429

Closed
YorickPeterse opened this Issue May 20, 2012 · 6 comments

Comments

Projects
None yet
5 participants
@YorickPeterse
Copy link

YorickPeterse commented May 20, 2012

It would be really nice if there was a way in both Rubygems.org as well as
Rubygems itself to pass on ownership of a Gem to another person. Currently there
are quite a few "troll" gems on Rubygems with perfectly valid named, this one
being a fine example: http://rubygems.org/gems/ftp.

In the current state this is already somewhat possible. A Gem author can simply
add other people to the list of authors and they can then push releases as well.
However, this requires manual action by the primary author, this doesn't work if
said author isn't active anymore. It also requires use of the API (if I'm not
mistaken) opposed to being able to use a web interface.

Looking back at this "ftp" example a way of doing this would be to allow users
to flag it. After enough flags (these might have to be verified to prevent
abuse) a user would be able to claim ownership (again this should be verified by
a group of people). Another way of preventing abuse would be to prevent this
process from happening if the Gem had a new release in the past N months, though
I fear people will then abuse that to prevent the system from being used (e.g. a
troll might keep pushing his gem just so people can't overtake it).

Another way of doing it would be to allow the author to mark his gem as "dead",
thus removing the need to flag it. The taking over process would still have to
be verified to prevent random people from over taking it and not doing anything
with it.

A side effect of this feature would be that installing a Gem that was taken over
might result in completely different code being installed compared to what was
installed before. To make this clear to developers Rubygems should display a
warning both on the website as well as installing a gem. This warning can be
something along the lines of "Warning: this gem has been taken over by X, please
ensure that it is still compatible with how it was before it was taken over".

@rking

This comment has been minimized.

Copy link

rking commented Jan 2, 2013

This definitely needs a solution.

The Ruby community patches around it by coming up with other names for gems, but this should be fixed.

@adkron

This comment has been minimized.

Copy link
Contributor

adkron commented Jan 18, 2013

👍

@rking

This comment has been minimized.

Copy link

rking commented Jan 18, 2013

Maybe there should be a core committee of peope with ownership-change rights that hears cases of abandonware.

This shouldn't happen.

@bf4

This comment has been minimized.

Copy link
Contributor

bf4 commented May 21, 2013

+1 on the idea of a committee. Also, why do we allow https://rubygems.org/gems/saikuro when the original author made https://rubygems.org/gems/Saikuro ?

@adkron

This comment has been minimized.

Copy link
Contributor

adkron commented May 22, 2013

Ownership changing is hard and could lead into some legal things. We would need rules for how long a gem has to go without being updated. Then do we have a waiting period where we contact the original author and wait for them to respond. Who would be on the committee? How much time would it take? Who owns the trademark on the name? How long can they hold that trademark? Who can they sue? Anyone thinking of hiring a lawyer yet?

It is easier to come up with a new gem name than to fight all the battles that come with this.

👎 on the committee making decisions.

@qrush

This comment has been minimized.

Copy link
Member

qrush commented Nov 28, 2014

Most current discussion about this is on #725, closing this issue.

@qrush qrush closed this Nov 28, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment