From: James Edward Gray II on
On Mar 18, 2010, at 11:16 AM, Lucas Nussbaum wrote:

> I think that the following are true:

> - there are several versions of the interpreter being all widely used
> (ruby 1.8.6, 1.8.7, and to a lesser degree unfortunately, 1.9.X)

We don't do this because we prefer it that way. Our language is in transition.

> - other scripting languages don't have as many API problems as ruby
> (look at perl or python -- well, python has some for python 3.X)
> - ruby has had several security issues over the past year. Every complex
> and famous software package has some, that's life. But managing
> security when you have several versions co-installed manually is
> harder than when you just have to 'apt-get upgrade'.

These strike me as gross over generalizations.

James Edward Gray II
From: Nick Brown on
Lucas Nussbaum wrote:
> I really think that this problem is a minor one, and not worth all the
> noise around it.

It may be a minor problem on the individual level, but a minor problem
which is very wide-spread becomes a much larger problem cumulatively.
Just changing the way the packages are named would probably solve this
minor-yet-common usability issue.

> I'll see with the other maintainers if there's a way we
> can improve the situation slightly. But the licensing issues involved
> make me fear that it is unlikely.

Awesome, thanks for checking! Maybe making the "ruby" package part of
the repository that isn't picky about licenses, and putting the
"ruby-minimal" package in the standard repository would help...

> That's not a reason to consider [a rude tone] acceptable.

Agreed! But since the problem will never be solved, we might as well
just accept that Internet anonymity causes temporary brain damage in
some people, and we should pity those so afflicted rather than let them
upset us ;-)
--
Posted via http://www.ruby-forum.com/.

From: Austin Ziegler on
On Thu, Mar 18, 2010 at 11:01 AM, Lucas Nussbaum
<lucas(a)lucas-nussbaum.net> wrote:
> On 18/03/10 at 23:31 +0900, Austin Ziegler wrote:
>> On Thu, Mar 18, 2010 at 10:21 AM, Lucas Nussbaum
>> <lucas(a)lucas-nussbaum.net> wrote:
>> > OpenSSL doesn't have a lot of fans, because of its licence that prevents
>> > it from being linked to GPL software. Yes, it could be possible to ship
>> > openssl.so and readline.so in the same package, but then it would be
>> > harder to argue that Debian does enough to protect the linking of
>> > readline (GPLv2) with openssl. The situation would be much simpler if
>> > Ruby switched to GNU TLS, for example.
>>
>> Your first sentence is incorrect; OpenSSL is both better known and
>> more widely used in the real world than GNU TLS is likely to ever be.
>> GNU TLS is preferred by people who have subscribed to the GNU
>> philosophy, which doesn't include everyone in the Ruby world, and
>> those of us who prefer OpenSSL see GNU TLS as a zany outlier created
>> by people who have nothing better to do with their time than to worry
>> about the attribution clause (I believe that's the part that makes GNU
>> software incompatible with OpenSSL licensing, since GNU believes that
>> attribution isn't necessary).
>>
>> That said, if someone were to make an SSL/TLS layer for Ruby that
>> could reasonably replace the OpenSSL namespace and that both "require
>> 'openssl'" and "require 'gnutls'" would satisfy, then I think we'd see
>> traction. Since this is apparently a problem for people who prefer GNU
>> TLS, I suggest that it is in their interest to do so.
>
> Note that your lawyer might disagree with you, whether he is a GNU
> fanboy or not, because it is widely agreed that the OpenSSL license is
> incompatible with the GPL.
>
> I agree that this sucks, but hey, that's life.

I see it the other way around; because the GNU GPL does not permit
attribution requirements, it is the GNU GPL which is incompatible with
the (older) BSD-style license. I agree that it'd be nicer if OpenSSL
and SSLeay were under the 3-clause BSD, but I understand exactly why
they do it.

To me, the 4+-clause BSD is far more acceptable than any GNU GPL
license, even the GNU LGPL, even v2 (which I think is an infinitely
superior license to v3, but that's just my opinion).

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. That is the key point, but
the FSF has already pointed a way out of this: write to a common API
that can be used transparently and allow end users (who are not
subject to redistribution requirements in any case) to swap out their
preferred implementation.

This is exactly what the FSF says should be done to deal with their
(likely incorrect) understanding of shared object linking especially
with respect to libreadline.

Since Ruby programmers and the Ruby language have no problem as such
with OpenSSL, I would suggest that it is up to GNU TLS supporters to
write that transparent layer and convince Rubyists to use it. GNU TLS
has a fraction of the users over OpenSSL.

-austin
--
Austin Ziegler • halostatue(a)gmail.com • austin(a)halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

From: Aldric Giacomoni on
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.
Because Ruby is growing and moving quite fast at the moment. When it
slows down, there will be a major change in the general attitude of the
community regarding breaking code. Still, a young API can and most
likely should change. We all respect that - but now that's beside the
point.
>
> Most other communities solve that by having more stable APIs and making
> sure that their important software supports the latest API.
Again.. Growing community ;-)
>
> In Debian Squeeze (next Debian release), we ship (and support for
> several years) ruby 1.8 (likely 1.8.249+some backports) and ruby 1.9.1
> (maybe a prerelease of 1.9.2, but unlikely). It would be totally insane,
> to, additionally, try to support several versions of the same libraries.
> 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.

Sorry to be a pain for you maintainers. Switch to Gentoo ;-) It handles
all that very well, and has done a fantastic job of handling an overlay
tree for gems - you can essentially get the gems installed and supported
by your distribution. It is of course far from perfect, but they're
doing a fine job of it.
Then again, they have just recently started handling license acceptance
for things like Java, VMWare and such, so Debian is eons ahead of them
in that regard -- which is in fact at the core of our current debate.

