Nick, The problem there is that innocent people can easily become confused into acting illegally through no real fault of their own. They see a gem at rubygems.org, a public repository, and tend to think that they're allowed to use the gem because it's released in a place where people release things to the public. Unless there is a license, however, under the law that may not be the case. Instead, some innocent programmer might download and use a gem from rubygems.org *illegally*, and *punishably under the law*. If it were * easy* and *well-known* how to check gem licenses *reliably*, especially for hundreds of gems at a time, as well as for all the gem dependencies of any particular gems a person wishes to use, the potential for this situation could be much reduced.
Additionally, people routinely need to check all the gems that their Ruby projects use are released under licenses compatible with their organizations' policies. This takes a whole lot of time and involves hundreds of trips to GitHub or locating and viewing hundreds of gems' readmes in Vim. The best solution here is capturing licenses in gem metadatas, and guiding gem authors to think about and declare the licenses under which they're publishing their gems. In our litigious New America, one may consider the practice of putting license information in gem metadata a new common courtesy, a form of politeness by gem authors to their gems' users, and an expected form of civility on the part of all who wish to partake in the civil environment of rubygems.org. Users do need to know that software comes with licenses, because that fact has legal ramifications. And software authors do need to know that they ought, as a common courtesy, to write down the license of any software they publish, because that also has legal ramifications to the benefit of all their users. The effect would be to help innocent users from accidentally breaking the law and to help all users be sure all the time that they are using gems with licenses in keeping with their organizations' policies. Indeed, we might even be able to write specs in our apps declaring that all gems used in our apps, from inspecting their metadatas, have been released with licenses whitelisted by the organization - with a build failure when someone adds a gem to an app that the organization hasn't whitelisted the license of. Cheers, Jay Feldblum On Thu, Oct 13, 2011 at 4:49 PM, Nick Quaranto <n...@quaran.to> wrote: > I don't want to police licenses from rubygems.org's end. Adding a flag on > push seems lame too...there's already a lot of "junk" most people don't > care > about filling out on the gemspec. > > On Thu, Oct 13, 2011 at 4:19 PM, Jon <jon.for...@gmail.com> wrote: > > > > To help prevent user errors, `gem build` and `gem push` should warn, > and > > > refuse if called without a `--force` or `--skip-license-check` flag, > when > > > building and pushing gems without a license listed. > > > > > > Should `gem push` if used with the `--host` option also warn and refuse > to > > work without a flag, and if yes, why do you think so? > > > > Jon > > _______________________________________________ > > RubyGems-Developers mailing list > > http://rubyforge.org/projects/rubygems > > RubyGems-Developers@rubyforge.org > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems RubyGems-Developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
