Terms of Service, DMCA process, and conflict resolution

John Barnette's Avatar

John Barnette

17 Nov, 2010 07:10 AM

We need a TOS that, along with the normal set of legalese, sets out an arbitration process. We need to figure out what that process is going to be, and find a gullible lawyer to help write it.

I pinged Chad earlier today to get some advice from him on this, and I'm going to drag him in to this ticket. James has thought more about this than any of the maintainers so I'm adding him as well.

I'm inclined to have a pretty simple setup where it's the RubyGems maintainers (Eric, Evan, me), Nick as the creator of Gemcutter, and an outside Ruby person with a lot of community exposure. Please share your thoughts.

  1. 1 Posted by John Barnette on 17 Nov, 2010 05:49 PM

    John Barnette's Avatar

    I pinged Chad Fowler (who pinged David Black and Rich Kilmer) about this. I've asked them to join this discussion as well. Here's a brief excerpt from our email exchange:


    We could probably get a lawyer to
    help craft something. We've worked with Cooley Godward before. I
    think it is a good idea for gemcutter to have a ToS and trying to
    write it ourselves with no help might be a mistake. Rich and David,
    what do you think?


    My main priority would be to disclaim all liability of any kind
    whatsoever for Ruby Central and its directors and employees and anyone
    else who might get caught in the middle. I would want something like,
    "People shouldn't do such-and-such with your software, but even if they do, you can't come after us." I think that's very important.

    Beyond that -- in practical terms -- my reaction to the arbitration
    board is that it may be a good idea but I would hate to be on it :-)
    That's more a measure of me than anything else, I imagine.

    I agree that we should consult a lawyer and make sure that whatever we
    do, we do right.

  2. 2 Posted by John Barnette on 17 Nov, 2010 05:50 PM

    John Barnette's Avatar

    Amen. I wish it wasn't necessary, but we're running out of luck trying to do everything by consensus. See for some very recent motivation. As much as you don't want to be on it, I think that you, Chad, Rich, or Jim would be the best choices from outside the active RubyGems maintainers. Maybe a rousing four-way game of paper-rock-scissors?

  3. 3 Posted by John Barnette on 17 Nov, 2010 06:09 PM

    John Barnette's Avatar
  4. 4 Posted by Dan Croak on 17 Nov, 2010 06:37 PM

    Dan Croak's Avatar

    A ToS protecting you guys from liability makes perfect sense. Go for it.

    I think most people dislike and don't read EULAs.

    That autotest thread came to a reasonable resolution. I'd suggest instead adding a FAQ:

    Q: Somebody used the name of my project! Will you transfer ownership of a gem to me?
    A: Please contact the owner of the gem and see if they'll transfer ownership or come to another resolution. Rubygems does not have an arbitration board. Do your best to work it out amongst yourselves amicably. Please be nice.

  5. 5 Posted by John Barnette on 17 Nov, 2010 06:46 PM

    John Barnette's Avatar

    Dan, if we were doing this speculatively, I'd be totally fine with adding that FAQ. In fact, I agree that we should add a "Matz Is Nice So We Are Nice" FAQ about dealing with conflicts without appealing to authority. Based on the difficulties we've had with the autotest issue above and a few others, though, I really think we should have a place to go when everything gets pear-shaped.

  6. 6 Posted by James Tucker on 18 Nov, 2010 05:12 AM

    James Tucker's Avatar
    1. We can't violate licenses - that means we cannot transfer code ownership, ever. Similarly we cannot invoke terms that are not part of the license.

    2. We own the gem namespace for any gems pushed to, not gem authors. Otherwise we cannot provide arbitration.

    3. We delegate responsibility for specific gem namespaces to particular users under a responsible maintenance contract - that is we provide free hosting for software that is being maintained in a responsible manner. We cannot force people to do work, but if someone dies or they are unresponsive for an extensive period of time (we need to define that time range specifically), then we may vote to recover, replace or remove namespace ownership for future releases in that namespace.

    4. We should not remove old namespaces except in cases of serious abuse:
      a) DMCA takedown b) Data volume abuse (max 200mb gems? we have some 120mb at the moment, I don't think we really want to host those either - they're mistakes as is - maybe aim for 50mb by end of year?). c) Privacy or malware violations (extconf.rb / mkrf -> zip and ship ~ or /etc/shadow or the like).

    5. If we do remove a portion of the namespace, we should remove dependent namespaces also - for example, if a depends on b and c, and we get a DMCA for c, we should takedown versions of a that depend on c. Those versions may be allowed to be re-released not dependent on c. This would be the only special case for re-release of existing versions.

    6. Authors / namespace owners involved in a discussion cannot vote in that discussion.

    7. Discussions that are not legally bound or are not covered by our terms are not to be hosted in our discussion forums. We may discuss those issues from the point of view of coverage, but we should be not seen to be supporting non-legal and out of context discussions. If we do do this, it will raise a feeling of bullying and could be socially engineered by one side.

    8. Gem namespaces are not trademarks. This is quite an issue in general - authors want to be free to write and publish useful software. There is no central registry for all nx and windows binaries and clobbers do occur quite regularly. Authors own a gem namespace when they take a gem namespace, not just for authoring something else in a different namespace or elsewhere. That being said, legal takedowns for registered trademarks are something we have to respect, within reason. You can leave notes in license and application documentation attributing registered trademarks to their respective owners and making it clear that the trademark is not part of the project and is not related to the owner in any way. This is common in documentation and literary writings, and the cases apply to software and software documentation too.

  7. 7 Posted by John Barnette on 18 Nov, 2010 05:17 AM

    John Barnette's Avatar

    Really good start. Re your point 4, we need to have the DMCA takedown notice stuff published somewhere, even though I hope we never have to use it.

  8. 8 Posted by James Tucker on 18 Nov, 2010 05:19 AM

    James Tucker's Avatar

    yes indeed, me too

  9. Support Staff 9 Posted by Eric Hodel on 18 Nov, 2010 10:59 PM

    Eric Hodel's Avatar

    Gems cover the require namespace as well as the gem name namespace, so I think we need an expansion of 3 to cover a case like autotest where a gem was split off with a different name that overlaps a more-established gems' require namespace.

  10. 10 Posted by James Tucker on 19 Nov, 2010 06:37 AM

    James Tucker's Avatar

    Ok, I'm open to suggestions as to how we can define this correctly / strictly?

    Does this apply to named forks?

    What about pure/vs non pure, etc?

  11. Support Staff 11 Posted by Eric Hodel on 22 Apr, 2011 06:13 PM

    Eric Hodel's Avatar

    We need to keep moving on this.

    Posterous has started the process for claiming its namespace from a gem author not associated with the company. It would help if I had a document to point to saying "we respect trademark", etc.

  12. 12 Posted by maisiesherwin on 06 Mar, 2012 04:48 AM

    maisiesherwin's Avatar

    Hay, everyone if you want to know dmca process so you can visit to this website Because i had also get information about dmca process and i have very impressed

  13. Support Staff 13 Posted by Nick Quaranto on 04 Aug, 2012 06:06 PM

    Nick Quaranto's Avatar

    Let's pick this up again. Where are we at? Can we just post one?

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac