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.for...@gmail.com> wrote: > On Thu, 13 Oct 2011 01:02:31 +0200 > Pavol Rusnak <prus...@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@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
