tag:help.rubygems.org,2010-01-19:/discussions/problems/411-rubygemsorg-toseulaRubyGems.org: Discussion 2017-05-31T04:02:41Ztag:help.rubygems.org,2010-01-19:Comment/38415962010-11-17T07:10:58Z2010-11-18T05:35:01Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>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.</p>
<p>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.</p>
<p>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.</p></div>John Barnettetag:help.rubygems.org,2010-01-19:Comment/38415962010-11-17T17:49:32Z2010-11-17T17:49:32Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>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:</p>
<p>Chad:</p>
<p>We could probably get a lawyer to<br />
help craft something. We've worked with Cooley Godward before. I<br />
think it is a good idea for gemcutter to have a ToS and trying to<br />
write it ourselves with no help might be a mistake. Rich and David,<br />
what do you think?</p>
<p>David:</p>
<p>My main priority would be to disclaim all liability of any kind<br />
whatsoever for Ruby Central and its directors and employees and anyone<br />
else who might get caught in the middle. I would want something like,<br />
"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.</p>
<p>Beyond that -- in practical terms -- my reaction to the arbitration<br />
board is that it may be a good idea but I would hate to be on it :-)<br />
That's more a measure of me than anything else, I imagine.</p>
<p>I agree that we should consult a lawyer and make sure that whatever we<br />
do, we do right.</p></div>John Barnettetag:help.rubygems.org,2010-01-19:Comment/38415962010-11-17T17:50:13Z2010-11-17T17:50:13Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>Amen. I wish it wasn't necessary, but we're running out of luck trying to do everything by consensus. See <a href="http://help.rubygems.org/discussions/problems/406-zentest-vs-autotest-zentest-without-autotest">http://help.rubygems.org/discussions/problems/406-zentest-vs-autote...</a> 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?</p></div>John Barnettetag:help.rubygems.org,2010-01-19:Comment/38415962010-11-17T18:09:03Z2010-11-17T18:09:03Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>Ongoing rubygems-developers discussion: <a href="http://rubyforge.org/pipermail/rubygems-developers/2010-November/005809.html">http://rubyforge.org/pipermail/rubygems-developers/2010-November/00...</a></p></div>John Barnettetag:help.rubygems.org,2010-01-19:Comment/38415962010-11-17T18:37:30Z2010-11-17T18:37:30Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>A ToS protecting you guys from liability makes perfect sense. Go for it.</p>
<p>I think most people dislike and don't read EULAs.</p>
<p>That autotest thread came to a reasonable resolution. I'd suggest instead adding a FAQ:</p>
<p>Q: Somebody used the name of my project! Will you transfer ownership of a gem to me?<br />
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.</p></div>Dan Croaktag:help.rubygems.org,2010-01-19:Comment/38415962010-11-17T18:46:46Z2010-11-17T18:46:46Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>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.</p></div>John Barnettetag:help.rubygems.org,2010-01-19:Comment/38415962010-11-18T05:12:58Z2010-11-18T05:12:58Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><ol>
<li><p>We can't violate licenses - that means we cannot transfer <em>code</em> ownership, ever. Similarly we cannot invoke terms that are not part of the license.</p></li>
<li><p>We own the gem namespace for any gems pushed to rubygems.org, not gem authors. Otherwise we cannot provide arbitration.</p></li>
<li><p>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.</p></li>
<li><p>We should not remove old namespaces except in cases of serious abuse:<br />
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).</p></li>
<li><p>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.</p></li>
<li><p>Authors / namespace owners involved in a discussion cannot vote in that discussion.</p></li>
<li><p>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.</p></li>
<li><p>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 <em>n</em>x 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 <em>registered</em> 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.</p></li>
</ol></div>James Tuckertag:help.rubygems.org,2010-01-19:Comment/38415962010-11-18T05:17:40Z2010-11-18T05:17:40Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>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.</p></div>John Barnettetag:help.rubygems.org,2010-01-19:Comment/38415962010-11-18T05:19:05Z2010-11-18T05:19:05Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>yes indeed, me too</p></div>James Tuckertag:help.rubygems.org,2010-01-19:Comment/38415962010-11-18T22:59:15Z2010-11-18T22:59:15Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>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.</p></div>Eric Hodeltag:help.rubygems.org,2010-01-19:Comment/38415962010-11-19T06:37:08Z2010-11-19T06:37:08Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>Ok, I'm open to suggestions as to how we can define this correctly / strictly?</p>
<p>Does this apply to named forks?</p>
<p>What about pure/vs non pure, etc?</p></div>James Tuckertag:help.rubygems.org,2010-01-19:Comment/38415962011-04-22T18:13:46Z2011-04-22T18:13:46Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>We need to keep moving on this.</p>
<p>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.</p>
<p><a href=
"http://help.rubygems.org/discussions/problems/565-posterous-ruby-gem-reclaiming-the-name">
http://help.rubygems.org/discussions/problems/565-posterous-ruby-ge...</a></p></div>Eric Hodeltag:help.rubygems.org,2010-01-19:Comment/38415962012-03-06T04:48:41Z2012-03-06T04:48:42Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>Hay, everyone if you want to know dmca process so you can visit
to this website dmcanow.com. Because i had also get information
about dmca process and i have very impressed</p>
<p><a href=
"http://www.dmcanow.com/about-dmcanow/">http://www.dmcanow.com/about-dmcanow/</a></p></div>maisiesherwintag:help.rubygems.org,2010-01-19:Comment/38415962012-08-04T18:06:44Z2012-08-04T18:06:44Zrubygems.org Terms of Service, DMCA process, and conflict resolution<div><p>Let's pick this up again. Where are we at? Can we just post
one?</p></div>Nick Quaranto