From: Austin Ziegler on
On Fri, Mar 19, 2010 at 5:16 AM, Brian Candler <b.candler(a)> 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?
> 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].

[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) • austin(a) •

From: Aldric Giacomoni on
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
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

From: Lucas Nussbaum on
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?
| Lucas Nussbaum
| lucas(a) |
| jabber: lucas(a) GPG: 1024D/023B3F4F |

From: James Nathan on
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)> wrote:

From: James Edward Gray II <james(a)>
Subject: Re: Recommended way to install Rubygems
To: "ruby-talk ML" <ruby-talk(a)>
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
On Thu, Mar 18, 2010 at 10:27 AM, Lucas Nussbaum
<lucas(a)> 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?

(1) Depends by whom, I guess ;).

> --
> | Lucas Nussbaum
> | lucas(a) |
> | jabber: lucas(a)             GPG: 1024D/023B3F4F |

Learning without thought is labor lost; thought without learning is perilous.”
--- Confucius