write up a Terms of use

[coilysiren]

from @qrush

This has been an open question since the start of the site and when RubyCentral came onboard. Every time a problem comes up with gems we say "wow we should have a terms of service that covers this".

I'd love a gist of what other similar services do (PyPi, CPAN npm), and I feel that RC needs to approve it.

Some questions it should cover: What is abusive behavior? (API access, squatting gem names, inappropriate names, etc)
What do we do when there is a conflict over a namespace?
How do we handle releasing a gem to someone?
What happens if a gem maintainer cannot be contacted?

There are more questions I'm sure I'm missing here.

[coilysiren]

There's also notes on the Trello board about creating an abuse page / reporting system, and a privacy policy

[coilysiren]

for reference

• PyPi's ToS https://github.com/pypa/pypi-legacy/blob/master/templates/confirm.pt
• NPMs http://blog.npmjs.org/post/93540308465/legal-stuff, https://www.npmjs.com/policies/conduct

[qrush]

We have a draft one that is under legal review right now! I can add you @lynnco. We should consider publishing them now I think too on GitHub, we can associate them on the site soon.

cc @dwradcliffe @evanphx @indirect

[ghost]

Some comments.

"Inappropriate names" can be problematic.

Take these:

https://rubygems.org/gems/fuck
https://rubygems.org/gems/fucking_favicons
https://rubygems.org/gems/fuckitruby
https://rubygems.org/gems/god
https://rubygems.org/gems/idiot
https://rubygems.org/gems/statwhore
https://rubygems.org/gems/test_bitch
https://rubygems.org/gems/tit

Linus called git git, which may be an "inappropate name" too. :-)

Then we also have joke projects that have a not so "problematic"
name like:

https://rubygems.org/gems/phuby

Anyway.

What do we do when there is a conflict over a namespace?

I think there were prior discussions. Ideally ruby itself
should allow one to designate additional namespaces but
I don't know if this will ever be added. Matz probably would
not like it if we could have many toplevel namespaces that
would be the same. But I personally would love to have some
way to designate a namespace "Foobar" that would be different
from someone else using the very same name. Then I could
modify that namespace, without tampering with the namespace
of someone else. But that would probably only be possible if
ruby itself would allow that.

So that leaves the alternative option here that people just
use or want to use the same name.

"configuration" is such a namespace that I very much like to
use for my own projects.

https://rubygems.org/gems/configuration

My configuration gem is different to that one though.

It would be nice if there could be some way to add NON-PRIMARY
namespaces here.

What I mean is this:

• If someone does:

"gem install configuration"

he will install the above gem. That is, the above gem is also
the primary one.

But perhaps we could also have something such as:

"gem install configuration --author shevy"

Just as example. This is of course also not ideal, I understand
this, but it would allow me to possibly put a gem project with
the same name - without it being the PRIMARY project. First
come, first serve, is ok, but I'd love to also be able to have
rubygems.org host these gems. Right now I host them on my own
via a ftp-site. On github, I think it is possible to also host
your own gems or at the least some add-ons (bundler allows you
to download these, if I remember correctly).

Dependencies may then, if this would be accepted one day, also
need some additional way to designate that one is to use
a non-primary source.

For instance:

gem 'configuration', author: :shevy

Or something like that, as example.

Anyway, the above is just an idea, I guess this would have to
be supported by several people so I don't assume that any of
this will come soon. Just my two cc here. (It may be a bit
complicated to show this gem with the same name - perhaps
also give people a way to look at non-primary gems, but I think
before I go and describe this idea more, it is probably just so far
fetched that it is not too useful to discuss it here right now.)

Perhaps ruby itself may have some stronger support for designated
namespaces; refinements sorta semi-go into that way, in the sense
that one could do... class-specific changes without requiring
them to be global changes. I have lots of ideas for that too,
different ones though, which perhaps I may add to the ruby
issue tracker.

How do we handle releasing a gem to someone?

You mean a new author?

Perhaps there could be some generic deadline... something like
10 years. Sounds a bit excessive perhaps but there are some
gems that seem mostly inactive since 2005 or so. Perhaps it
may require manual email too, or something like that - no idea.
Or it may be tied to the amount of downloads. If there is a
gem from 2005 that has 1000 downloads in total, then I guess
it should be freed or "freeable" very easily, without much
further email discussions, since it seems fairly unimportant
or minor.

What happens if a gem maintainer cannot be contacted?

Perhaps one should first define some deadline; and then depending
on whether someone not be contacted, to make the namespace
available for others. (One could also offer some way to let
people find out which namespaces are old and no longer in use;
or perhaps have people try to maintain some gem. That may also
be a possibility, so if it is +10 years old or something like
that and someone else wants to keep things updated, that should
be possible too. Perhaps freeze the last known version before
changes are done, so that people can still refer the old one
as well.)

Anyway! Just some ideas.

[afeld]

/cc http://help.rubygems.org/discussions/problems/411-rubygemsorg-toseula