Make license/licenses field mandatory

Jay Feldblum y_feldblum at
Wed Oct 19 14:33:55 EDT 2011

The lawyers are crazy ... right up until someone gets sued.

The important questions in this thread are:

   1. What could do to make it easy for all of its users to do
   the right thing, and do the right thing by default?
   2. What should do in that regard?

The wrong thing is for gem authors to upload unlicensed gems or gems with
unusable licenses to a public gems-sharing website, and for gem users to
download and use those gems under the default assumption that it's ok (it's
not, and gem users need to understand that and pay attention to it). could guide its users towards uploading only licensed software
where knows about the license used (e.g. it's a SPDX license
tag). This would make it much easier for everyone who uses public gems to
find out about any potential copyright violations or breaches of contract in
which he happens to be engaged by accident, when he used a gem whose author
forgot to license. could also guide its users to knowing about
the licenses of every gem uploaded to it, by displaying the license name
(and a link to the license text) on the page for that gem and by permitting
the rubygems library to expose the license as gem metadata. This would mean
that *we*, the innumerable gem users out there, can *stop* having to deal
quite so much with the crazy lawyers.

We should don Rufio's mantle and do our part to reduce the size of the legal
profession by guiding gem authors to license their gems, and by guiding them
automatically to do so.

As an aside: note the prevalence of the word *guide* above. I mean should *guide*, but does *not* need to *force*, gem authors to
license their gems. The point is education, metadata, and the pit of
not dictatorship.

Jay Feldblum

On Wed, Oct 19, 2011 at 2:05 PM, Eric Hodel <drbrain at> wrote:

> On Oct 19, 2011, at 6:21 AM, Pavol Rusnak wrote:
> > On 18/10/11 22:34, Eric Hodel wrote:
> >>> * What if I want to publish my gem with no license?
> >>
> >> put "unlicensed" in the field
> >>
> >>> * ...with a personally crafted license?
> >>
> >> If you can't give a name to your license? ("beer ware" and "WTF"
> licenses are relatively new licenses that were given clever names.  If
> you're not creative like me then uou can have the "Eric Hodel license")
> >>
> >>> * the public domain?
> >>
> >> "public domain"
> >
> > Let me react on this part. Please, please, please do not use "public
> > domain", your own crafted license or no license. If you think you need
> > to, please rethink and don't use it! There are plenty of nice licenses
> > written by lawyers and software experts from which you can choose from.
> > If you use some "funny" license you are basically blocking your gem from
> > being used in some areas and my guess is you don't want this.
> RubyGems cannot stop authors from picking a license of their choice.
> > Some examples:
> >  - Public domain is not valid outside US
> Then if you want to use such software you'll need to make arrangements with
> the original author, it's not up to RubyGems to mediate.
> >  - Beerware makes your work non-redistributable (as a part of bigger
> >    FOSS project)
> FreeBSD contained PHK's malloc() and crypt() implementations (since
> replaced, not due to license) that are under the Beerware license.  Last I
> checked FreeBSD was a big FOSS project.  PHK's crypt() was also shipped in
> some Cisco products.  If you think you can't use PHK's beerware in your
> project, FOSS or otherwise, I think your lawyers are crazy.  The lawyers for
> FreeBSD and Cisco certainly aren't.
> See:
> _______________________________________________
> RubyGems-Developers mailing list
> RubyGems-Developers at

More information about the RubyGems-Developers mailing list