Recommended way to install Rubygems

[Leslie Viljoen]

[Note: parts of this message were removed to make it a legal post.]

On 19/03/10 at 02:49 +0900, Aldric Giacomoni wrote:I think that rubygems
and emerge and actually quite similar, which
probably explains why they work together well. Rubygems is a great tool
for developers who want to get the latest cutting edge software.
However, at some point, applications are transferred from developers to
sysadmins, and "cutting edge" isn't really a good selling point.
Internally (in an organization) it's fine, because you can just
vendorize all the gems you use. But if you want to distribute your
application to the outside world, it's difficult to explain that the
user needs to use rubygems to install that application because it's
written in ruby, while the ruby is just interested in the functionality
provided by the application, and doesn't care whether it's perl or ruby.

Can I ask: how do Perl and Python deal with this? CPAN is included in the
base Perl install - how does Perl deal
with the fact that CPAN then installs its own stuff?
Is it safe to install RubyGems via apt-get now? I have seen warnings but I
don't know the actual reason behind them.

 

[Aldric Giacomoni]

I think that rubygems and emerge and actually quite similar, which
probably explains why they work together well. Rubygems is a great tool
for developers who want to get the latest cutting edge software.
However, at some point, applications are transferred from developers to
sysadmins, and "cutting edge" isn't really a good selling point.


I think that approaches that aim at getting rubygems and apt-get to
cooperate are just wrong. Both rubygems and apt-get have good reasons to
exist, but they don't solve the same problem. Instead, we should try to
develop a set of good practices that make it easier to convert a ruby
library into a "normal" Deb or RPM package. Much progress has already
been done lately, and the last libraries I've packaged didn't use
"require 'rubygems'" except in the test suite, so they did not require
any patching.

Apt-get does not really handle slotting in the way portage does, and I
think that's what you are thinking about when you say that rubygems and
portage work the same way.
Rubygems isn't meant for what you describe, but I agree that it helps
that behavior. Its purpose is to manage different versions of gems
because it understands that purposes and APIs can change.
Did we mention that gems can be released under whatever license the
owner wants? What a nightmare for Debian's apt-get system...
I'm glad to hear that it's becoming easier to integrate libs into
apt-get.

Someone suggested, earlier, that we add ruby to a different branch of
the debian sources. How about creating a separate tree for the gems,
where the updating can be done more quickly than on the regular tree? Is
that idea a no-go because of Debian policies (of which I am blissfully
ignorance) ?

I have kind-of done that a few hours ago.

Now:
# apt-get install ruby
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libruby1.8 ruby1.8
Suggested packages:
irb rdoc ri libopenssl-ruby ruby-dev ruby1.8-examples rdoc1.8 ri1.8
The following NEW packages will be installed:
libruby1.8 ruby ruby1.8
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 2060kB/2082kB of archives.
After this operation, 6980kB of additional disk space will be used.

(See the list of Suggested packages)

It's not much, but still a slight improvement, which should probably
have been done before.

That's great - I think it's probably the best way to start. The rest
will come down to meetings and long discussions about policies..
Now if only users would _read_ !

-- Aldric Giacomoni
What is the source of conflict?

 

[Lucas Nussbaum]

Someone suggested, earlier, that we add ruby to a different branch of
the debian sources. How about creating a separate tree for the gems,
where the updating can be done more quickly than on the regular tree? Is
that idea a no-go because of Debian policies (of which I am blissfully
ignorance) ?

