From prusnak at opensuse.org Wed Oct 12 09:54:28 2011 From: prusnak at opensuse.org (Pavol Rusnak) Date: Wed, 12 Oct 2011 15:54:28 +0200 Subject: Make license/licenses field mandatory Message-ID: <4E959C14.6080704@opensuse.org> Hi all! I'd like to propose making license/licenses field mandatory. While doing rubygem packages for Linux distributions we have to deal with licenses a lot and currently not having a license field in gemspec is the only thing stopping us from doing automated packaging. One has to unpack the gem, search for the license text and change the field by hand. If these fields were mandatory (i.e. one or the other), it would make the whole process much easier. In my opinion the license is very important aspect of the gem similarly important as its name and I think also non-Linux parts of Ruby ecosystem would benefit from that change. What do you think? -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic From steve at steveklabnik.com Wed Oct 12 11:07:02 2011 From: steve at steveklabnik.com (Steve Klabnik) Date: Wed, 12 Oct 2011 11:07:02 -0400 Subject: Make license/licenses field mandatory In-Reply-To: <4E959C14.6080704@opensuse.org> References: <4E959C14.6080704@opensuse.org> Message-ID: I wouldn't be opposed to this. I hate forgetting such things, and it is important.... From jim.weirich at gmail.com Wed Oct 12 12:26:19 2011 From: jim.weirich at gmail.com (Jim Weirich) Date: Wed, 12 Oct 2011 12:26:19 -0400 Subject: Make license/licenses field mandatory In-Reply-To: <4E959C14.6080704@opensuse.org> References: <4E959C14.6080704@opensuse.org> Message-ID: This is a good idea as long as it is mandatory at the gem creation time, not at the gem usage time. On Oct 12, 2011, at 9:54 AM, Pavol Rusnak wrote: > Hi all! > > I'd like to propose making license/licenses field mandatory. While doing > rubygem packages for Linux distributions we have to deal with licenses a > lot and currently not having a license field in gemspec is the only > thing stopping us from doing automated packaging. One has to unpack the > gem, search for the license text and change the field by hand. If these > fields were mandatory (i.e. one or the other), it would make the whole > process much easier. In my opinion the license is very important aspect > of the gem similarly important as its name and I think also non-Linux > parts of Ruby ecosystem would benefit from that change. What do you think? > > -- > Best Regards / S pozdravom, > > Pavol RUSNAK SUSE LINUX, s.r.o > openSUSE Boosters Team Lihovarska 1060/12 > PGP 0xA6917144 19000 Praha 9 > prusnak[at]opensuse.org Czech Republic > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers -- -- Jim Weirich -- jim.weirich at gmail.com From nick at quaran.to Wed Oct 12 13:43:50 2011 From: nick at quaran.to (Nick Quaranto) Date: Wed, 12 Oct 2011 13:43:50 -0400 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> Message-ID: I bet this might cut down on delete requests we get too, since someone pushing an internal gem may opt to not have a license. Then again, authors of the popular gem generators (say, Bundler) may set the default to an OSS license, making the check moot anyway :( On Oct 12, 2011 1:19 PM, "Jim Weirich" wrote: > This is a good idea as long as it is mandatory at the gem creation time, > not at the gem usage time. > > On Oct 12, 2011, at 9:54 AM, Pavol Rusnak wrote: > > > Hi all! > > > > I'd like to propose making license/licenses field mandatory. While doing > > rubygem packages for Linux distributions we have to deal with licenses a > > lot and currently not having a license field in gemspec is the only > > thing stopping us from doing automated packaging. One has to unpack the > > gem, search for the license text and change the field by hand. If these > > fields were mandatory (i.e. one or the other), it would make the whole > > process much easier. In my opinion the license is very important aspect > > of the gem similarly important as its name and I think also non-Linux > > parts of Ruby ecosystem would benefit from that change. What do you > think? > > > > -- > > Best Regards / S pozdravom, > > > > Pavol RUSNAK SUSE LINUX, s.r.o > > openSUSE Boosters Team Lihovarska 1060/12 > > PGP 0xA6917144 19000 Praha 9 > > prusnak[at]opensuse.org Czech Republic > > _______________________________________________ > > RubyGems-Developers mailing list > > http://rubyforge.org/projects/rubygems > > RubyGems-Developers at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > -- > -- Jim Weirich > -- jim.weirich at gmail.com > > > > > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From docwhat at gmail.com Wed Oct 12 14:14:39 2011 From: docwhat at gmail.com (=?iso-8859-1?Q?Christian_H=F6ltje?=) Date: Wed, 12 Oct 2011 14:14:39 -0400 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> Message-ID: Yeah, but if they publish it with an OSS license, it's open source (if someone grabs it before it's taken down). So I suspect that bundler/etc. won't do that... it would really piss someone off, even if it's their fault. Ciao! On Oct 12, 2011, at 1:43 PM, Nick Quaranto wrote: > I bet this might cut down on delete requests we get too, since someone > pushing an internal gem may opt to not have a license. Then again, authors > of the popular gem generators (say, Bundler) may set the default to an OSS > license, making the check moot anyway :( -- Christian H?ltje (aka docwhat) http://docwhat.org/ From jon.forums at gmail.com Wed Oct 12 14:29:41 2011 From: jon.forums at gmail.com (Jon) Date: Wed, 12 Oct 2011 14:29:41 -0400 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> Message-ID: <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> > > > I'd like to propose making license/licenses field mandatory. While doing > > > rubygem packages for Linux distributions we have to deal with licenses a > > > lot and currently not having a license field in gemspec is the only > > > thing stopping us from doing automated packaging. One has to unpack the > > > gem, search for the license text and change the field by hand. If these > > > fields were mandatory (i.e. one or the other), it would make the whole > > > process much easier. In my opinion the license is very important aspect > > > of the gem similarly important as its name and I think also non-Linux > > > parts of Ruby ecosystem would benefit from that change. What do you > > think? 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 = [] If the field is not present and "correct", do you believe things similar to `gem build mygem.gemspec` should refuse to create a .gem? 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 From jeremy at hinegardner.org Wed Oct 12 14:44:16 2011 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Wed, 12 Oct 2011 12:44:16 -0600 Subject: Make license/licenses field mandatory In-Reply-To: <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> Message-ID: <20111012184416.GZ32027@hinegardner.org> On Wed, Oct 12, 2011 at 02:29:41PM -0400, Jon wrote: > > > > I'd like to propose making license/licenses field mandatory. While doing > > > > rubygem packages for Linux distributions we have to deal with licenses a > > > > lot and currently not having a license field in gemspec is the only > > > > thing stopping us from doing automated packaging. One has to unpack the > > > > gem, search for the license text and change the field by hand. If these > > > > fields were mandatory (i.e. one or the other), it would make the whole > > > > process much easier. In my opinion the license is very important aspect > > > > of the gem similarly important as its name and I think also non-Linux > > > > parts of Ruby ecosystem would benefit from that change. What do you > > > think? > > 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 = [] > > If the field is not present and "correct", do you believe things similar to > `gem build mygem.gemspec` should refuse to create a .gem? I can see the benefits of making the license strongly encouraged. Possibly issue a warning if the license is not filled out with a non-empty value. RPM lint has a great warning on this, and there a list of many many licenses with decent shortnames at: https://fedoraproject.org/wiki/Licensing#Software_License_List I could see a case for; an error if the license is empty, and a warning if it is not one of the known licenses. Also, to help prevent proprietary code from getting accidentally pushed to rubygems.org; rubygems.org could be updated by default refusing to accept gems that have 'Proprietary' in the license field. This of course could be overridden... Just my $.02. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From nick at quaran.to Wed Oct 12 17:52:08 2011 From: nick at quaran.to (Nick Quaranto) Date: Wed, 12 Oct 2011 17:52:08 -0400 Subject: rubygems 'developers' site Message-ID: Hey folks, I'm going to put together a small little static site for the various projects going on in the rubygems ecosystem. Basically, there's no central way to figure out how to contribute to these various projects (or what they are), and I would love for there to be *one* place where people can go to see what's going on, what was updated last, who's in charge, etc. I want to include services that are hooked up via our webhooks as well or use our data in some way. I'm wondering, what projects should go on this page? There's plenty I'm probably missing here, please reply with more if you know of any: Core Projects RubyGems Core (http://github.com/rubygems/rubygems) RubyGems.org (http://github.com/rubygems/rubygems.org) RubyGems Guides (http://github.com/rubygems/guides) RubyGems Testers (http://test.rubygems.org/) Ecosystem Projects RubyDoc.info (http://rubydoc.info/gems) Ruby Toolbox (https://www.ruby-toolbox.com/) Gem Family (http://gemfamily.info/) Gem Notifier (http://gemnotifier.heroku.com) Gemnasium (http://gemnasium.com/) Rails Plugins (http://railsplugins.org) If you have any suggestions as for what should go on this page, let me know! Thanks, Nick From prusnak at opensuse.org Wed Oct 12 19:02:31 2011 From: prusnak at opensuse.org (Pavol Rusnak) Date: Thu, 13 Oct 2011 01:02:31 +0200 Subject: Make license/licenses field mandatory In-Reply-To: <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> Message-ID: <4E961C87.3000605@opensuse.org> 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). > 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). -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic From jon.forums at gmail.com Thu Oct 13 09:41:58 2011 From: jon.forums at gmail.com (Jon) Date: Thu, 13 Oct 2011 09:41:58 -0400 Subject: Make license/licenses field mandatory In-Reply-To: <4E961C87.3000605@opensuse.org> References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> <4E961C87.3000605@opensuse.org> Message-ID: <20111013094158.c20c0b328a0f28982e344e80@gmail.com> On Thu, 13 Oct 2011 01:02:31 +0200 Pavol Rusnak 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 From headius at headius.com Thu Oct 13 11:47:35 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 13 Oct 2011 08:47:35 -0700 Subject: No external deps on Rubygems.org? Message-ID: I ran into a snag trying to demo JRuby's support for installing Maven artifacts as gems: rubygems.org does not allow pushing gems with external dependencies. For the "cloby" gem, which exposes Clojure's STM and persistent list as Ruby instance variables, I wanted to have a dependency on Clojure directly from Maven, using JRuby's maven gem support. The gem name for that looks like "mvn:org.clojure:clojure". This worked well as a dependency in the gemspec, and local copies of the gem would also fetch Clojure from Maven Central. But I was not able to push the gem to rubygems.org. Inability to push gems that depend on Maven artifacts waters down that support considerably. It also means we would need to start pushing Maven libraries to Rubygems.org for every such library anyone depends on...which could mean hundreds of gems that only exist to wrap a JVM library. I know nobody wants that (and that's why we built this support into JRuby) so perhaps we can reach a compromise? - Charlie From nick at quaran.to Thu Oct 13 12:17:39 2011 From: nick at quaran.to (Nick Quaranto) Date: Thu, 13 Oct 2011 12:17:39 -0400 Subject: No external deps on Rubygems.org? In-Reply-To: References: Message-ID: "dependency" is for "gem" dependency, let's keep it that way, please. There is a "requirements" field in the gemspec that this could be used for instead: http://guides.rubygems.org/specification-reference/#requirements However this is yet another reason to have metadata :( -Nick On Thu, Oct 13, 2011 at 11:47 AM, Charles Oliver Nutter wrote: > I ran into a snag trying to demo JRuby's support for installing Maven > artifacts as gems: rubygems.org does not allow pushing gems with > external dependencies. > > For the "cloby" gem, which exposes Clojure's STM and persistent list > as Ruby instance variables, I wanted to have a dependency on Clojure > directly from Maven, using JRuby's maven gem support. The gem name for > that looks like "mvn:org.clojure:clojure". This worked well as a > dependency in the gemspec, and local copies of the gem would also > fetch Clojure from Maven Central. But I was not able to push the gem > to rubygems.org. > > Inability to push gems that depend on Maven artifacts waters down that > support considerably. It also means we would need to start pushing > Maven libraries to Rubygems.org for every such library anyone depends > on...which could mean hundreds of gems that only exist to wrap a JVM > library. I know nobody wants that (and that's why we built this > support into JRuby) so perhaps we can reach a compromise? > > - Charlie > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From erik at hollensbe.org Thu Oct 13 12:21:16 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Thu, 13 Oct 2011 09:21:16 -0700 Subject: No external deps on Rubygems.org? In-Reply-To: References: Message-ID: <946A1AC2-75AA-4404-8E4E-5158FD0315EE@hollensbe.org> Did my patch get reverted? -Erik On Oct 13, 2011, at 9:17 AM, Nick Quaranto wrote: > "dependency" is for "gem" dependency, let's keep it that way, please. There > is a "requirements" field in the gemspec that this could be used for > instead: > > http://guides.rubygems.org/specification-reference/#requirements > > However this is yet another reason to have metadata :( > > -Nick > > On Thu, Oct 13, 2011 at 11:47 AM, Charles Oliver Nutter > wrote: > >> I ran into a snag trying to demo JRuby's support for installing Maven >> artifacts as gems: rubygems.org does not allow pushing gems with >> external dependencies. >> >> For the "cloby" gem, which exposes Clojure's STM and persistent list >> as Ruby instance variables, I wanted to have a dependency on Clojure >> directly from Maven, using JRuby's maven gem support. The gem name for >> that looks like "mvn:org.clojure:clojure". This worked well as a >> dependency in the gemspec, and local copies of the gem would also >> fetch Clojure from Maven Central. But I was not able to push the gem >> to rubygems.org. >> >> Inability to push gems that depend on Maven artifacts waters down that >> support considerably. It also means we would need to start pushing >> Maven libraries to Rubygems.org for every such library anyone depends >> on...which could mean hundreds of gems that only exist to wrap a JVM >> library. I know nobody wants that (and that's why we built this >> support into JRuby) so perhaps we can reach a compromise? >> >> - Charlie >> _______________________________________________ >> RubyGems-Developers mailing list >> http://rubyforge.org/projects/rubygems >> RubyGems-Developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers >> > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From prusnak at opensuse.org Thu Oct 13 12:39:33 2011 From: prusnak at opensuse.org (Pavol Rusnak) Date: Thu, 13 Oct 2011 18:39:33 +0200 Subject: Make license/licenses field mandatory In-Reply-To: <4E959C14.6080704@opensuse.org> References: <4E959C14.6080704@opensuse.org> Message-ID: <4E971445.7080508@opensuse.org> On 10/12/2011 03:54 PM, Pavol Rusnak wrote: > Hi all! > > I'd like to propose making license/licenses field mandatory. While doing > rubygem packages for Linux distributions we have to deal with licenses a > lot and currently not having a license field in gemspec is the only > thing stopping us from doing automated packaging. One has to unpack the > gem, search for the license text and change the field by hand. If these > fields were mandatory (i.e. one or the other), it would make the whole > process much easier. In my opinion the license is very important aspect > of the gem similarly important as its name and I think also non-Linux > parts of Ruby ecosystem would benefit from that change. What do you think? > As most of you seem to agree, I created the following pull request[1] containing the suggested change. Feel free to accept/comment/edit ... [1] https://github.com/rubygems/rubygems/pull/202 -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic From nick at quaran.to Thu Oct 13 12:41:07 2011 From: nick at quaran.to (Nick Quaranto) Date: Thu, 13 Oct 2011 12:41:07 -0400 Subject: No external deps on Rubygems.org? In-Reply-To: <946A1AC2-75AA-4404-8E4E-5158FD0315EE@hollensbe.org> References: <946A1AC2-75AA-4404-8E4E-5158FD0315EE@hollensbe.org> Message-ID: Erik, not sure what you're referring to... On Oct 13, 2011 12:28 PM, "Erik Hollensbe" wrote: > > Did my patch get reverted? > > -Erik > > On Oct 13, 2011, at 9:17 AM, Nick Quaranto wrote: > > > "dependency" is for "gem" dependency, let's keep it that way, please. > There > > is a "requirements" field in the gemspec that this could be used for > > instead: > > > > http://guides.rubygems.org/specification-reference/#requirements > > > > However this is yet another reason to have metadata :( > > > > -Nick > > > > On Thu, Oct 13, 2011 at 11:47 AM, Charles Oliver Nutter < > headius at headius.com > >> wrote: > > > >> I ran into a snag trying to demo JRuby's support for installing Maven > >> artifacts as gems: rubygems.org does not allow pushing gems with > >> external dependencies. > >> > >> For the "cloby" gem, which exposes Clojure's STM and persistent list > >> as Ruby instance variables, I wanted to have a dependency on Clojure > >> directly from Maven, using JRuby's maven gem support. The gem name for > >> that looks like "mvn:org.clojure:clojure". This worked well as a > >> dependency in the gemspec, and local copies of the gem would also > >> fetch Clojure from Maven Central. But I was not able to push the gem > >> to rubygems.org. > >> > >> Inability to push gems that depend on Maven artifacts waters down that > >> support considerably. It also means we would need to start pushing > >> Maven libraries to Rubygems.org for every such library anyone depends > >> on...which could mean hundreds of gems that only exist to wrap a JVM > >> library. I know nobody wants that (and that's why we built this > >> support into JRuby) so perhaps we can reach a compromise? > >> > >> - Charlie > >> _______________________________________________ > >> RubyGems-Developers mailing list > >> http://rubyforge.org/projects/rubygems > >> RubyGems-Developers at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rubygems-developers > >> > > _______________________________________________ > > RubyGems-Developers mailing list > > http://rubyforge.org/projects/rubygems > > RubyGems-Developers at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From luislavena at gmail.com Thu Oct 13 13:03:53 2011 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 13 Oct 2011 19:03:53 +0200 Subject: No external deps on Rubygems.org? In-Reply-To: References: Message-ID: On Thu, Oct 13, 2011 at 5:47 PM, Charles Oliver Nutter wrote: > I ran into a snag trying to demo JRuby's support for installing Maven > artifacts as gems: rubygems.org does not allow pushing gems with > external dependencies. > > For the "cloby" gem, which exposes Clojure's STM and persistent list > as Ruby instance variables, I wanted to have a dependency on Clojure > directly from Maven, using JRuby's maven gem support. The gem name for > that looks like "mvn:org.clojure:clojure". This worked well as a > dependency in the gemspec, and local copies of the gem would also > fetch Clojure from Maven Central. But I was not able to push the gem > to rubygems.org. > 1) Gem names with ":" will not work on Windows, is not safe. 2) RubyGems cannot install gems across multiple repositories (so if your maven wrapper is in another server it will not find it) 3) Last but not least: let's not turn RubyGems "dependencies" into "anything this gem depend on". RubyGems dependencies *must be* a gem. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From erik at hollensbe.org Thu Oct 13 14:15:32 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Thu, 13 Oct 2011 11:15:32 -0700 Subject: No external deps on Rubygems.org? In-Reply-To: References: <946A1AC2-75AA-4404-8E4E-5158FD0315EE@hollensbe.org> Message-ID: I wrote a patch a while back that handles metadata. I'm not sure what's become of it. -Erik On Oct 13, 2011, at 9:41 AM, Nick Quaranto wrote: > Erik, not sure what you're referring to... > On Oct 13, 2011 12:28 PM, "Erik Hollensbe" wrote: > >> >> Did my patch get reverted? >> >> -Erik >> >> On Oct 13, 2011, at 9:17 AM, Nick Quaranto wrote: >> >>> "dependency" is for "gem" dependency, let's keep it that way, please. >> There >>> is a "requirements" field in the gemspec that this could be used for >>> instead: >>> >>> http://guides.rubygems.org/specification-reference/#requirements >>> >>> However this is yet another reason to have metadata :( >>> >>> -Nick >>> >>> On Thu, Oct 13, 2011 at 11:47 AM, Charles Oliver Nutter < >> headius at headius.com >>>> wrote: >>> >>>> I ran into a snag trying to demo JRuby's support for installing Maven >>>> artifacts as gems: rubygems.org does not allow pushing gems with >>>> external dependencies. >>>> >>>> For the "cloby" gem, which exposes Clojure's STM and persistent list >>>> as Ruby instance variables, I wanted to have a dependency on Clojure >>>> directly from Maven, using JRuby's maven gem support. The gem name for >>>> that looks like "mvn:org.clojure:clojure". This worked well as a >>>> dependency in the gemspec, and local copies of the gem would also >>>> fetch Clojure from Maven Central. But I was not able to push the gem >>>> to rubygems.org. >>>> >>>> Inability to push gems that depend on Maven artifacts waters down that >>>> support considerably. It also means we would need to start pushing >>>> Maven libraries to Rubygems.org for every such library anyone depends >>>> on...which could mean hundreds of gems that only exist to wrap a JVM >>>> library. I know nobody wants that (and that's why we built this >>>> support into JRuby) so perhaps we can reach a compromise? >>>> >>>> - Charlie >>>> _______________________________________________ >>>> RubyGems-Developers mailing list >>>> http://rubyforge.org/projects/rubygems >>>> RubyGems-Developers at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rubygems-developers >>>> >>> _______________________________________________ >>> RubyGems-Developers mailing list >>> http://rubyforge.org/projects/rubygems >>> RubyGems-Developers at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rubygems-developers >> >> _______________________________________________ >> RubyGems-Developers mailing list >> http://rubyforge.org/projects/rubygems >> RubyGems-Developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers >> > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From y_feldblum at yahoo.com Thu Oct 13 14:51:17 2011 From: y_feldblum at yahoo.com (Jay Feldblum) Date: Thu, 13 Oct 2011 14:51:17 -0400 Subject: Make license/licenses field mandatory In-Reply-To: <20111013094158.c20c0b328a0f28982e344e80@gmail.com> References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> <4E961C87.3000605@opensuse.org> <20111013094158.c20c0b328a0f28982e344e80@gmail.com> Message-ID: 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 wrote: > On Thu, 13 Oct 2011 01:02:31 +0200 > Pavol Rusnak 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 > From evan at fallingsnow.net Thu Oct 13 15:19:35 2011 From: evan at fallingsnow.net (Evan Phoenix) Date: Thu, 13 Oct 2011 12:19:35 -0700 Subject: No external deps on Rubygems.org? In-Reply-To: References: <946A1AC2-75AA-4404-8E4E-5158FD0315EE@hollensbe.org> Message-ID: On Thursday, October 13, 2011 at 11:15 AM, Erik Hollensbe wrote: > I wrote a patch a while back that handles metadata. I'm not sure what's become of it. It got merged in. Nick just doesn't know that. Nick, metadata is in!! > > -Erik > > On Oct 13, 2011, at 9:41 AM, Nick Quaranto wrote: > > > Erik, not sure what you're referring to... > > On Oct 13, 2011 12:28 PM, "Erik Hollensbe" wrote: > > > > > > > > Did my patch get reverted? > > > > > > -Erik > > > > > > On Oct 13, 2011, at 9:17 AM, Nick Quaranto wrote: > > > > > > > "dependency" is for "gem" dependency, let's keep it that way, please. > > > There > > > > is a "requirements" field in the gemspec that this could be used for > > > > instead: > > > > > > > > http://guides.rubygems.org/specification-reference/#requirements > > > > > > > > However this is yet another reason to have metadata :( > > > > > > > > -Nick > > > > > > > > On Thu, Oct 13, 2011 at 11:47 AM, Charles Oliver Nutter < > > > headius at headius.com (mailto:headius at headius.com) > > > > > wrote: > > > > > > > > > I ran into a snag trying to demo JRuby's support for installing Maven > > > > > artifacts as gems: rubygems.org (http://rubygems.org) does not allow pushing gems with > > > > > external dependencies. > > > > > > > > > > For the "cloby" gem, which exposes Clojure's STM and persistent list > > > > > as Ruby instance variables, I wanted to have a dependency on Clojure > > > > > directly from Maven, using JRuby's maven gem support. The gem name for > > > > > that looks like "mvn:org.clojure:clojure". This worked well as a > > > > > dependency in the gemspec, and local copies of the gem would also > > > > > fetch Clojure from Maven Central. But I was not able to push the gem > > > > > to rubygems.org (http://rubygems.org). > > > > > > > > > > Inability to push gems that depend on Maven artifacts waters down that > > > > > support considerably. It also means we would need to start pushing > > > > > Maven libraries to Rubygems.org (http://Rubygems.org) for every such library anyone depends > > > > > on...which could mean hundreds of gems that only exist to wrap a JVM > > > > > library. I know nobody wants that (and that's why we built this > > > > > support into JRuby) so perhaps we can reach a compromise? > > > > > > > > > > - Charlie > > > > > _______________________________________________ > > > > > RubyGems-Developers mailing list > > > > > http://rubyforge.org/projects/rubygems > > > > > RubyGems-Developers at rubyforge.org (mailto:RubyGems-Developers at rubyforge.org) > > > > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > > _______________________________________________ > > > > RubyGems-Developers mailing list > > > > http://rubyforge.org/projects/rubygems > > > > RubyGems-Developers at rubyforge.org (mailto:RubyGems-Developers at rubyforge.org) > > > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > > > > _______________________________________________ > > > RubyGems-Developers mailing list > > > http://rubyforge.org/projects/rubygems > > > RubyGems-Developers at rubyforge.org (mailto:RubyGems-Developers at rubyforge.org) > > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > _______________________________________________ > > RubyGems-Developers mailing list > > http://rubyforge.org/projects/rubygems > > RubyGems-Developers at rubyforge.org (mailto:RubyGems-Developers at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org (mailto:RubyGems-Developers at rubyforge.org) > http://rubyforge.org/mailman/listinfo/rubygems-developers From drbrain at segment7.net Thu Oct 13 16:00:11 2011 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 13 Oct 2011 13:00:11 -0700 Subject: Metadata (Was: No external deps on Rubygems.org?) In-Reply-To: <946A1AC2-75AA-4404-8E4E-5158FD0315EE@hollensbe.org> References: <946A1AC2-75AA-4404-8E4E-5158FD0315EE@hollensbe.org> Message-ID: On Oct 13, 2011, at 9:21 AM, Erik Hollensbe wrote: > Did my patch get reverted? I believe it has never been released, but is still in trunk waiting for the 1.9 release. From drbrain at segment7.net Thu Oct 13 15:58:29 2011 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 13 Oct 2011 12:58:29 -0700 Subject: Make license/licenses field mandatory In-Reply-To: <4E959C14.6080704@opensuse.org> References: <4E959C14.6080704@opensuse.org> Message-ID: On Oct 12, 2011, at 6:54 AM, Pavol Rusnak wrote: > I'd like to propose making license/licenses field mandatory. While doing > rubygem packages for Linux distributions we have to deal with licenses a > lot and currently not having a license field in gemspec is the only > thing stopping us from doing automated packaging. One has to unpack the > gem, search for the license text and change the field by hand. If these > fields were mandatory (i.e. one or the other), it would make the whole > process much easier. In my opinion the license is very important aspect > of the gem similarly important as its name and I think also non-Linux > parts of Ruby ecosystem would benefit from that change. What do you think? The first goal of RubyGems is to provide useful tools for Rubyists to share libraries. The needs of repackagers comes second. I'm fine with a warning at gem build time if the license is not set. I don't want to make it suddenly mandatory as that disrupts a gem author's workflow. In order for this to be successful for gem packagers, Rubyists need to agree it is a good thing. Some authors will avoid upgrading RubyGems if mandatory requirements are added too quickly. Perhaps in the future it can be made mandatory if gem authors agree it is a good thing, but not for the present. As a repackager, if the license field is not set you should submit a patch to the gem author to set it for them. From jon.forums at gmail.com Thu Oct 13 16:19:10 2011 From: jon.forums at gmail.com (Jon) Date: Thu, 13 Oct 2011 16:19:10 -0400 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> <4E961C87.3000605@opensuse.org> <20111013094158.c20c0b328a0f28982e344e80@gmail.com> Message-ID: > 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 From nick at quaran.to Thu Oct 13 16:49:55 2011 From: nick at quaran.to (Nick Quaranto) Date: Thu, 13 Oct 2011 16:49:55 -0400 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> <4E961C87.3000605@opensuse.org> <20111013094158.c20c0b328a0f28982e344e80@gmail.com> Message-ID: 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 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From luislavena at gmail.com Thu Oct 13 17:14:08 2011 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 13 Oct 2011 23:14:08 +0200 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> <4E961C87.3000605@opensuse.org> <20111013094158.c20c0b328a0f28982e344e80@gmail.com> Message-ID: On Thu, Oct 13, 2011 at 10:49 PM, Nick Quaranto 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. > What about a warning about pushing a gem that has no license and ask about it? I see help.rubygems.org getting *lot* of request like "doh, by mistake a pushed the gem of my company, please remove". Luckily I'm not the one doing the manual work, but I bet now that you're married would like to spend some time with your wife, right? -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From y_feldblum at yahoo.com Thu Oct 13 17:20:44 2011 From: y_feldblum at yahoo.com (Jay Feldblum) Date: Thu, 13 Oct 2011 17:20:44 -0400 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> <4E961C87.3000605@opensuse.org> <20111013094158.c20c0b328a0f28982e344e80@gmail.com> Message-ID: Jon, That's a good question. It catches me out on making a blanket statement where I should have been more careful. Let me start off with the rationale and then give my answer. The thing that needs enforcement is rubygems.org, the public gems repository. The thing that needs to guide users in the right direction is the rubygems library. The rubygems.org whitelist should be the key enforcer that new gems and new gem versions pushed to the public rubygems.org repository have known open-source licenses. Anything outside of rubygems.org and its whitelist should be there only to help and to guide, and should easily be overridden. Therefore, gem push --host HOST *should warn* but *should not refuse* (i.e., should allow the operation only if the --host HOST option is passed, and only if the HOST is other than rubygems.org). The warning should be there because all gems *should* have licenses, even if the license is "Proprietary: Authorized Use Only." This is my strong opinion and I think the rubygems tooling should take that opinion as well. The rationale that tooling *should* have a way to find out about all gem licenses still applies here. I quite understand that it may be annoying for a new gem author to see this warning message, but the five minutes it takes him to add a license is five minutes less time that every one of his gem's users, potentially thousands of people, have to spend researching the gem. But in the case of a private gem at a private repository, if the gem author sees the warning and ignores it, then his tooling missing that license information is his fault - but it doesn't affect anyone else, or at least anyone else outside his organization. Overall, what I'd like to see is a tool that can tell me: $ bundle licenses list activesupport (3.1.1) => MIT multi_json (1.0.3) => MIT my-private-gem (3.2.6) => Proprietary old-public-gem (2.6.7) => all from metadata, so I can remain sure every time I update my gems of what the licenses are. And I'd like the rubygems tooling to guide everyone to make that possible, and the public rubygems.org ecosystem to enforce it. Cheers, Jay Feldblum On Thu, Oct 13, 2011 at 4:19 PM, Jon 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From nick at quaran.to Thu Oct 13 17:50:31 2011 From: nick at quaran.to (Nick Quaranto) Date: Thu, 13 Oct 2011 17:50:31 -0400 Subject: No external deps on Rubygems.org? In-Reply-To: References: <946A1AC2-75AA-4404-8E4E-5158FD0315EE@hollensbe.org> Message-ID: This makes my week!!!! ZOMG!@!!!!! On Thu, Oct 13, 2011 at 3:19 PM, Evan Phoenix wrote: > On Thursday, October 13, 2011 at 11:15 AM, Erik Hollensbe wrote: > > I wrote a patch a while back that handles metadata. I'm not sure what's > become of it. > It got merged in. Nick just doesn't know that. > > Nick, metadata is in!! > > > > -Erik > > > > On Oct 13, 2011, at 9:41 AM, Nick Quaranto wrote: > > > > > Erik, not sure what you're referring to... > > > On Oct 13, 2011 12:28 PM, "Erik Hollensbe" erik at hollensbe.org)> wrote: > > > > > > > > > > > Did my patch get reverted? > > > > > > > > -Erik > > > > > > > > On Oct 13, 2011, at 9:17 AM, Nick Quaranto wrote: > > > > > > > > > "dependency" is for "gem" dependency, let's keep it that way, > please. > > > > There > > > > > is a "requirements" field in the gemspec that this could be used > for > > > > > instead: > > > > > > > > > > http://guides.rubygems.org/specification-reference/#requirements > > > > > > > > > > However this is yet another reason to have metadata :( > > > > > > > > > > -Nick > > > > > > > > > > On Thu, Oct 13, 2011 at 11:47 AM, Charles Oliver Nutter < > > > > headius at headius.com (mailto:headius at headius.com) > > > > > > wrote: > > > > > > > > > > > I ran into a snag trying to demo JRuby's support for installing > Maven > > > > > > artifacts as gems: rubygems.org (http://rubygems.org) does not > allow pushing gems with > > > > > > external dependencies. > > > > > > > > > > > > For the "cloby" gem, which exposes Clojure's STM and persistent > list > > > > > > as Ruby instance variables, I wanted to have a dependency on > Clojure > > > > > > directly from Maven, using JRuby's maven gem support. The gem > name for > > > > > > that looks like "mvn:org.clojure:clojure". This worked well as a > > > > > > dependency in the gemspec, and local copies of the gem would also > > > > > > fetch Clojure from Maven Central. But I was not able to push the > gem > > > > > > to rubygems.org (http://rubygems.org). > > > > > > > > > > > > Inability to push gems that depend on Maven artifacts waters down > that > > > > > > support considerably. It also means we would need to start > pushing > > > > > > Maven libraries to Rubygems.org (http://Rubygems.org) for every > such library anyone depends > > > > > > on...which could mean hundreds of gems that only exist to wrap a > JVM > > > > > > library. I know nobody wants that (and that's why we built this > > > > > > support into JRuby) so perhaps we can reach a compromise? > > > > > > > > > > > > - Charlie > > > > > > _______________________________________________ > > > > > > RubyGems-Developers mailing list > > > > > > http://rubyforge.org/projects/rubygems > > > > > > RubyGems-Developers at rubyforge.org (mailto: > RubyGems-Developers at rubyforge.org) > > > > > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > > > _______________________________________________ > > > > > RubyGems-Developers mailing list > > > > > http://rubyforge.org/projects/rubygems > > > > > RubyGems-Developers at rubyforge.org (mailto: > RubyGems-Developers at rubyforge.org) > > > > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > > > > > > _______________________________________________ > > > > RubyGems-Developers mailing list > > > > http://rubyforge.org/projects/rubygems > > > > RubyGems-Developers at rubyforge.org (mailto: > RubyGems-Developers at rubyforge.org) > > > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > _______________________________________________ > > > RubyGems-Developers mailing list > > > http://rubyforge.org/projects/rubygems > > > RubyGems-Developers at rubyforge.org (mailto: > RubyGems-Developers at rubyforge.org) > > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > > _______________________________________________ > > RubyGems-Developers mailing list > > http://rubyforge.org/projects/rubygems > > RubyGems-Developers at rubyforge.org (mailto: > RubyGems-Developers at rubyforge.org) > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From y_feldblum at yahoo.com Thu Oct 13 17:45:31 2011 From: y_feldblum at yahoo.com (Jay Feldblum) Date: Thu, 13 Oct 2011 17:45:31 -0400 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> <4E961C87.3000605@opensuse.org> <20111013094158.c20c0b328a0f28982e344e80@gmail.com> Message-ID: 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 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 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 at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From headius at headius.com Thu Oct 13 23:09:11 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 14 Oct 2011 03:09:11 +0000 Subject: No external deps on Rubygems.org? In-Reply-To: References: Message-ID: These *are* gems... system ~/projects/jruby $ gem install mvn:org.clojure:clojure Successfully installed mvn:org.clojure:clojure-1.4.0.a.1-java 1 gem installed system ~/projects/jruby $ ls lib/ruby/gems/1.8/cache/*clojure* lib/ruby/gems/1.8/cache/mvn:org.clojure:clojure-1.3.0-java.gem lib/ruby/gems/1.8/cache/mvn:org.clojure:clojure-1.4.0.a.1-java.gem We have some additional tweaks to RubyGems to source them out of Maven instead of having to push them to Rubygems.org. We did this to avoid everyone pushing their own copy of every maven artifact in the world, which I think you all would agree is best. Here's the deal... JVM libraries are as useful to JRuby users as gems are. There's tens of thousands of them available. They're generally published by the JVM community to Maven repositories, primarily the "central" repositories that act like rubygems.org does for RubyGems. JRuby users want to use those libraries in their apps and depend on them in their gems. In order to do that, one of two things need to happen: 1. They push a gem that contains the libraries. This means potentially hundreds or thousands of binary jar files wrapped in gems and pushed to rubygems.org, and updated as those libraries are versioned. This is what you are recommending to me. 2. They use JRuby's maven/gem integration to source the libraries directly from maven, transparently wrapped in a gem at install time. I think this is preferable in many ways, but since those gems don't exist on rubygems.org it's not an option. I can certainly make a recommendation to JRuby users that they should start pushing maven artifacts as gems to rubygems.org, if that's what you'd prefer. I could also set up a nightly/weekly job to scan Maven Central and push tens of thousands of jars-in-gems to rubygems.org, so we'd know they're available for JRuby users. I don't think anyone wants that, though. :) Suggestions? - Charlie On Thu, Oct 13, 2011 at 4:17 PM, Nick Quaranto wrote: > "dependency" is for "gem" dependency, let's keep it that way, please. There > is a "requirements" field in the gemspec that this could be used for > instead: > > http://guides.rubygems.org/specification-reference/#requirements > > However this is yet another reason to have metadata :( > > -Nick > > On Thu, Oct 13, 2011 at 11:47 AM, Charles Oliver Nutter > wrote: > >> I ran into a snag trying to demo JRuby's support for installing Maven >> artifacts as gems: rubygems.org does not allow pushing gems with >> external dependencies. >> >> For the "cloby" gem, which exposes Clojure's STM and persistent list >> as Ruby instance variables, I wanted to have a dependency on Clojure >> directly from Maven, using JRuby's maven gem support. The gem name for >> that looks like "mvn:org.clojure:clojure". This worked well as a >> dependency in the gemspec, and local copies of the gem would also >> fetch Clojure from Maven Central. But I was not able to push the gem >> to rubygems.org. >> >> Inability to push gems that depend on Maven artifacts waters down that >> support considerably. It also means we would need to start pushing >> Maven libraries to Rubygems.org for every such library anyone depends >> on...which could mean hundreds of gems that only exist to wrap a JVM >> library. I know nobody wants that (and that's why we built this >> support into JRuby) so perhaps we can reach a compromise? >> >> - Charlie >> _______________________________________________ >> RubyGems-Developers mailing list >> http://rubyforge.org/projects/rubygems >> RubyGems-Developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers >> > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From headius at headius.com Thu Oct 13 23:11:30 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 14 Oct 2011 03:11:30 +0000 Subject: No external deps on Rubygems.org? In-Reply-To: References: <946A1AC2-75AA-4404-8E4E-5158FD0315EE@hollensbe.org> Message-ID: Perhaps someone can describe to me how metadata or requirements could be used to fulfill this requirement...I'm not sure I understand. The current setup, with Maven artifacts transparently and "magically" available as gems seems like the ideal situation: * No duplication of every Maven artifact on rubygems.org * No conflicting gem versions from different users pushing their own copy of jars-in-gems If there's a simple way to handle this with metadata or requirements, I would love to hear it! - Charlie On Thu, Oct 13, 2011 at 6:15 PM, Erik Hollensbe wrote: > I wrote a patch a while back that handles metadata. I'm not sure what's become of it. > > -Erik > > On Oct 13, 2011, at 9:41 AM, Nick Quaranto wrote: > >> Erik, not sure what you're referring to... >> On Oct 13, 2011 12:28 PM, "Erik Hollensbe" wrote: >> >>> >>> Did my patch get reverted? >>> >>> -Erik >>> >>> On Oct 13, 2011, at 9:17 AM, Nick Quaranto wrote: >>> >>>> "dependency" is for "gem" dependency, let's keep it that way, please. >>> There >>>> is a "requirements" field in the gemspec that this could be used for >>>> instead: >>>> >>>> http://guides.rubygems.org/specification-reference/#requirements >>>> >>>> However this is yet another reason to have metadata :( >>>> >>>> -Nick >>>> >>>> On Thu, Oct 13, 2011 at 11:47 AM, Charles Oliver Nutter < >>> headius at headius.com >>>>> wrote: >>>> >>>>> I ran into a snag trying to demo JRuby's support for installing Maven >>>>> artifacts as gems: rubygems.org does not allow pushing gems with >>>>> external dependencies. >>>>> >>>>> For the "cloby" gem, which exposes Clojure's STM and persistent list >>>>> as Ruby instance variables, I wanted to have a dependency on Clojure >>>>> directly from Maven, using JRuby's maven gem support. The gem name for >>>>> that looks like "mvn:org.clojure:clojure". This worked well as a >>>>> dependency in the gemspec, and local copies of the gem would also >>>>> fetch Clojure from Maven Central. But I was not able to push the gem >>>>> to rubygems.org. >>>>> >>>>> Inability to push gems that depend on Maven artifacts waters down that >>>>> support considerably. It also means we would need to start pushing >>>>> Maven libraries to Rubygems.org for every such library anyone depends >>>>> on...which could mean hundreds of gems that only exist to wrap a JVM >>>>> library. I know nobody wants that (and that's why we built this >>>>> support into JRuby) so perhaps we can reach a compromise? >>>>> >>>>> - Charlie >>>>> _______________________________________________ >>>>> RubyGems-Developers mailing list >>>>> http://rubyforge.org/projects/rubygems >>>>> RubyGems-Developers at rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/rubygems-developers >>>>> >>>> _______________________________________________ >>>> RubyGems-Developers mailing list >>>> http://rubyforge.org/projects/rubygems >>>> RubyGems-Developers at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rubygems-developers >>> >>> _______________________________________________ >>> RubyGems-Developers mailing list >>> http://rubyforge.org/projects/rubygems >>> RubyGems-Developers at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rubygems-developers >>> >> _______________________________________________ >> RubyGems-Developers mailing list >> http://rubyforge.org/projects/rubygems >> RubyGems-Developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers > > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From drbrain at segment7.net Thu Oct 13 23:15:09 2011 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 13 Oct 2011 20:15:09 -0700 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> <4E961C87.3000605@opensuse.org> <20111013094158.c20c0b328a0f28982e344e80@gmail.com> Message-ID: <249947CA-E67C-4860-8248-073614F105BD@segment7.net> On Oct 13, 2011, at 2:45 PM, Jay Feldblum wrote: > Instead, some innocent programmer might download and use a gem from rubygems.org *illegally*, and *punishably under the law*. It's not the job of RubyGems to police what people do beyond making sure the versions of gems they install are mutually compatible. I've heard people claim that using certain combinations of GPL and certain other-licensed software is illegal. Restricting this through RubyGems is not going to prevent people from using such combinations as they'll work around it. Yes, I understand that mandatory licenses in the spec will make it easier for users of gems that want to audit licenses of gems they installed to do so, but getting authors setting the license in the spec is your first problem. Sudden, mandatory licensing is likely to go over with them about as well as the deprecation warnings on RubyGems 1.8.0 without a careful campaign of education on why it is useful to pave the way. PS: Can you show a case where a software author has uploaded unlicensed (or non-free-licensed) software to a website where open-source software is shared (like rubygems.org, sf.net, rubyforge.org, code.google.com or similar) then sued users who downloaded it? I haven't heard of such a thing in over ten years of open source contribution and use so I'm highly unconvinced. I think a successful suit is about as likely as an arrest for taking cookies from an unsupervised plate in the middle of a public park that's sitting next to a box with a "free" sign. Sure, the cookie plate doesn't say "free", but why did you put it next to the free box in the first place? From headius at headius.com Thu Oct 13 23:26:27 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 14 Oct 2011 03:26:27 +0000 Subject: No external deps on Rubygems.org? In-Reply-To: References: Message-ID: On Thu, Oct 13, 2011 at 5:03 PM, Luis Lavena wrote: > 1) Gem names with ":" will not work on Windows, is not safe. I'll look into that. I know we have tests for this functionality that pass on Windows... > 2) RubyGems cannot install gems across multiple repositories (so if > your maven wrapper is in another server it will not find it) The Maven logic is built into our copy of RubyGems directly; it knows if it sees anything prefixed with "mvn:" it uses Maven to source the contents of that gem, rather than looking on rubygems.org. > 3) Last but not least: let's not turn RubyGems "dependencies" into > "anything this gem depend on". How would you recommend people grab the required libraries? Like I said in other posts, I can certainly recommend that they start wrapping and pushing those libraries to rubygems.org, but I don't think anyone wants rubygems.org bloated up with thousands of jar files. > RubyGems dependencies *must be* a gem. These *are* gems...we just build them dynamically by sourcing the contents from Maven. - Charlie From y_feldblum at yahoo.com Fri Oct 14 01:50:08 2011 From: y_feldblum at yahoo.com (Jay Feldblum) Date: Fri, 14 Oct 2011 01:50:08 -0400 Subject: Make license/licenses field mandatory In-Reply-To: <249947CA-E67C-4860-8248-073614F105BD@segment7.net> References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> <4E961C87.3000605@opensuse.org> <20111013094158.c20c0b328a0f28982e344e80@gmail.com> <249947CA-E67C-4860-8248-073614F105BD@segment7.net> Message-ID: Eric, I'd like rubygems.org to check that there *is* a license, and either that it's a license listed on http://www.opensource.org/licenses (the whitelist) or that it's marked as a custom otherwise-free/open license. My suggestion is that rubygems.org enforce a license whitelist *but also permit an escape hatch* (i.e., permit marking a gem as using a custom but otherwise free/open license). So rubygems.org wouldn't be *policing* per-se. It would be making an effort to get good license metadata and to have gem authors provide it. The requirement from rubygems.org can be phased in over time, with the warning to gem authors in the rubygems library coming first and coming well in advance of any enforcement by the rubygems.org server. Gem authors will have been seeing this warning for perhaps a year when building/pushing new gems or new versions of gems that are missing licenses, and will be well-prepared for rubygems.org to begin enforcing a whitelist (while also permitting the escape hatch above). Organizations' attorneys are often concerned with protecting their organizations or clients from the mere possibility of litigation or any type of legal action, regardless of how unlikely ligation or other action might be. Additionally, in our litigious New America, *successful* suits in this area may be rare, but unscrupulous folk may be likely to to try a lawsuit - not to try to win - but to make the defendant cry uncle and beg to settle quickly. To try to prevent against such scenarios, organizations' attorneys may want the developers to be vigilant against using anything against its license. The point isn't that it happens. The point is to prevent it from happening as far as possible. To go to a finer point, someone might upload his software to an open-source code-sharing site, with the intention that his software be copyleft, but forgetting to include a specific license. Someone else might download and use the software in his commercial project in a way inconsistent with a copyleft license. The hypothetical tooling to check all the licenses is equally useful for answering the question "can I be sued?" as it is for answering the more-fundamental questions "am I being honest?" and "am I treating my fellow developers with respect (by not using their software against their will)?" Cheers, Jay Feldblum On Thu, Oct 13, 2011 at 11:15 PM, Eric Hodel wrote: > On Oct 13, 2011, at 2:45 PM, Jay Feldblum wrote: > > Instead, some innocent programmer might download and use a gem from > rubygems.org *illegally*, and *punishably under the law*. > > It's not the job of RubyGems to police what people do beyond making sure > the versions of gems they install are mutually compatible. > > I've heard people claim that using certain combinations of GPL and certain > other-licensed software is illegal. Restricting this through RubyGems is > not going to prevent people from using such combinations as they'll work > around it. > > Yes, I understand that mandatory licenses in the spec will make it easier > for users of gems that want to audit licenses of gems they installed to do > so, but getting authors setting the license in the spec is your first > problem. Sudden, mandatory licensing is likely to go over with them about > as well as the deprecation warnings on RubyGems 1.8.0 without a careful > campaign of education on why it is useful to pave the way. > > PS: Can you show a case where a software author has uploaded unlicensed (or > non-free-licensed) software to a website where open-source software is > shared (like rubygems.org, sf.net, rubyforge.org, code.google.com or > similar) then sued users who downloaded it? I haven't heard of such a thing > in over ten years of open source contribution and use so I'm highly > unconvinced. > > I think a successful suit is about as likely as an arrest for taking > cookies from an unsupervised plate in the middle of a public park that's > sitting next to a box with a "free" sign. Sure, the cookie plate doesn't > say "free", but why did you put it next to the free box in the first place? > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From jon.forums at gmail.com Fri Oct 14 13:30:25 2011 From: jon.forums at gmail.com (Jon) Date: Fri, 14 Oct 2011 13:30:25 -0400 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> <4E961C87.3000605@opensuse.org> <20111013094158.c20c0b328a0f28982e344e80@gmail.com> Message-ID: > The thing that needs enforcement is rubygems.org, the public gems > repository. The thing that needs to guide users in the right direction is > the rubygems library. > > While I'm not yet convinced of "The thing that needs enforcement is rubygems.org..." and I'm not a lawyer, I did read the fedoraproject.org link from Jeremy, and a couple of its embedded links https://fedoraproject.org/wiki/Packaging/LicensingGuidelines https://fedoraproject.org/wiki/Licensing/FAQ and am struck by a few things 1) The amount of legal and non-legal up-front investment and ongoing maintenance that is likely required to implement enforcement correctly. 2) Are there potential liabilities that are inadvertently taken on if rubygems.org attempts to implement *any* licensing enforcement above and beyond what's currently done? And of course the complement question. 3) The ongoing rubygems.org policy discussion is beyond the scope of the OP's original proposal and really another thread. I'm not trying to short-circuit the discussion or diminish important licensing issues, but my bias is to answer "yes" to the OPs proposal of making `licenses` mandatory and simply implement a check like the current `authors` check. And perhaps a future `Gem::Lint` abstraction as previously mentioned enables some sort of pluggable way for RG commands to have hookable validation of a specification to meet specific needs that really fall outside of RG's scope. Jon From drbrain at segment7.net Fri Oct 14 14:19:36 2011 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 14 Oct 2011 11:19:36 -0700 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> <20111012142941.f4c3d35889ff7d2d93944dcb@gmail.com> <4E961C87.3000605@opensuse.org> <20111013094158.c20c0b328a0f28982e344e80@gmail.com> <249947CA-E67C-4860-8248-073614F105BD@segment7.net> Message-ID: On Oct 13, 2011, at 10:50 PM, Jay Feldblum wrote: > Organizations' attorneys are often concerned with protecting their > organizations or clients from the mere possibility of litigation or any type > of legal action, regardless of how unlikely ligation or other action might > be. I don't see how enforcing a sticker on the side of the box is going to help fearful lawyers. The sticker on the side of Ruby would say "Ruby or BSD 2-clause", but the truth of the matter is a bit more complicated as only a proper review would determine: http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/LEGAL?view=markup RubyGems cannot act as a dictator in this matter and have it be successful, nor can it be overly whiny or restrictive and have it be successful. In order for it to be successful you need to educate users on why filling in the licenses field is a good thing, not the members of this list. Once it is accepted by the community RubyGems may decide to enforce it. From darix at web.de Fri Oct 14 15:16:35 2011 From: darix at web.de (Marcus Rueckert) Date: Fri, 14 Oct 2011 21:16:35 +0200 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> Message-ID: <20111014191635.GE20237@nordisch.org> On 2011-10-13 12:58:29 -0700, Eric Hodel wrote: > On Oct 12, 2011, at 6:54 AM, Pavol Rusnak wrote: > > I'd like to propose making license/licenses field mandatory. While doing > > rubygem packages for Linux distributions we have to deal with licenses a > > lot and currently not having a license field in gemspec is the only > > thing stopping us from doing automated packaging. One has to unpack the > > gem, search for the license text and change the field by hand. If these > > fields were mandatory (i.e. one or the other), it would make the whole > > process much easier. In my opinion the license is very important aspect > > of the gem similarly important as its name and I think also non-Linux > > parts of Ruby ecosystem would benefit from that change. What do you think? > > > The first goal of RubyGems is to provide useful tools for Rubyists to > share libraries. The needs of repackagers comes second. > > I'm fine with a warning at gem build time if the license is not set. > > I don't want to make it suddenly mandatory as that disrupts a gem > author's workflow. In order for this to be successful for gem > packagers, Rubyists need to agree it is a good thing. Some authors > will avoid upgrading RubyGems if mandatory requirements are added too > quickly. Perhaps in the future it can be made mandatory if gem > authors agree it is a good thing, but not for the present. > > As a repackager, if the license field is not set you should submit a > patch to the gem author to set it for them. This is really not just about repackager. It also affects users, like others have pointed out. Just to name the recent example of the BSD4 clause fun with the bcrypt-ruby dependency for rails 3.1. :) rubygems would be an ideal please to make gem packager aware of that a license is needed. you dont want to know how often i have to open bugs with gems "what is the license of your code"? because there is neither a license header in the source files, or a license/copyright file or at least a mention of the license in the readme. (not even in their SCM) And proposing to use the license tag standard recently pushed by the big linux distributions will also make integration work easier. no need to invent new acronyms, no need for mapping tables between the different names. the syntax can even handle multiple license in the same package and knows if the conditions are "and" or "or". So i would really like to vouch for making the the check a bit more strict when a license tag is found in the gem spec, but having it optional with warning for a few releases. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From erik at hollensbe.org Fri Oct 14 17:05:14 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Fri, 14 Oct 2011 14:05:14 -0700 Subject: Make license/licenses field mandatory In-Reply-To: <20111014191635.GE20237@nordisch.org> References: <4E959C14.6080704@opensuse.org> <20111014191635.GE20237@nordisch.org> Message-ID: <2F5C4505-7ADD-4D80-A1F6-0893F1F17E02@hollensbe.org> Top-posting hoooooooooooooo Ok guys, let's think about this from a simple logistics standpoint. Neither Eric or Nick are qualified to make legal judgments on, well, anything as far as I'm aware of. That means RubyCentral is going to need a full-time lawyer, or more like an army of them, to police the 100,000+ gems that are out there. Maybe if one of you wants to foot the bill? Remember, in the United States it is *ILLEGAL* to dispense legal advice unless you are a licensed lawyer. -Erik On Oct 14, 2011, at 12:16 PM, Marcus Rueckert wrote: > On 2011-10-13 12:58:29 -0700, Eric Hodel wrote: >> On Oct 12, 2011, at 6:54 AM, Pavol Rusnak wrote: >>> I'd like to propose making license/licenses field mandatory. While doing >>> rubygem packages for Linux distributions we have to deal with licenses a >>> lot and currently not having a license field in gemspec is the only >>> thing stopping us from doing automated packaging. One has to unpack the >>> gem, search for the license text and change the field by hand. If these >>> fields were mandatory (i.e. one or the other), it would make the whole >>> process much easier. In my opinion the license is very important aspect >>> of the gem similarly important as its name and I think also non-Linux >>> parts of Ruby ecosystem would benefit from that change. What do you think? >> >> >> The first goal of RubyGems is to provide useful tools for Rubyists to >> share libraries. The needs of repackagers comes second. >> >> I'm fine with a warning at gem build time if the license is not set. >> >> I don't want to make it suddenly mandatory as that disrupts a gem >> author's workflow. In order for this to be successful for gem >> packagers, Rubyists need to agree it is a good thing. Some authors >> will avoid upgrading RubyGems if mandatory requirements are added too >> quickly. Perhaps in the future it can be made mandatory if gem >> authors agree it is a good thing, but not for the present. >> >> As a repackager, if the license field is not set you should submit a >> patch to the gem author to set it for them. > > This is really not just about repackager. > > It also affects users, like others have pointed out. Just to name the > recent example of the BSD4 clause fun with the bcrypt-ruby dependency > for rails 3.1. :) > > rubygems would be an ideal please to make gem packager aware of that a > license is needed. you dont want to know how often i have to open bugs > with gems "what is the license of your code"? because there is neither a > license header in the source files, or a license/copyright file or at > least a mention of the license in the readme. (not even in their SCM) > > And proposing to use the license tag standard recently pushed by the big > linux distributions will also make integration work easier. no need to > invent new acronyms, no need for mapping tables between the different > names. the syntax can even handle multiple license in the same package > and knows if the conditions are "and" or "or". > > So i would really like to vouch for making the the check a bit more strict > when a license tag is found in the gem spec, but having it optional with > warning for a few releases. > > darix > > -- > openSUSE - SUSE Linux is my linux > openSUSE is good for you > www.opensuse.org > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From ryand-ruby at zenspider.com Fri Oct 14 17:28:20 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 14 Oct 2011 14:28:20 -0700 Subject: Make license/licenses field mandatory In-Reply-To: <4E959C14.6080704@opensuse.org> References: <4E959C14.6080704@opensuse.org> Message-ID: On Oct 12, 2011, at 06:54 , Pavol Rusnak wrote: > I'd like to propose making license/licenses field mandatory. I'm not opposed to adding a package-time warning if the license field is not filled out but making it mandatory right off the bat is a mistake that I'm not willing to make at this time. In the future we can tighten the belt and make the field mandatory. As for all the other suggestions saying there needs to be enforcement at multiple levels, absolutely not. This is out of scope for the OP's proposal and out of scope for what we're trying to do at this time. From darix at web.de Fri Oct 14 20:44:06 2011 From: darix at web.de (Marcus Rueckert) Date: Sat, 15 Oct 2011 02:44:06 +0200 Subject: Make license/licenses field mandatory In-Reply-To: <2F5C4505-7ADD-4D80-A1F6-0893F1F17E02@hollensbe.org> References: <4E959C14.6080704@opensuse.org> <20111014191635.GE20237@nordisch.org> <2F5C4505-7ADD-4D80-A1F6-0893F1F17E02@hollensbe.org> Message-ID: <20111015004406.GF20237@nordisch.org> On 2011-10-14 14:05:14 -0700, Erik Hollensbe wrote: > Top-posting hoooooooooooooo > > Ok guys, let's think about this from a simple logistics standpoint. > Neither Eric or Nick are qualified to make legal judgments on, well, > anything as far as I'm aware of. That means RubyCentral is going to > need a full-time lawyer, or more like an army of them, to police the > 100,000+ gems that are out there. > > Maybe if one of you wants to foot the bill? Remember, in the United > States it is *ILLEGAL* to dispense legal advice unless you are a > licensed lawyer. who said that ... all we want is 2 things: 1. optional have a license tag in the gem spec and warn when there is none. 2. if people use a license tag, use the same shortnames that the linux foundation defined. [1] no need to invent new tags now. if some dev puts the wrong license on something or later on mixes incompatible licenses that is out of the scope. darix [1] http://spdx.org/licenses/ (yes i know the site is down for maintenance atm) -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From darix at web.de Sat Oct 15 09:12:23 2011 From: darix at web.de (Marcus Rueckert) Date: Sat, 15 Oct 2011 15:12:23 +0200 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E959C14.6080704@opensuse.org> Message-ID: <20111015131223.GA15723@nordisch.org> On 2011-10-14 14:28:20 -0700, Ryan Davis wrote: > On Oct 12, 2011, at 06:54 , Pavol Rusnak wrote: > > > I'd like to propose making license/licenses field mandatory. > > I'm not opposed to adding a package-time warning if the license field > is not filled out but making it mandatory right off the bat is a > mistake that I'm not willing to make at this time. In the future we > can tighten the belt and make the field mandatory. > > As for all the other suggestions saying there needs to be enforcement > at multiple levels, absolutely not. This is out of scope for the OP's > proposal and out of scope for what we're trying to do at this time. well if you start with the spdx tags right from the beginning you save us all the problems with migrating to a defined set later on. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From ryand-ruby at zenspider.com Sun Oct 16 16:34:55 2011 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Sun, 16 Oct 2011 13:34:55 -0700 Subject: Make license/licenses field mandatory In-Reply-To: <20111015131223.GA15723@nordisch.org> References: <4E959C14.6080704@opensuse.org> <20111015131223.GA15723@nordisch.org> Message-ID: <4825FEEE-72EC-4F49-AD83-C67BF2077766@zenspider.com> On Oct 15, 2011, at 06:12 , Marcus Rueckert wrote: > On 2011-10-14 14:28:20 -0700, Ryan Davis wrote: >> On Oct 12, 2011, at 06:54 , Pavol Rusnak wrote: >> >>> I'd like to propose making license/licenses field mandatory. >> >> I'm not opposed to adding a package-time warning if the license field >> is not filled out but making it mandatory right off the bat is a >> mistake that I'm not willing to make at this time. In the future we >> can tighten the belt and make the field mandatory. >> >> As for all the other suggestions saying there needs to be enforcement >> at multiple levels, absolutely not. This is out of scope for the OP's >> proposal and out of scope for what we're trying to do at this time. > > well if you start with the spdx tags right from the beginning you save > us all the problems with migrating to a defined set later on. Patches welcome. From nick at quaran.to Sun Oct 16 19:57:54 2011 From: nick at quaran.to (Nick Quaranto) Date: Sun, 16 Oct 2011 19:57:54 -0400 Subject: contribute.rubygems.org first pass Message-ID: Here's my first draft! http://contribute.rubygems.org/ http://github.com/rubygems/contribute Maybe eventually we can hook up github issues/api integration, but for now it will do! Any feedback/thoughts would be really appreciated. From steve at steveklabnik.com Mon Oct 17 00:52:37 2011 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 17 Oct 2011 00:52:37 -0400 Subject: contribute.rubygems.org first pass In-Reply-To: References: Message-ID: Puuurdy. From erik at hollensbe.org Mon Oct 17 08:49:36 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Mon, 17 Oct 2011 05:49:36 -0700 Subject: contribute.rubygems.org first pass In-Reply-To: References: Message-ID: <5D2739AD-0243-41D7-8737-A1A525852B8F@hollensbe.org> Looks nice dude! The site seems a little slow atm though, figured I should say something. -Erik On Oct 16, 2011, at 4:57 PM, Nick Quaranto wrote: > Here's my first draft! > > http://contribute.rubygems.org/ > > http://github.com/rubygems/contribute > > Maybe eventually we can hook up github issues/api integration, but for now > it will do! > > Any feedback/thoughts would be really appreciated. > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From nick at quaran.to Mon Oct 17 10:16:16 2011 From: nick at quaran.to (Nick Quaranto) Date: Mon, 17 Oct 2011 10:16:16 -0400 Subject: contribute.rubygems.org first pass In-Reply-To: <5D2739AD-0243-41D7-8737-A1A525852B8F@hollensbe.org> References: <5D2739AD-0243-41D7-8737-A1A525852B8F@hollensbe.org> Message-ID: I wonder if it's just Heroku spinning up (it's only one dyno right now)...does it seem ok on subsequent loads? It's basically just a static site. On Mon, Oct 17, 2011 at 8:49 AM, Erik Hollensbe wrote: > Looks nice dude! The site seems a little slow atm though, figured I should > say something. > > -Erik > > On Oct 16, 2011, at 4:57 PM, Nick Quaranto wrote: > > > Here's my first draft! > > > > http://contribute.rubygems.org/ > > > > http://github.com/rubygems/contribute > > > > Maybe eventually we can hook up github issues/api integration, but for > now > > it will do! > > > > Any feedback/thoughts would be really appreciated. > > _______________________________________________ > > RubyGems-Developers mailing list > > http://rubyforge.org/projects/rubygems > > RubyGems-Developers at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From erik at hollensbe.org Mon Oct 17 11:10:10 2011 From: erik at hollensbe.org (Erik Hollensbe) Date: Mon, 17 Oct 2011 08:10:10 -0700 Subject: contribute.rubygems.org first pass In-Reply-To: References: <5D2739AD-0243-41D7-8737-A1A525852B8F@hollensbe.org> Message-ID: Yeah, I think you're right, it is quite a bit faster now. -Erik On Oct 17, 2011, at 7:16 AM, Nick Quaranto wrote: > I wonder if it's just Heroku spinning up (it's only one dyno right > now)...does it seem ok on subsequent loads? It's basically just a static > site. > > On Mon, Oct 17, 2011 at 8:49 AM, Erik Hollensbe wrote: > >> Looks nice dude! The site seems a little slow atm though, figured I should >> say something. >> >> -Erik >> >> On Oct 16, 2011, at 4:57 PM, Nick Quaranto wrote: >> >>> Here's my first draft! >>> >>> http://contribute.rubygems.org/ >>> >>> http://github.com/rubygems/contribute >>> >>> Maybe eventually we can hook up github issues/api integration, but for >> now >>> it will do! >>> >>> Any feedback/thoughts would be really appreciated. >>> _______________________________________________ >>> RubyGems-Developers mailing list >>> http://rubyforge.org/projects/rubygems >>> RubyGems-Developers at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rubygems-developers >> >> _______________________________________________ >> RubyGems-Developers mailing list >> http://rubyforge.org/projects/rubygems >> RubyGems-Developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers >> > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From alexch at gmail.com Tue Oct 18 13:58:24 2011 From: alexch at gmail.com (Alex Chaffee) Date: Tue, 18 Oct 2011 10:58:24 -0700 Subject: Make license/licenses field mandatory Message-ID: We've been discussing this on the gemcutter list too; here's a summary of my personal thoughts from that thread. --- I'd say limit the field to a single line, which contains either: * a URL to the license * a path to a file inside the gem itself (usually license.txt) * a short name, based on a standard dictionary of licenses On Mon, Oct 17, 2011 at 9:55 PM, 7rans wrote: > There is a standard, SPDX (spdx.org) Cool! The more I think about this -- which is still, admittedly, not vey much -- the more I think that a URI/URL is the way to go. Not so much for a clickable hyperlink -- which, as we can see now, is not always useful -- but as a, you know, Uniform format for Identifying and/or Locating a Resource, which is what a license field in a gem wants to do. Making our own dictionary would be a losing proposition; better to piggyback on spdx, even if it means typing "http://spdx.org/licenses/MIT" rather than "MIT" Though actually SPDX defines a "short identifer" too, so in that example, either could work. --- Also, to answer the actual question, generally, if things are mandatory, people get annoyed and fill in garbage, which wouldn't help anything. So I'd be quite wary of making anything mandatory, especially not without having a good answer for these questions: * What if I want to publish my gem with no license? * ...with a personally crafted license? * ...in the public domain? * What are the data structure rules for the field(s)? * i.e. ...Does "MIT" mean the same as "mit" as "MIT Public License" as "M.I.T."? * Whose short name dictionary are we using? Who's responsible for maintaining and updating that list? * What about different versions and variants of the same license? (I know you've covered a lot of these points already, but just wanted to restate the questions.) -- Alex Chaffee - alex at cohuman.com - http://alexch.github.com Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch | http://alexch.tumblr.com From drbrain at segment7.net Tue Oct 18 16:34:02 2011 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 18 Oct 2011 13:34:02 -0700 Subject: Make license/licenses field mandatory In-Reply-To: References: Message-ID: On Oct 18, 2011, at 10:58 AM, Alex Chaffee wrote: > We've been discussing this on the gemcutter list too; here's a summary > of my personal thoughts from that thread. > > --- > > I'd say limit the field to a single line, which contains either: > > * a URL to the license > * a path to a file inside the gem itself (usually license.txt) > * a short name, based on a standard dictionary of licenses > > On Mon, Oct 17, 2011 at 9:55 PM, 7rans wrote: >> There is a standard, SPDX (spdx.org) > > Cool! The more I think about this -- which is still, admittedly, not > vey much -- the more I think that a URI/URL is the way to go. Not so > much for a clickable hyperlink -- which, as we can see now, is not > always useful -- but as a, you know, Uniform format for Identifying > and/or Locating a Resource, which is what a license field in a gem > wants to do. > > Making our own dictionary would be a losing proposition; better to > piggyback on spdx, even if it means typing > "http://spdx.org/licenses/MIT" rather than "MIT" > > Though actually SPDX defines a "short identifer" too, so in that > example, either could work. When we introduced this the intention was short names only, so "MIT", "BSD", "GPL", "LGPL", etc. Since spdx.org is down for me with this message: > This site is down for maintenance. We will be restoring service shortly. Thank you for your patience. > > The Linux Foundation and the entries in the list are limited to 64 characters, using a URL isn't a workable option and a file path is restricted as well. We'll just use short names since they're easy for authors to write. Being easy to use but lossy is better than hard to use and "correct". > --- > > Also, to answer the actual question, generally, if things are > mandatory, people get annoyed and fill in garbage, which wouldn't help > anything. > > So I'd be quite wary of making anything mandatory, especially not > without having a good answer for these questions: > > * 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") > * ...in the public domain? "public domain" > * What are the data structure rules for the field(s)? short names only > * i.e. ...Does "MIT" mean the same as "mit" as "MIT Public License" as "M.I.T."? Yes, because that's common sense. It needs to be easy for authors and we need to give them reasonable guidelines (like pointing at spdx.org). Then we need to yell at people for doing it wrong when reasonable. > * Whose short name dictionary are we using? Who's responsible for > maintaining and updating that list? When spdx.org comes back I'll look at it, but we're probably going to be using spdx.org's. > * What about different versions and variants of the same license? Whatever spdx.org says. I guess they have things like "GPL" or "GPL2" or "GPL3" and "BSD" or "BSD-2clause" or "BSD 3-clause". From alex at stinky.com Tue Oct 18 17:31:51 2011 From: alex at stinky.com (Alex Chaffee) Date: Tue, 18 Oct 2011 14:31:51 -0700 Subject: Make license/licenses field mandatory In-Reply-To: References: Message-ID: Dr. Brain is brainy! I like all those answers :-) > * ...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") So not to get all pedantic on you, but probably your beerware license is going to be worded differently from my beerware license, but if we both use the same term then... well, then what? What are the potential risks and ramifications, for either the publisher, or the site, or the site user? (I said I hadn't thought through this very much, right?) And then maybe later someone will submit a beerware license to spdx.org and suddenly the term "beerware" means something official, which isn't exactly what you or I thought it meant when we published it... > * Whose short name dictionary are we using? Who's responsible for > > maintaining and updating that list? > > When spdx.org comes back I'll look at it, but we're probably going to be > using spdx.org's. Word on the street is that they had a security breach. For some reason that strikes me as ironic, but maybe it's just sad. -- Alex Chaffee - alex at stinky.com http://alexchaffee.com http://twitter.com/alexch From drbrain at segment7.net Tue Oct 18 19:24:33 2011 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 18 Oct 2011 16:24:33 -0700 Subject: Make license/licenses field mandatory In-Reply-To: References: Message-ID: <8C92A249-CA27-427C-BB71-D3CD30699133@segment7.net> On Oct 18, 2011, at 2:31 PM, Alex Chaffee wrote: >> * ...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") > > So not to get all pedantic on you, but probably your beerware license is > going to be worded differently from my beerware license, but if we both use > the same term then... well, then what? Then one (or both) of us is being a jerk: http://en.wikipedia.org/wiki/Beerware > What are the potential risks and ramifications, for either the publisher, or the site, or the site user? (I said I hadn't thought through this very much, right?) Open source projects usually have code mingled from many different sources. Ironing these out properly requires reading the license and looking through the source to see if different portions have different licenses. It's up to the author to pick the license that matches something from the list or to choose a unique-enough name for a new license and register that somewhere. The licenses list can only ever act like a sticker on the box. Making it more than just a sticker is an attempt to solve a social and legal problem that is going to annoy authors. > And then maybe later someone will submit a beerware license to spdx.org and > suddenly the term "beerware" means something official, which isn't exactly > what you or I thought it meant when we published it? I don't think it is worth our time to worry about such a "what-if" scenario, the license attribute is just a sticker on the box. From prusnak at opensuse.org Wed Oct 19 09:21:01 2011 From: prusnak at opensuse.org (Pavol Rusnak) Date: Wed, 19 Oct 2011 15:21:01 +0200 Subject: Make license/licenses field mandatory In-Reply-To: References: Message-ID: <4E9ECEBD.6000809@opensuse.org> Most of the things you wrote make sense. Thanks Eric! 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") > >> * ...in 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. Some examples: - Public domain is not valid outside US - Beerware makes your work non-redistributable (as a part of bigger FOSS project) - etc., etc. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic From drbrain at segment7.net Wed Oct 19 14:05:21 2011 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 19 Oct 2011 11:05:21 -0700 Subject: Make license/licenses field mandatory In-Reply-To: <4E9ECEBD.6000809@opensuse.org> References: <4E9ECEBD.6000809@opensuse.org> Message-ID: <43A9B8C9-D121-4C40-A265-D54346AE4D50@segment7.net> 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") >> >>> * ...in 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: http://people.freebsd.org/~phk/ From y_feldblum at yahoo.com Wed Oct 19 14:33:55 2011 From: y_feldblum at yahoo.com (Jay Feldblum) Date: Wed, 19 Oct 2011 14:33:55 -0400 Subject: Make license/licenses field mandatory In-Reply-To: <43A9B8C9-D121-4C40-A265-D54346AE4D50@segment7.net> References: <4E9ECEBD.6000809@opensuse.org> <43A9B8C9-D121-4C40-A265-D54346AE4D50@segment7.net> Message-ID: The lawyers are crazy ... right up until someone gets sued. The important questions in this thread are: 1. What could RubyGems.org 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 RubyGems.org 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). RubyGems.org could guide its users towards uploading only licensed software where RubyGems.org 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. RubyGems.org 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 RubyGems.org should *guide*, but does *not* need to *force*, gem authors to license their gems. The point is education, metadata, and the pit of success, not dictatorship. Cheers, Jay Feldblum On Wed, Oct 19, 2011 at 2:05 PM, Eric Hodel 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") > >> > >>> * ...in 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: http://people.freebsd.org/~phk/ > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From prusnak at opensuse.org Wed Oct 19 15:09:42 2011 From: prusnak at opensuse.org (Pavol Rusnak) Date: Wed, 19 Oct 2011 21:09:42 +0200 Subject: Make license/licenses field mandatory In-Reply-To: <43A9B8C9-D121-4C40-A265-D54346AE4D50@segment7.net> References: <4E9ECEBD.6000809@opensuse.org> <43A9B8C9-D121-4C40-A265-D54346AE4D50@segment7.net> Message-ID: <4E9F2076.40508@opensuse.org> On 19/10/11 20:05, Eric Hodel wrote: > RubyGems cannot stop authors from picking a license of their choice. I know. That's why I wrote it as an appeal to rubygem authors, not as an enforcement policy. >> 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. Again, see above. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic From drbrain at segment7.net Wed Oct 19 17:39:31 2011 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 19 Oct 2011 14:39:31 -0700 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E9ECEBD.6000809@opensuse.org> <43A9B8C9-D121-4C40-A265-D54346AE4D50@segment7.net> Message-ID: On Oct 19, 2011, at 11:33 AM, Jay Feldblum wrote: > 1. What could RubyGems.org 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 RubyGems.org do in that regard? RubyGems already has a licenses field designed for short names, but RubyGems can't provide any guarantees. > 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). Continuing to argue this point on this mailing list will get you nowhere. I can't control what gem authors do and I have very limited power to push them in any particular direction. You are going to need to write up some documents to educate gem authors. I don't have the time or passion to write up such a document and none of the other committers have shown an interest. If you wish to see further movement you need to start educating authors. I can help publicize what you write. > RubyGems.org could guide its users towards uploading only licensed software > where RubyGems.org knows about the license used (e.g. it's a SPDX license > tag). Have you not been reading this thread? We've already agreed to using the SPDX tags, but will not enforce any restriction at this time. > RubyGems.org 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. I can't speak for Nick, but I believe he has his hands full between his work responsibilities and the existing maintenance burden of running rubygems.org. If you wish to see such features you will need to write them. From nick at quaran.to Wed Oct 19 17:58:17 2011 From: nick at quaran.to (Nick Quaranto) Date: Wed, 19 Oct 2011 17:58:17 -0400 Subject: Make license/licenses field mandatory In-Reply-To: References: <4E9ECEBD.6000809@opensuse.org> <43A9B8C9-D121-4C40-A265-D54346AE4D50@segment7.net> Message-ID: So I and the other RG.org maintainers don't forget: https://github.com/rubygems/rubygems.org/issues/363 On Wed, Oct 19, 2011 at 5:39 PM, Eric Hodel wrote: > On Oct 19, 2011, at 11:33 AM, Jay Feldblum wrote: > > 1. What could RubyGems.org 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 RubyGems.org do in that regard? > > RubyGems already has a licenses field designed for short names, but > RubyGems can't provide any guarantees. > > > 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). > > Continuing to argue this point on this mailing list will get you nowhere. > I can't control what gem authors do and I have very limited power to push > them in any particular direction. > > You are going to need to write up some documents to educate gem authors. I > don't have the time or passion to write up such a document and none of the > other committers have shown an interest. If you wish to see further > movement you need to start educating authors. I can help publicize what you > write. > > > RubyGems.org could guide its users towards uploading only licensed > software > > where RubyGems.org knows about the license used (e.g. it's a SPDX license > > tag). > > Have you not been reading this thread? We've already agreed to using the > SPDX tags, but will not enforce any restriction at this time. > > > RubyGems.org 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. > > I can't speak for Nick, but I believe he has his hands full between his > work responsibilities and the existing maintenance burden of running > rubygems.org. If you wish to see such features you will need to write > them. > > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From noreply at rubyforge.org Thu Oct 20 21:18:23 2011 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 20 Oct 2011 21:18:23 -0400 (EDT) Subject: [ rubygems-Bugs-22617 ] Gem.loaded_specs does not work on 1.9 Message-ID: <20111021011823.48DCB15B802E@rubyforge.org> Bugs item #22617, was opened at 2008-10-30 09:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126 Category: other Group: v1.3.x Status: Closed Resolution: Accepted Priority: 3 Submitted By: Paul Brannan (cout) Assigned to: Evan Phoenix (evan) Summary: Gem.loaded_specs does not work on 1.9 Initial Comment: The loaded_specs attribute seems to always be empty on 1.9: [pbrannan at zem ruby]$ ruby -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs' {"ruby-prof"=>#=", #]]>, @version=#, @files=["Rakefile", "README", "LICENSE", "CHANGES", "bin/ruby-prof", "lib/ruby-prof", "lib/ruby-prof.rb", "lib/unprof.rb", "lib/ruby-prof/abstract_printer.rb", "lib/ruby-prof/call_tree_printer.rb", "lib/ruby-prof/call_tree_printer.rb.rej", "lib/ruby-prof/flat_printer.rb", "lib/ruby-prof/graph_html_printer.rb", "lib/ruby-prof/graph_printer.rb", "lib/ruby-prof/profile_test_case.rb", "lib/ruby-prof/task.rb", "rails_plugin/ruby-prof", "rails_plugin/ruby-prof/init.rb", "rails_plugin/ruby-prof/lib", "rails_plugin/ruby-prof/lib/profiling.rb", "examples/flat.txt", "examples/graph.html", "examples/graph.txt", "ext/extconf.rb", "ext/extconf.rb.rej", "ext/measure_allocations.h", "ext/measure_cpu_time.h", "ext/measure_memory.h", "ext/measure_process_time.h", "ext/measure_wall_time.h", "ext/ruby_prof.c", "test/basic_test.rb", "test/duplicate_names_test.rb", "test/line_number_test.rb", "test/measure_mode_test.rb", "test/module_test.rb", "test/no_method_class_test.rb", "test/prime.rb", "test/prime1.rb", "test/prime2.rb", "test/prime3.rb", "test/prime_test.rb", "test/printers_test.rb", "test/profile_unit_test.rb", "test/recursive_test.rb", "test/singleton_test.rb", "test/start_test.rb", "test/test_helper.rb", "test/test_suite.rb", "test/thread_test.rb", "test/timing_test.rb"], @has_rdoc=true, @specification_version=2, @loaded=true, @requirements=[], @signing_key=nil, @default_executable="ruby-prof", @email="shugo at ruby-lang.org and cfis at savagexi.com", @required_ruby_version=#=", #]]>, @rdoc_options=["--title", "ruby-prof", "--inline-source", "--line-numbers", "--main", "README"], @bindir="bin", @rubygems_version="1.2.0", @homepage="http://rubyforge.org/projects/ruby-prof/", @name="ruby-prof", @platform="ruby", @autorequire=nil, @rubyforge_project="ruby-prof", @extensions=["ext/extconf.rb"], @summary="Fast Ruby profiler", @loaded_from="/usr/local/lib/ruby/gems/1.8/specifications/ruby-prof-0.6.0.gemspec", @original_platform=nil, @post_install_message=nil, @description="ruby-prof is a fast code profiler for Ruby. It is a C extension and therefore is many times faster than the standard Ruby profiler. It supports both flat and graph profiles. For each method, graph profiles show how long the method ran, which methods called it and which methods it called. RubyProf generate both text and html and can output it to standard out or to a file.", @dependencies=[], @test_files=["test/test_helper.rb", "test/test_suite.rb"], @require_paths=["bin", "lib"]>} [pbrannan at zem ruby]$ ruby1.9 -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs' /usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 216:'def' and line 218:'end' /usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 231:'def' and line 233:'end' /usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 246:'def' and line 248:'end' /usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 261:'def' and line 263:'end' {} ---------------------------------------------------------------------- Comment By: cczona (cczona) Date: 2011-10-20 18:18 Message: Yes, still happening in Ruby 1.9.1-p431 (currently HEAD), p430, and p378. A workaround is to call Gem.loaded_path before any 'require" or 'gem' statements. Gem.loaded_path subsequently populates properly. gem_prelude is known to have issues in certain patchlevels of 1.9.1 See for instance http://redmine.ruby-lang.org/issues/2404 ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2010-11-13 01:36 Message: Yeah, Evan took this on, it's his game now. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-12 20:06 Message: This was rejected because it is invalid. gem_prelude supersedes rubygems in 1.9. I doubt there is anything we can or should do (to rubygems). ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2010-11-12 15:28 Message: This one appears to still be valid. (standard users are unable to re-open tickets.) ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-12 14:46 Message: This ticket has been deemed stale and we're closing it in order to catch up with our ticket list. If you think it is still valid, please reopen. ---------------------------------------------------------------------- Comment By: Giorgenes Gelatti (giorgenes) Date: 2010-07-08 10:23 Message: I can't require 'gemname' on ruby1.9.1. Could it be related? ---------------------------------------------------------------------- Comment By: Roger Pack (rogerdpack) Date: 2010-01-18 18:44 Message: you can run ruby --disable-gems (I think) to disable gem prelude (auto loading of gem lib dirs). Barring that, you could submit a patch that compares $LOADED_FEATURES with the load paths of existing gems and "infers" "we have already loaded those other gems via the normal mechanism" Cheers! -r ---------------------------------------------------------------------- Comment By: Nikolai Weibull (pcp) Date: 2009-10-21 13:36 Message: Yes, I would love to be able to provide a patch, but I don?t see a solution. To me it looks like this is an inherent flaw in how Ruby 1.9 and Rubygems interact. Since Ruby 1.9 adds all the paths to gems installed on your system, Rubygems never gets a chance to load the specs and thus solve this problem. I have no idea why it was decided that Ruby 1.9 should augment its $LOAD_PATH in this way, nor why these things weren?t considered at the time, but it would be great if someone came up with a solution. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-10-21 10:00 Message: Whiny you sound, patches are welcome too :-) ---------------------------------------------------------------------- Comment By: Nikolai Weibull (pcp) Date: 2009-10-21 09:48 Message: This is still the case on Windows 1.9.1-p243. By extension, Config.datadir, which is what I care about, doesn?t work. I don?t want to sound whiny, but I can?t see how this can have gone unfixed for close to a year now. It seems like a rather central concept. ---------------------------------------------------------------------- Comment By: Matt Hulse (mhulse) Date: 2009-08-04 16:27 Message: Yes, this is still happening in 1.9.1-p129. I'm on WinXP Pro using the mingw32 build from rubyinstaller.org/downloads. I just updated to rubygems 1.3.5 using gem update --system and Gem.loaded_specs is still empty until I call gem('') or gem('nokogiri') (the gem I'm looking for). ---------------------------------------------------------------------- Comment By: Joeri Samson (joeri) Date: 2009-03-29 11:42 Message: with 1.9.1p0 and rubygems 1.3.1 I get the same error as Eric Hodel, except if I print/access Gem.loaded_specs before calling gem "rake": joeri at alpha ~ $ ruby19 -rubygems -e 'p Gem.loaded_specs; gem("rake"); p Gem.loaded_specs' {} {"rake"=>#, @summary="Ruby based make-like utility.", @email="jim at weirichhouse.org", @homepage="http://rake.rubyforge.org", @rubyforge_project="rake", @description="Rake is a Make-like program implemented in Ruby. Tasks and dependencies are specified in standard Ruby syntax.", @autorequire=nil, @default_executable="rake", @signing_key=nil, @post_install_message=nil, @original_platform=nil, @rubygems_version="1.3.1", @specification_version=2, @date=2009-03-04 00:00:00 +0100, @require_paths=["bin", "lib"], @bindir="bin", @has_rdoc=true, @required_ruby_version=#=", #]], @version=nil>, @required_rubygems_version=#=", #]], @version=nil>, @platform="ruby", @cert_chain=[], @authors=["Jim Weirich"], @files=["install.rb", "CHANGES", "MIT-LICENSE", "Rakefile", "README", "TODO", "bin/rake", "lib/rake/classic_namespace.rb", "lib/rake/clean.rb", "lib/rake/contrib/compositepublisher.rb", "lib/rake/contrib/ftptools.rb", "lib/rake/contrib/publisher.rb", "lib/rake/contrib/rubyforgepublisher.rb", "lib/rake/contrib/sshpublisher.rb", "lib/rake/contrib/sys.rb", "lib/rake/gempackagetask.rb", "lib/rake/loaders/makefile.rb", "lib/rake/packagetask.rb", "lib/rake/rake_test_loader.rb", "lib/rake/rdoctask.rb", "lib/rake/repaired_system.rb", "lib/rake/ruby182_test_unit_fix.rb", "lib/rake/runtest.rb", "lib/rake/tasklib.rb", "lib/rake/testtask.rb", "lib/rake/win32.rb", "lib/rake.rb", "test/capture_stdout.rb", "test/check_expansion.rb", "test/contrib/test_sys.rb", "test/data/rakelib/test1.rb", "test/data/rbext/rakefile.rb", "test/filecreation.rb", "test/functional.rb", "test/in_environment.rb", "test/rake_test_setup.rb", "test/reqfile.rb", "test/reqfile2.rb", "test/session_functional.rb", "test/shellcommand.rb", "test/test_application.rb", "test/test_clean.rb", "test/test_definitions.rb", "test/test_earlytime.rb", "test/test_extension.rb", "test/test_file_creation_task.rb", "test/test_file_task.rb", "test/test_filelist.rb", "test/test_fileutils.rb", "test/test_ftp.rb", "test/test_invocation_chain.rb", "test/test_makefile_loader.rb", "test/test_multitask.rb", "test/test_namespace.rb", "test/test_package_task.rb", "test/test_pathmap.rb", "test/test_rake.rb", "test/test_rdoc_task.rb", "test/test_require.rb", "test/test_rules.rb", "test/test_task_arguments.rb", "test/test_task_manager.rb", "test/test_tasklib.rb", "test/test_tasks.rb", "test/test_test_task.rb", "test/test_top_level_functions.rb", "test/test_win32.rb", "test/data/imports/deps.mf", "test/data/sample.mf", "test/data/chains/Rakefile", "test/data/default/Rakefile", "test/data/dryrun/Rakefile", "test/data/file_creation_task/Rakefile", "test/data/imports/Rakefile", "test/data/multidesc/Rakefile", "test/data/namespace/Rakefile", "test/data/statusreturn/Rakefile", "test/data/unittest/Rakefile", "test/data/unittest/subdir", "doc/command_line_usage.rdoc", "doc/example", "doc/example/a.c", "doc/example/b.c", "doc/example/main.c", "doc/example/Rakefile1", "doc/example/Rakefile2", "doc/glossary.rdoc", "doc/jamis.rb", "doc/proto_rake.rdoc", "doc/rake.1.gz", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @test_files=[], @rdoc_options=["--line-numbers", "--inline-source", "--main", "README", "--title", "Rake -- Ruby Make"], @extra_rdoc_files=["README", "MIT-LICENSE", "TODO", "CHANGES", "doc/command_line_usage.rdoc", "doc/glossary.rdoc", "doc/proto_rake.rdoc", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @executables=["rake"], @extensions=[], @requirements=[], @dependencies=[], @loaded=true, @loaded_from="/home/joeri/.gem/ruby/1.9.1/specifications/rake-0.8.4.gemspec">} ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2009-03-27 14:29 Message: With 1.9.1p0 and 1.9.2dev I see: $ ruby19 -v -rubygems -e 'gem "rake"; p Gem.loaded_specs' ruby 1.9.2dev (2009-03-28 trunk 23085) [i386-darwin9.6.0] :234:in `push_gem_version_on_load_path': Could not find RubyGem rake (>= 0) (Gem::LoadError) from :14:in `gem' from -e:1:in `
' This will take a bit more work than I planned for 1.3.1, and may require changes to gem_prelude :/ ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-03-16 03:50 Message: Ah, no, I hit .activate, which hits source_index. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-03-16 03:48 Message: works for me ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-02 07:59 Message: Is this still happening in 1.9.1? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126 From luislavena at gmail.com Sat Oct 22 05:08:40 2011 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 22 Oct 2011 11:08:40 +0200 Subject: [ruby-core:40273] Re: Can rubygems save us from "binary-compatibility hell"? In-Reply-To: References: Message-ID: Hello, Please see comments inline... On Sat, Oct 22, 2011 at 5:21 AM, Eric Hodel wrote: > >> The other is a binary gem that includes a compiled extension >> library. ?TEENY release will be done about every year. ?This >> is not a technical issue, but do you think it is reasonable >> to make gem developers release their binary gems when new >> Ruby is released? > > I think it depends on the developer. ?I can make a list of recent platform gems so we can consult the authors. ?With the addition of the Developer Kit for Windows rubyists it may not be as big a concern now as it has been in the past. ?Luis can comment better here. > Well, that depends on what are the dependencies of those gems. If the gem just use C extension for speed and don't depend on external libraries (e.g. RedCloth, rdiscount, hpricot) then is not an issue if there is no binary gem for the newer version of Ruby. But, this is a problem for more complex gems like EventMachine, nokogiri and others that depend on externals (openssl, libxml2). More than that, there is an existing problem with RubyGems that forced us to create "fat-binary" gems which include binaries for 1.8.x and 1.9.x so gem can be installed properly. Projects like rake-compiler made this task a bit more easy, yet still requires gem author certain environment adjustments. While 1.8.x usage has been reduced lately, it is still present. With this ABI compatibility change it will require those gem authors wanting to provide fat-binary gems for every single ABI version in the same gem. I've presented this issue before at rubygems developer list, April 2009: http://rubyforge.org/pipermail/rubygems-developers/2009-April/004522.html >> And, is it possible to allow users to use, with a new Ruby, an old gem that does not support the new Ruby with a warning? > > This would require further adjustments to RubyGems, but I think it is possible. ?Some of the adjustments are related to the stdlib gems proposal (coming soon). > Perhaps RubyGems' Specification will require to be extended to a list of versions the gem is compatible with and not just one unique version? Those are my only concerns: gem authors overhead when packaging binary gems and making more easy to gem users install them without falling into the compile-your-own rabbit hole. Thank you. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From nick at quaran.to Fri Oct 28 16:23:12 2011 From: nick at quaran.to (Nick Quaranto) Date: Fri, 28 Oct 2011 16:23:12 -0400 Subject: contribute.rubygems.org first pass In-Reply-To: References: Message-ID: Launched this guy: https://twitter.com/#!/qrush/status/130015747513659393 http://contribute.rubygems.org/ And it's in the new footer on http://rubygems.org. Woot! On Sun, Oct 16, 2011 at 7:57 PM, Nick Quaranto wrote: > Here's my first draft! > > http://contribute.rubygems.org/ > > http://github.com/rubygems/contribute > > Maybe eventually we can hook up github issues/api integration, but for now > it will do! > > Any feedback/thoughts would be really appreciated. > From luislavena at gmail.com Sun Oct 30 19:59:38 2011 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 30 Oct 2011 20:59:38 -0300 Subject: Ruby 1.9.3 is out, where is RubyGems 1.8.11? Message-ID: Hello, I noticed there is no packages for RubyGems 1.8.11 at RubyForge: http://rubyforge.org/frs/?group_id=126&release_id=46225 But there is the rubygems-update available: http://rubygems.org/gems/rubygems-update/versions/1.8.11 Would you mind pushing the tgz packages to RubyForge? Or update the ones in RubyGems.org: http://rubygems.org/pages/download This is required for me to upgrade RubyInstaller releases too. Thank you. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry