Make license/licenses field mandatory

Jay Feldblum y_feldblum at yahoo.com
Thu Oct 13 14:51:17 EDT 2011


All,

Since rubygems.org is a public gem repository for gems released to the
public, it makes sense for rubygems.org to maintain a requirement that gems
pushed to it be licensed for use by the public. The only decent way
rubygems.org can enforce such a rule is by having the right fields in the
gemspec where authors can enter the name of the license. It makes sense for
rubygems.org to maintain a whitelist of licenses, and to require gem authors
who push to rubygems.org to use a license in the whitelist, with an optional
"escape hatch" where an author may be able to use a non-whitelisted license
but mark it as "a non-whitelisted open-source license".

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. The license does not
need to be a whitelisted license from rubygems.org, since many people
distribute packaged gem files privately which are not licensed to the
public, and even maintain their own private gem repository servers. Only
rubygems.org would have the whitelist, not `gem build` or `gem push`. This
will help ensure that new gems pushed to rubygems.org come with licenses so
*tooling* can know what the licenses are, but will not prevent building or
distribution of private gems.

Cheers,
Jay

On Thu, Oct 13, 2011 at 9:41 AM, Jon <jon.forums at gmail.com> wrote:

> On Thu, 13 Oct 2011 01:02:31 +0200
> Pavol Rusnak <prusnak at opensuse.org> wrote:
>
> > On 12/10/11 20:29, Jon wrote:
> > > Is it your perspective that the field is mandatory and the field's
> value must be something other than one of the following?
> > >
> > >   s.license = ""
> > >     - or -
> > >   s.licenses = []
> >
> > You can put s.license = "Proprietary", s.license = "Non-commercial" or
> > something similar if you don't want to use common FOSS license(s).
>
> Similar to other responses, I see value in making 'licences' mandatory for
> gem building, say
>
>   gem build sooper.gemspec
>   ERROR:  While executing gem ... (Gem::InvalidSpecificationException)
>       licenses may not be empty
>
> but I don't support specific content checks or effectively pushing
> organization specific policy decisions upstream into RG.
>
> I think it could be very useful if rubygems.org said "To help you catch
> accidental pushes and help us manage removals, if we see your gem's metadata
> has licenses =~ /SOME_PATTERN/ we'll skip deployment of your gem." Or
> whatever policy (potentially changed in the future) makes sense based upon
> real-world usage patterns.
>
> But as each gem's 'metadata' file can be slurped, analyzed and the gem
> black/white-listed according to an one's needs, I don't believe RG should do
> anything more than simply requiring 'licences' on build similar to requiring
> 'authors'
>
>
> > > If the field is not present and "correct", do you believe things
> similar to `gem build mygem.gemspec` should refuse to create a .gem?
> >
> > Yes. I think gem build foo.gemspec should refuse to create a gem when
> > both license and licenses are empty. (We might want to check also on gem
> > push, but that's probably not necessary).
>
> Agree on `build` but strongly disagree on `push` as (a) this type of policy
> constraint doesn't belong in RG, and (b) implementation could
> complicate/destabilize RG and, in the end, probably be easily subverted.
>
> Jon
>
> ---
> blog: http://jonforums.github.com/
> twitter: @jonforums
>
> Most people die of a sort of creeping common sense, and discover when it
> is too late that the only things one never regrets are one's mistakes.
>                                                           - Oscar Wilde
> _______________________________________________
> RubyGems-Developers mailing list
> http://rubyforge.org/projects/rubygems
> RubyGems-Developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>


More information about the RubyGems-Developers mailing list