Recommended way to install Rubygems
in [Ruby]
|
From: Austin Ziegler on 19 Mar 2010 08:44 On Fri, Mar 19, 2010 at 5:16 AM, Brian Candler <b.candler(a)pobox.com> wrote: > Austin Ziegler wrote: >> Lawyers will agree that there's a distribution incompatibility since >> the GNU GPL doesn't permit attribution requirements and OpenSSL >> requires it under two different licences. > If Debian are worried about infringement, then who do they think is > going to sue them? It's subtly more complex than that. While IANAL, I suspect that Debian and the other distribution managers are fairly safe here since they don't require that you have OpenSSL by default, and provide OpenSSL as a dynamically loadable object when requested by the end user (implicitly or explicitly). As I said in an earlier message, the FSF takes a maximal view on the applicability of the GNU GPL, extending to situations that are not logically covered by the GNU GPL (e.g., run-time combination). It is fairly clear that if I were to distribute an application that requires both OpenSSL (with the attribution clauses) and libreadline (under the GNU GPL), I would be violating the license of one of them or another (probably the GNU GPL because it has the incompatibility with attribution requirements). If, on the other hand, OpenSSL and/or libreadline are optional components that end users enable at run-time, the situation is likely the opposite of what the FSF says (that is, no license violation; just the violation of the spirit of the GNU GPL). By the way, this is one of the things that annoys me about a lot of GPLed projects on Windows: they present the GNU GPL as a EULA, when it's completely NOT a EULA. I do not need to accept the GNU GPL to *use* a piece of software; just to distribute it. It's arguable that the GNU GPL v3 and the Affero GPL step into EULA territory by treating networked use as distribution, but that is an untested area of the licences. More reason to avoid both versions, IMO. > (1) The OpenSSL copyright holders? > > http://www.openssl.org/support/faq.html#LEGAL2 > > Clearly, they see it as an issue of the GPL holders needing to extend > their licence, not OpenSSL intending to restrict what GPL authors do. They're also right. OpenSSL's license is extremely permissive, even if the attribution requirement is annoying. > 'If you develop open source software that uses OpenSSL, you may find > it useful to choose an other license than the GPL, or state explicitly > that "This program is released under the GPL with the additional > exemption that compiling, linking, and/or using OpenSSL is allowed."' > > Anyway, if the OpenSSL licence requires attribution, surely that > applies only to OpenSSL itself? Do people think that it is viral in > the way that the GPL is viral? No; the problem is that the GNU GPL does not allow "subordinate"[1] licences to have any restrictions above and beyond what the GNU GPL has, "restricting" end-user rights further[2]. -austin [1] The GNU GPL views all licences in a mixed license bundle as subordinate to itself, as it's an expansive, viral license[3]. That is to say that the language of the GNU GPL expects that it will be the final arbiter of what is permitted and what is not permitted for a composite work containing GNU GPL software. [2] In many ways, I agree with this restriction, if not the implementation. It would be fairly trivial to put language in the GNU GPL enumerating additional optional exceptions for other 'open' licences (e.g., attribution clauses). I am not sure that the original 4-clause BSD license (with advertising attribution clauses) would pass the GNU GPL with that anyway, nor am I sure that it should pass. [3] The GNU GPL is correctly viewed as a viral license in that it imposes requirements on software that includes software under the GNU GPL. This virality is a feature of the GNU GPL. It's a feature that I strongly dislike, but it is exactly the purpose for which the GNU GPL was written. -- Austin Ziegler halostatue(a)gmail.com austin(a)halostatue.ca http://www.halostatue.ca/ http://twitter.com/halostatue
From: Aldric Giacomoni on 19 Mar 2010 08:56 Lucas Nussbaum wrote: > On 19/03/10 at 06:44 +0900, John W Higgins wrote: > >> ebuild (including full dependency checks from the gem itself). Does it work >> flexibility - again looking at Gentoo it somehow, in a very much automated >> fashion, manages to handle all these wild and wacky libraries. >> >> In fact you might want to look at Gentoo as a way to create sources packages >> because it seems to handle all your issues and will present a nice simple >> tar.bz2 package of the files that might be much easier to work with in >> regards to your need for standardization. And I'm truly not saying that to >> be an idiot or anything - it really seems like Gentoo has solved the issues >> you are having, at least with respect to getting the files into some form of >> a constant layout which may be of great help to you. Well.. Gentoo also builds from source, so it tends to have all the header files! In addition, it doesn't shy away from adding requirements to ebuilds. I had an issue, in fact, where xemacs kept on being re-installed on my machine, and I eventually tracked the problem down to a specific USE flag on my (cue suspenseful music) dev-lang/ruby package. That's right.. Ruby required xemacs;-) I removed the USE flag and xemacs never came back. > I agree that we could have a better infrastructure on the Debian side to > deal with that, and automate many of the tasks. None of the problems are > particularly hard, we just all lack time (and motivation to work on a > somehow poisonous issue). > > I really think that, in the end, whether to plug into the gems system > (like Gentoo does) or to leave it for manual installs by the user (like > Debian does) is mainly a matter of taste. This is true. > Btw, I see in the github portage tree that former versions for gems are > apparently no longer available. How do you deal with gems that require a > specific (ancient) version of another gem? Besides the official portage tree, there are overlays; there is an overlay dedicated to Ruby, which has much more than the regular tree. You are right, though - there is a limitation, and the limitation always is "Who has created an ebuild (or .deb package) for this version of the gem?" If the version we need isn't in the tree or the overlay, then either we create an ebuild for it or we install it with rubygems. -- Posted via http://www.ruby-forum.com/.
From: Lucas Nussbaum on 19 Mar 2010 16:05 On 19/03/10 at 20:22 +0900, Brian Candler wrote: > Lucas Nussbaum wrote: > > Note that Freeradius has a exception for OpenSSL in src/LICENSE.openssl. > > Ah, that's pretty recent, thanks for pointing it out. I look forward to > an EAP-capable freeradius out of the box. > > > Ruby doesn't AFAICS. > > Has it been requested? http://redmine.ruby-lang.org/issues/show/2982 -- | Lucas Nussbaum | lucas(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F |
From: James Nathan on 20 Mar 2010 22:24 i have used this program and it is all ways ziped and hard to download. --- On Thu, 3/18/10, James Edward Gray II <james(a)graysoftinc.com> wrote: From: James Edward Gray II <james(a)graysoftinc.com> Subject: Re: Recommended way to install Rubygems To: "ruby-talk ML" <ruby-talk(a)ruby-lang.org> Date: Thursday, March 18, 2010, 10:01 AM On Mar 18, 2010, at 10:53 AM, Lucas Nussbaum wrote: > On 19/03/10 at 00:35 +0900, James Edward Gray II wrote: >> On Mar 18, 2010, at 10:15 AM, Lucas Nussbaum wrote: >> >>> Note there are not many development communities that are proud of the >>> fact of having different, incompatible versions of the same software >>> being widely used at the same time. >>> >>> Most other communities solve that by having more stable APIs and making >>> sure that their important software supports the latest API. >> >>> Of course, if you want to install many different Ruby and gems versions, >>> and then try to keep them in a sensible state wrt security issues (which >>> are not that uncommon in the ruby world), that's your choice. >> >> You have lost the high ground in the civility argument. > > Why? What do you disagree with? I wasn't agreeing or disagreeing with anything. I was pointing out that you yourself have stopped being civil in the quoted comments above. James Edward Gray II
From: Robert Dober on 21 Mar 2010 14:45
On Thu, Mar 18, 2010 at 10:27 AM, Lucas Nussbaum <lucas(a)lucas-nussbaum.net> wrote: > On 18/03/10 at 17:10 +0900, Ryan Davis wrote: >> >> On Mar 18, 2010, at 00:47 , Lucas Nussbaum wrote: >> >> > Which parts of ruby which are currently split out would you like to see >> > installed when the user installs ruby? For example, ruby ships a ruby >> > emacs mode. Installing that would require adding a dependency on emacs, >> > which doesn't sound reasonable. >> >> That's a bullshit rationalization. > > See why I don't want to discuss this? ;-) Strange, don't you like being insulted? (1) Anyway as a (thankfull) user of Ruby and Ubuntu I vote against any preinstalled gem, that is just asking for trouble. For things like ruby-emacs should that not go into emcas rather? Cheers Robert (1) Depends by whom, I guess ;). > -- > | Lucas Nussbaum > | lucas(a)lucas-nussbaum.net http://www.lucas-nussbaum.net/ | > | jabber: lucas(a)nussbaum.fr GPG: 1024D/023B3F4F | > > -- Learning without thought is labor lost; thought without learning is perilous. --- Confucius |