You could create an external repository with unofficial (as in: not in
Debian) packages that are built automatically from gems. I think that
this was actually already done (see http://www.debgem.com/), but I'm not
sure of the status of this project. There's nothing blocking anybody
from doing that.

However, those debs are likely not suitable to be directly integrated in
Debian. In Debian, we install Ruby libraries under /usr/lib/ruby/1.8
(with a migration to /usr/lib/ruby/vendor_ruby/1.8 planned, but not done
yet, to avoid mixing the stdlib with third-party libs). Also, we make
sure that each package works, so an automated process is not going to
help us

 

[Lucas Nussbaum]

Can I ask: how do Perl and Python deal with this? CPAN is included in the
base Perl install - how does Perl deal
with the fact that CPAN then installs its own stuff?

CPAN only installs its own stuff when the user requests it. However,
most of the useful CPAN is packaged in Debian. Packaging perl modules is
very easy, because:
- they are provided as .tgz
- they all share exactly the same interface for compilation and testing
- that interface doesn't require any external dependencies
(I'm not very familiar with python packaging, but I think that it is
similar)

As a result, Debian currently contains more than 2000 perl libraries,
about 1400 python libraries, and only ~300 ruby libraries.

With ruby libraries:
- it is usually difficult to find a usable source. Sometimes we have to
extract the gem and convert it to a tgz. We also have a service
(githubredir.debian.net) that allows us to fetch a specific tag on
github as a .tgz.
- then we often have to modify the source, to remove the calls to
"require 'rubygems'"
- then we have to find a way to install the files. If the directory
structure uses the setup.rb standard (bin/, lib/, etc...), then it's
easy, and we use our own copy of setup.rb to install everything.
But some libraries don't ship the files in a very organized way.
- Then we have to find a way to run the test suite during the build.
Since all packages in Debian are frequently rebuilt for QA purposes,
it is a good way to detect regressions. Unfortunately, using "rake
test" is usually not an option, because of the way the Rakefile is
written (dependencies on other stuff including rubygems, etc). So, in
most cases, we just run the test manually (cd test ; ./ts_*.rb) or
give up and do not run the test suite automatically during the build.

Also, we would like to support two ruby versions (1.8 and 1.9.X),
which is often difficult because 1.9.X compatibility is rarely
mentioned in the library documentation.

Is it safe to install RubyGems via apt-get now? I have seen warnings but I
don't know the actual reason behind them.

Even if I said "yes", I'm probably not the one to trust on that

 

[Leslie Viljoen]

[Note: parts of this message were removed to make it a legal post.]

CPAN only installs its own stuff when the user requests it. However,
most of the useful CPAN is packaged in Debian. Packaging perl modules is
very easy, because:
- they are provided as .tgz
- they all share exactly the same interface for compilation and testing
- that interface doesn't require any external dependencies
(I'm not very familiar with python packaging, but I think that it is
similar)

As a result, Debian currently contains more than 2000 perl libraries,
about 1400 python libraries, and only ~300 ruby libraries.

With ruby libraries:
- it is usually difficult to find a usable source. Sometimes we have to
extract the gem and convert it to a tgz. We also have a service
(githubredir.debian.net) that allows us to fetch a specific tag on
github as a .tgz.
- then we often have to modify the source, to remove the calls to
"require 'rubygems'"
- then we have to find a way to install the files. If the directory
structure uses the setup.rb standard (bin/, lib/, etc...), then it's
easy, and we use our own copy of setup.rb to install everything.
But some libraries don't ship the files in a very organized way.
- Then we have to find a way to run the test suite during the build.
Since all packages in Debian are frequently rebuilt for QA purposes,
it is a good way to detect regressions. Unfortunately, using "rake
test" is usually not an option, because of the way the Rakefile is
written (dependencies on other stuff including rubygems, etc). So, in
most cases, we just run the test manually (cd test ; ./ts_*.rb) or
give up and do not run the test suite automatically during the build.

Also, we would like to support two ruby versions (1.8 and 1.9.X),
which is often difficult because 1.9.X compatibility is rarely
mentioned in the library documentation.

Ok, I have created a few gems and I wouldn't mind trying to make my gems
more
Debian friendly. Perhaps these guidelines could be put on a wiki, or
something
like Hoe could check for and warn about some of them.

To make a gem, I usually read these:
http://docs.rubygems.org/read/chapter/5
http://nubyonrails.com/articles/tutorial-publishing-rubygems-with-hoe

 

[Eric Hodel]

=20
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.

Maybe Debian should switch to a non-GPL readline implementation for ruby =
as it's not illegal on OS X:

$ otool -L `gem which readline`
=
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/un=
iversal-darwin10.0/readline.bundle:
=
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby.1.d=
ylib (compatibility version 1.8.0, current version 1.8.7)
/usr/lib/libedit.2.dylib (compatibility version 2.0.0, current =
version 2.11.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, =
current version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current =
version 123.0.0)

(Ignoring compatibility problems between readline and editline, of =
course)=

 

[gf]

[...]
Instead, we should try to
develop a set of good practices that make it easier to convert a ruby
library into a "normal" Deb or RPM package. Much progress has already
been done lately, and the last libraries I've packaged didn't use
"require 'rubygems'" except in the test suite, so they did not require
any patching.

[...]

Perhaps talking to the gemcutter people (http://rubygems.org/) to
bottleneck the Deb/RPM packaging needs would be productive? That's
supposed to be the source for gems now, so building in a hook that
does all the necessary tweaks for *nix packaging would tie Windows,
Mac OS, gems and Deb/RPM together at the source. Just a thought from
my tired ol' mind.

http://www.rubyinside.com/gemcutter-a-fast-and-easy-approach-to-ruby-gem-ho=
sting-2281.html
http://www.rubyinside.com/gemcutter-is-the-new-official-default-rubygem-hos=
t-2659.html

 

[Lucas Nussbaum]

Maybe Debian should switch to a non-GPL readline implementation for ruby as it's not illegal on OS X:

$ otool -L `gem which readline`
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0/readline.bundle:
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby.1.dylib (compatibility version 1.8.0, current version 1.8.7)
/usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.11.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)

(Ignoring compatibility problems between readline and editline, of course)

It was pointed out that libedit doesn't support multibyte encodings yet,
unfortunately. But yes, it is a solution.

 

[Lucas Nussbaum]

[...]
Instead, we should try to
develop a set of good practices that make it easier to convert a ruby
library into a "normal" Deb or RPM package. Much progress has already
been done lately, and the last libraries I've packaged didn't use
"require 'rubygems'" except in the test suite, so they did not require
any patching.

[...]

Perhaps talking to the gemcutter people (http://rubygems.org/) to
bottleneck the Deb/RPM packaging needs would be productive? That's
supposed to be the source for gems now, so building in a hook that
does all the necessary tweaks for *nix packaging would tie Windows,
Mac OS, gems and Deb/RPM together at the source. Just a thought from
my tired ol' mind.

Yes. I will do that when we have a discussion about that on the Debian
side again (now is not a good time, we are trying to get a release out).

 

[John W Higgins]

[Note: parts of this message were removed to make it a legal post.]

Good Afternoon,

With ruby libraries:
- it is usually difficult to find a usable source. Sometimes we have to
extract the gem and convert it to a tgz. We also have a service
(githubredir.debian.net) that allows us to fetch a specific tag on
github as a .tgz.

I'm rather confused by this - a gem file (at least as far as I can find)
contains two files data.tar.gz and metadata.tar.gz within the tar.gz shell
of the .gem file - what exactly is the issue with that layout? Is there
something specific that this doesn't provide you that is of great
importance?

- then we often have to modify the source, to remove the calls to
"require 'rubygems'"

I'm pretty sure that's a one liner for 99.9% of cases and I really don't
think is necessary - you really should look at how Gentoo installs gems
because we get the benefit of both "manually" installing a package as well
as full integration within RubyGems (for example gem list --local shows all
gems installed via portage and well as gem install). If there is no ebuild
file we can infact turn to emerge-gem to take a gem file and create an
ebuild (including full dependency checks from the gem itself). Does it work
every single time - nope - but it seems like a huge improvement over what is
going on with Debian at the moment.

- then we have to find a way to install the files. If the directory
structure uses the setup.rb standard (bin/, lib/, etc...), then it's
easy, and we use our own copy of setup.rb to install everything.
But some libraries don't ship the files in a very organized way.

Again, you keep seeming to want to continue to take shot after shot at
developers when clearly it's an issue with the ability of Debian to have any
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.

John

 

[Rick DeNatale]

I think that rubygems and emerge and actually quite similar, which
probably explains why they work together well. Rubygems is a great tool
for developers who want to get the latest cutting edge software.
However, at some point, applications are transferred from developers to
sysadmins, and "cutting edge" isn't really a good selling point.
Internally (in an organization) it's fine, because you can just
vendorize all the gems you use. But if you want to distribute your
application to the outside world, it's difficult to explain that the
user needs to use rubygems to install that application because it's
written in ruby, while the ruby is just interested in the functionality
provided by the application, and doesn't care whether it's perl or ruby.

I assume you mean that "the user doesn't care whether it's perl or ruby."

Actually control, or lack of control over configuration management
cuts both ways.

I the case of OO base framework code, you can't safely change versions
of the framework and the application based on the framework. Back in
the late 80s early 90s, everyone got excited over the early
application frameworks like MacApp and NextStep, and all of the guys
developing operating systems got the idea of building operating
systems with frameworks as the API. This just doesn't work. I know,
I was there.

http://talklikeaduck.denhaven2.com/2007/06/15/a-meeting-with-gill-bates

And for those who might be slow, I just switched the first letters in
Gill Bates first and last names. <G>

MacApp, NextStep, and Rails work only when the application can freeze
to a particular version of the framework, moving between versions of
the framework inevitably involves some rewrite of the application.

This is why it's very wise to freeze gems in a Rails application. And
when this is done, by the way, you don't need gems to install the app,
you typically deploy it via checking it out from a source code
repository, and the gems are put in the right place within THAT
APPLICATIONS file hierarchy.

I know folks who've been bitten when they haven't vendored gems and
deployed to a hosting provider, who took it upon themselves to upgrade
the SYSTEM without knowing about the need for independent
configuration management for the customer's application(s).

And other users got bitten when their hosting provider (or they
themselves) upgraded the Ruby 1.8 package and got Ruby 1.8.6 changed
out to 1.8.7 before their code, or rails or ... was compatible with
1.8.7.

Now I know that 1.8.7 maybe shouldn't have made some of the changes it
did, and I argued against this at the time, but it's not a question of
who is to blame, it's a question of recognizing that seeing
configuration management as solely the concern of system
administrators is problematical at best.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Rick DeNatale]

Good Afternoon,



I'm rather confused by this - a gem file (at least as far as I can find)
contains two files data.tar.gz and metadata.tar.gz within the tar.gz shel= l
of the .gem file - what exactly is the issue with that layout? Is there
something specific that this doesn't provide you that is of great
importance?



I'm pretty sure that's a one liner for 99.9% of cases and I really don't
think is necessary - you really should look at how Gentoo installs gems
because we get the benefit of both "manually" installing a package as wel= l
as full integration within RubyGems (for example gem list --local shows a= ll
gems installed via portage and well as gem install). If there is no ebuil= d
file we can infact turn to emerge-gem to take a gem file and create an
ebuild (including full dependency checks from the gem itself). Does it wo= rk
every single time - nope - but it seems like a huge improvement over what= is
going on with Debian at the moment.



Again, you keep seeming to want to continue to take shot after shot at
developers when clearly it's an issue with the ability of Debian to have = any
flexibility - again looking at Gentoo it somehow, in a very much automate= d
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 packa= ges
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 t= o
be an idiot or anything - it really seems like Gentoo has solved the issu= es
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.

Putting my self in Lucas' shoes, I have to say that such advice seems
like telling a Christian that he should accept Mohammed, or an Arab or
Buddhist that If they just accept Jesus as their savior everything
will be all right.

Me, I'm for freedom of religion, as long as I'm free to practice as I wish.

<duck>What have I opened myself up for</duck>

Seriously though. Each distro has it's own philosophy and goals.
Debian tries to balance stability with keeping up with the latest
trends. It appeals to people who like such stability. At times
though this has caused problems, the loooong interlude between Woody
and Sarge caused a lot of folks to champ at the bit for new stuff.
That's one of the reasons Ubuntu got popular, it introduced timeboxed
releases so that one could be assured that one would be getting a
'stable' refresh every 6 months or so, and not have to dip into the
testing or horror of horrors 'sid' version. Canonical was more
aggressive in pulling stuff from the testing branch, reworking it and
contributing it back.

Personally, I use Ubuntu for my linux boxes, but I still use Ruby and
rubygems from source.

Lucas' dilemma is that he is trying to deal with a rapidly moving body
of software in Ruby and particularly ruby gems, in the context of the
conservative debian philosophy.

I don't envy him.

--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Lucas Nussbaum]

I assume you mean that "the user doesn't care whether it's perl or ruby."

Yes. I clearly sent too many mails on this list today, but people keep
replying to me with interesting comments!!

Actually control, or lack of control over configuration management
cuts both ways.

I the case of OO base framework code, you can't safely change versions
of the framework and the application based on the framework. Back in
the late 80s early 90s, everyone got excited over the early
application frameworks like MacApp and NextStep, and all of the guys
developing operating systems got the idea of building operating
systems with frameworks as the API. This just doesn't work. I know,
I was there.

http://talklikeaduck.denhaven2.com/2007/06/15/a-meeting-with-gill-bates

And for those who might be slow, I just switched the first letters in
Gill Bates first and last names. <G>

MacApp, NextStep, and Rails work only when the application can freeze
to a particular version of the framework, moving between versions of
the framework inevitably involves some rewrite of the application.

This is why it's very wise to freeze gems in a Rails application. And
when this is done, by the way, you don't need gems to install the app,
you typically deploy it via checking it out from a source code
repository, and the gems are put in the right place within THAT
APPLICATIONS file hierarchy.

I know folks who've been bitten when they haven't vendored gems and
deployed to a hosting provider, who took it upon themselves to upgrade
the SYSTEM without knowing about the need for independent
configuration management for the customer's application(s).

And other users got bitten when their hosting provider (or they
themselves) upgraded the Ruby 1.8 package and got Ruby 1.8.6 changed
out to 1.8.7 before their code, or rails or ... was compatible with
1.8.7.

Now I know that 1.8.7 maybe shouldn't have made some of the changes it
did, and I argued against this at the time, but it's not a question of
who is to blame, it's a question of recognizing that seeing
configuration management as solely the concern of system
administrators is problematical at best.

Thanks for the very interesting link.

I understand why it is necessary to freeze the rails version for an
application, and why such framework are a different problem.

However, that's only a small part of the issue: most gems that are
typically vendored are only used through a relatively simple API, and
there's no real reason to vendor and freeze those. And the core+stdlib
don't really have valid reasons for significantly breaking the API,
especially between versions of Ruby 1.8.7.X.

Of course, that requires efforts. But the consequence of not doing that
work is that people tend to stay with ancient versions of the
interpreter, do not consider it interesting to try newer versions, and
we end up with Ruby 1.9: first snapshot package uploaded to Debian 5
years ago, and still not widely used by the Ruby community because the
cost of migration is too high.

 

[Lucas Nussbaum]

Good Afternoon,



I'm rather confused by this - a gem file (at least as far as I can find)
contains two files data.tar.gz and metadata.tar.gz within the tar.gz shell
of the .gem file - what exactly is the issue with that layout? Is there
something specific that this doesn't provide you that is of great
importance?

It's just extra work. Also, if I remember correctly, the dates in the
data.tar.gz file are incorrect because of a missing feature in the
pure-ruby tar implementation in rubygems.

I'm pretty sure that's a one liner for 99.9% of cases and I really don't
think is necessary - you really should look at how Gentoo installs gems
because we get the benefit of both "manually" installing a package as well
as full integration within RubyGems (for example gem list --local shows all
gems installed via portage and well as gem install). If there is no ebuild
file we can infact turn to emerge-gem to take a gem file and create an
ebuild (including full dependency checks from the gem itself). Does it work
every single time - nope - but it seems like a huge improvement over what is
going on with Debian at the moment.


Again, you keep seeming to want to continue to take shot after shot at
developers when clearly it's an issue with the ability of Debian to have any
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.

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.

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?

 

[Dido Sevilla]

T24gVGh1LCBNYXIgMTgsIDIwMTAgYXQgMTE6MDIgUE0sIEx1Y2FzIE51c3NiYXVtCjxsdWNhc0Bs
dWNhcy1udXNzYmF1bS5uZXQ+IHdyb3RlOgo+IElmLCBtYXliZSwgdGhlIFJ1YnkgY29tbXVuaXR5
IGZpeGVkIHRoZSBmYWN0IHRoYXQgaXQncyBpbGxlZ2FsIHRvIGxvYWQKPiBhbGwgb2Ygc3RkbGli
IGluIHRoZSBzYW1lIHByb2Nlc3MgKGJlY2F1c2Ugb2YgT3BlblNTTCB2cyBHUEwpCgpodHRwOi8v
d3d3Lm9wZW5zc2wub3JnL3N1cHBvcnQvZmFxLmh0bWwjTEVHQUwyCgoiT24gbWFueSBzeXN0ZW1z
IGluY2x1ZGluZyB0aGUgbWFqb3IgTGludXggYW5kIEJTRCBkaXN0cmlidXRpb25zLCB5ZXMKKHRo
ZSBHUEwgZG9lcyBub3QgcGxhY2UgcmVzdHJpY3Rpb25zIG9uIHVzaW5nIGxpYnJhcmllcyB0aGF0
IGFyZSBwYXJ0Cm9mIHRoZSBub3JtYWwgb3BlcmF0aW5nIHN5c3RlbSBkaXN0cmlidXRpb24pLiAi
CgotLSAK5pmu6YCa44GY44KD44Gq44GE44Gu44GM5b2T54S244Gq44KJ562U44GI44KL56eB44Gv
5L2V44GM44Gn44GN44KL77yfCuaZrumAmuOBp+OCguaZrumAmuOBmOOCg+OBquOBj+OBpuaEn+OB
mOOCi+OBvuOBvuaEn+OBmOOCi+OBk+OBqOOBoOOBkeOCkuOBmeOCi+OCiO+8gQpodHRwOi8vc3Rv
cm13eXJtLmJsb2dzcG90LmNvbQo=

 

[Lucas Nussbaum]

http://www.openssl.org/support/faq.html#LEGAL2

"On many systems including the major Linux and BSD distributions, yes
(the GPL does not place restrictions on using libraries that are part
of the normal operating system distribution). "

Full quote:

"On other systems, the situation is less clear. Some GPL software
copyright holders claim that you infringe on their rights if you use
OpenSSL with their software on operating systems that don't normally
include OpenSSL.

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." If you are
using GPL software developed by others, you may want to ask the
copyright holder for permission to use their software with OpenSSL."


Note that the FSF and Debian think that this is a problem.

I'm not sure how the Ruby copyright is managed. If it is possible to
change the license, I would suggest adding a GPL exemption clause (like
wget did, for example), which would clarify the situation.

From wget's README file:

Additional permission under GNU GPL version 3 section 7

If you modify this program, or any covered work, by linking or
combining it with the OpenSSL project's OpenSSL library (or a
modified version of that library), containing parts covered by the
terms of the OpenSSL or SSLeay licenses, the Free Software Foundation
grants you additional permission to convey the resulting work.
Corresponding Source for a non-source form of such a combination
shall include the source code for the parts of OpenSSL used as well
as that of the covered work.

 

[Brian Candler]

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?

(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.

'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?

(2) The Ruby/FreeRADIUS/etc people?

Their code explicitly does things like #include <openssl.h>. It is quite
obviously intended to be used and linked with OpenSSL.

They might be worried if someone tried to redistribute Ruby+OpenSSL
under a single combined licence which was more restrictive than the GPL.
But Debian isn't doing that; they aggregate a whole load of software,
each distributed under its own licence. Is there an all-encompassing
"Debian Licence"? I didn't think so, and I wouldn't use Debian/Ubuntu if
I discovered there were.

 

[Lucas Nussbaum]

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?

(1) The OpenSSL copyright holders?
[..]

(2) The Ruby/FreeRADIUS/etc people?

[..]

You shouldn't assume that because someone is very friendly now, it will
always be the case. There has been several occurrences of people or
groups changing their mind, because, for a example, a company was bought
by another one with a less friendly position.

Note that Freeradius has a exception for OpenSSL in src/LICENSE.openssl.
Ruby doesn't AFAICS.

They might be worried if someone tried to redistribute Ruby+OpenSSL
under a single combined licence which was more restrictive than the GPL.
But Debian isn't doing that; they aggregate a whole load of software,
each distributed under its own licence. Is there an all-encompassing
"Debian Licence"? I didn't think so, and I wouldn't use Debian/Ubuntu if
I discovered there were.

There isn't.

 

[Brian Candler]

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?

 

[Austin Ziegler]

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.
--=20
Austin Ziegler =95 (e-mail address removed) =95 (e-mail address removed)
http://www.halostatue.ca/ =95 http://twitter.com/halostatue