>
>> >> Also: don't let the unfriendly tone one often encounters on the internet
>> >> get ya down. The medium itself seems to encourage that sort of thing...
>> >
>> > That's not a reason to consider it acceptable.
>>
>> True enough, OTOH, I've found it a lot easier to live on the
>> inter-tubes if I develop a thick skin, and give everyone the benefit
>> of the doubt that they are not actively trying to be uncivil, even if
>> they express themselves in what I might perceive to be an uncivil
>> fashion.
>
> It's really to give the benefit of the doubt about civility to several
> people on this list.

Normal person + Anonymity + Audience = Total fscktard. It's a
penny-arcade rule, and it's true. May as well be called "The Law of Gabe
& Tyco", or whatever their names are.
For whatever it's worth, Lucas, I have tremendous respect for the work
you do as a package maintainer. It's hard, time-consuming, sometimes
tedious, and sadly most of the time very thankless, as it is completely
behind the scenes.

Besides the issue of licensing mentioned above, the only other real
issue mentioned in this thread is "What will the users think?" or WWUT,
which can clearly be brought back to WWJDIHHAC (What would Jesus do if
he had a computer). JEG II made a change on Ruby's website to help
educating the users. Is it possible to add a message of some sort to the
pre-install apt-get warning when installing Ruby, to explain the
different Ruby packages?
I know it's not exactly Standard Operating Procedure for Debian, but
again, Ruby moves very fast, much faster than Debian does - which is not
a qualification, just a comparison.
--
Posted via http://www.ruby-forum.com/.

From: Austin Ziegler on
On Thu, Mar 18, 2010 at 11:02 AM, Lucas Nussbaum
<lucas(a)lucas-nussbaum.net> wrote:
> Apparently, the ruby core team is OK with the current situation, since
> apt-get install ruby1.9.1-full/ruby-full is advertised on
> http://www.ruby-lang.org/en/downloads/. You might want to educate your
> users to read the documentation.
>
> Also, I disagree that it's not our call to make. Most of the software
> shipped by Debian is split in seperate packages, and Ruby is the only
> case where I hear people complaining about such a minor issue.
>
> (Also note that the split predates me being involved in Ruby
> maintenance.)

Yes, it is. Let me be very clear in saying that the situation in the
last two years is, while far from ideal, significantly better than it
used to be. For that, let me say thank you. I disagree with you on a
number of things (including the fact that I think that Debian still
has a long way to go toward getting it right), but your maintenance is
appreciated and things are better than they used to be.

>> All of the standard libraries are meant to be
>> installed so you can count on having them.  By changing that decision,
>> Debian has made it so you can't count on having them and that changes
>> the rules of what you can do with Ruby.
> If, maybe, the Ruby community fixed the fact that it's illegal to load
> all of stdlib in the same process (because of OpenSSL vs GPL), we could
> consider including ssl and readline in the default lib pkg. However, I don't
> see how we will make Ruby depend on installing Tcl/Tk (because of the TK
> bindings), or Emacs (because of the ruby mode for emacs). Note that even
> ruby-full doesn't install the TK and elisp stuff.

Please don't repeat this, because as I pointed out on ruby-core, it's
not true. it's not illegal to load libreadline and openssl in the same
process; it's illegal to ship software that contains both. Neither the
OpenSSL license nor the GNU GPL address use or incidental in-memory
copies, only distribution.

-austin
--
Austin Ziegler • halostatue(a)gmail.com • austin(a)halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue