Feature #2982
closedRuby tries to link with both openssl and readline
Description
=begin
Hi,
Ruby currently tries to link with both OpenSSL (which is under the SSL license), and Readline (GPL).
This is not allowed. For more information, see for example http://people.gnome.org/~markmc/openssl-and-the-gpl.html and http://www.mail-archive.com/debian-legal@lists.debian.org/msg38757.html .
I have heard of a legal decision that makes this OK for scripting languages if the two libraries aren't loaded by default in the same address space.
A possible solution could be to port Ruby to use the GNU TLS library.
=end
Updated by matz (Yukihiro Matsumoto) almost 15 years ago
=begin
Hi,
In message "Re: [ruby-core:28735] [Bug #2982] Ruby tries to link with both openssl and readline"
on Thu, 18 Mar 2010 17:01:38 +0900, Lucas Nussbaum redmine@ruby-lang.org writes:
|Ruby currently tries to link with both OpenSSL (which is under the SSL license), and Readline (GPL).
No. The Ruby does not try to link with those libraries by default,
unless explicitly required by the user, so that it is a user's
responsibility to avoid loading those two in the same address space.
License sucks.
matz.
=end
Updated by lucas (Lucas Nussbaum) almost 15 years ago
=begin
On 18/03/10 at 18:23 +0900, Yukihiro Matsumoto wrote:
Hi,
In message "Re: [ruby-core:28735] [Bug #2982] Ruby tries to link with both openssl and readline"
on Thu, 18 Mar 2010 17:01:38 +0900, Lucas Nussbaum redmine@ruby-lang.org writes:|Ruby currently tries to link with both OpenSSL (which is under the SSL license), and Readline (GPL).
No. The Ruby does not try to link with those libraries by default,
unless explicitly required by the user, so that it is a user's
responsibility to avoid loading those two in the same address space.
Users, and developers of third-party libraries and application. Note
that it is de-facto illegal to use openssl with GPL libraries/gems (and
there are quite a lot of GPL-only libraries/gems).
License sucks.
Agreed ;)¶
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
=end
Updated by austin (Austin Ziegler) almost 15 years ago
=begin
On Thu, Mar 18, 2010 at 5:37 AM, Lucas Nussbaum
lucas@lucas-nussbaum.net wrote:
On 18/03/10 at 18:23 +0900, Yukihiro Matsumoto wrote:
In message "Re: [ruby-core:28735] [Bug #2982] Ruby tries to link with both openssl and readline"
on Thu, 18 Mar 2010 17:01:38 +0900, Lucas Nussbaum redmine@ruby-lang.org writes:
|Ruby currently tries to link with both OpenSSL (which is under the SSL license), and Readline (GPL).No. The Ruby does not try to link with those libraries by default,
unless explicitly required by the user, so that it is a user's
responsibility to avoid loading those two in the same address space.Users, and developers of third-party libraries and application. Note
that it is de-facto illegal to use openssl with GPL libraries/gems (and
there are quite a lot of GPL-only libraries/gems).
This is completely incorrect and FUD. It is against the license to
distribute GNU GPL libraries/gems with OpenSSL. There is nothing
against the license for use. The GNU GPL is a distribution license,
not a EULA. If end users do something but do not distribute that
something, it's not illegal.
The FSF also takes a maximal view on shared libraries that is not so
far supported by any court case or common sense. It is perfectly legal
to ship a GNU GPLed Photoshop plug-in, and it is perfectly legal for a
user to use such. RMS and the FSF do not believe so, but the only
court cases that talk about in-memory copies indicate that they are a
necessary by-product of running the program, and as such it's not a
problem.
Please stop the GPL zealot's FUD.
-austin¶
Austin Ziegler • halostatue@gmail.com • austin@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue
=end
Updated by lucas (Lucas Nussbaum) almost 15 years ago
=begin
Right, sorry. What I meant is that third-party developers might need to worry if they distribute libraries/gems linked with OpenSSL. Now, of course, it depends on your definition of linking.
Now, IANAL, and neither are you AFAIK, so maybe it would be better to stop calling people zealots and ask someone with a real legal expertise.
=end
Updated by nobu (Nobuyoshi Nakada) almost 15 years ago
- Status changed from Open to Closed
=begin
=end
Updated by lucas (Lucas Nussbaum) almost 15 years ago
=begin
Why was this bug marked as closed?
Anyway. I asked the Debian people responsible for reviewing packages before their acceptance in the Debian archive. See http://lists.debian.org/debian-legal/2010/03/msg00037.html for the reply of one of them.
So, we would need a link exception, similar to the one in wget or freeradius, to confirm that it is allowed to link ruby's GPL code to openssl.
wget's exception is:
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.
Freeradius exception is:
This LICENSE file is a modification to the main LICENSE file, which is
GPLv2. It applies only to the files in the "src" directory.
In addition, as a special exception, the copyright holders give
permission to link the code of this program with the OpenSSL library,
and distribute linked combinations including the two.
You must obey the GNU General Public License in all respects
for all of the code used other than OpenSSL. If you modify
file(s) with this exception, you may extend this exception to your
version of the file(s), but you are not obligated to do so. If you
do not wish to do so, delete this exception statement from your
version. If you delete this exception statement from all source
files in the program, then also delete it here.
=end
Updated by naruse (Yui NARUSE) almost 15 years ago
=begin
You can link openssl and Ruby's Licensed Ruby.
=end
Updated by lucas (Lucas Nussbaum) almost 15 years ago
=begin
But if we ship ruby under the terms of the ruby license, we are no longer allowed to link it to readline.
=end
Updated by naruse (Yui NARUSE) almost 15 years ago
=begin
When you want to link openssl, you use Ruby's.
When you want to link readline, you use GPL.
=end
Updated by lucas (Lucas Nussbaum) almost 15 years ago
=begin
I will see if that point of view works for the archive maintainers...
=end
Updated by naruse (Yui NARUSE) almost 15 years ago
=begin
Linked exeption is useless because:
- for openssl you can use Ruby's
- for both openssl and readline, readline's GPL2 infect Ruby
=end
Updated by coatl (caleb clausen) almost 15 years ago
=begin
Unfortunately, I have no good suggestion as to how to get out of this mess. However, I want to make everyone aware that the problem is broader than is generally known. In addition to the readline extension, ruby ships with a gdbm extension. Gdbm is GPL (not LGPL) licensed, and so it presents exactly the same problem as readline. For all I know, there could be other licensing dragons lurking in ext/, but that was the only other one I could find when I went looking.
I agree with Yui that no change made to the license of ruby can make it more compatible than it is now. The most reasonable way out would be for the fsf to change readline and gdbm from GPL to LGPL licensing. I understand that's due to happen sometime after hell freezes over. The next best option seems to be for ruby to discontinue use of readline and gdbm.
How much effort would be needed to internationalize libedit?
=end
Updated by zenspider (Ryan Davis) almost 15 years ago
=begin
On Mar 19, 2010, at 15:42 , caleb clausen wrote:
How much effort would be needed to internationalize libedit?
Apparently this has already been done, but not released yet. Aaron found recent commits in their repo that look like they'll save us from this BS.
=end
Updated by hramrach (Michal Suchanek) almost 15 years ago
=begin
On 20 March 2010 20:50, Ryan Davis ryand-ruby@zenspider.com wrote:
On Mar 19, 2010, at 15:42 , caleb clausen wrote:
How much effort would be needed to internationalize libedit?
Apparently this has already been done, but not released yet. Aaron found recent commits in their repo that look like they'll save us from this BS.
Changing to libedit makes this part of Ruby more usable I guess.
However, removing OpenSSL is really the way to go since there are
multiple GPL extensions in Ruby and probably quite a few in gems as
well. I am not sure why OpenSSL is incompatible with GPL but since
FSF/Debian determined it is and they are really the ones behind GPL I
guess it's better to avoid the combination.
Thanks
Michal
=end
Updated by darix (Marcus Rückert) almost 15 years ago
=begin
On 2010-03-21 05:25:01 +0900, Michal Suchanek wrote:
On 20 March 2010 20:50, Ryan Davis ryand-ruby@zenspider.com wrote:
On Mar 19, 2010, at 15:42 , caleb clausen wrote:
How much effort would be needed to internationalize libedit?
Apparently this has already been done, but not released yet. Aaron found recent commits in their repo that look like they'll save us from this BS.
Changing to libedit makes this part of Ruby more usable I guess.
However, removing OpenSSL is really the way to go since there are
multiple GPL extensions in Ruby and probably quite a few in gems as
well. I am not sure why OpenSSL is incompatible with GPL but since
FSF/Debian determined it is and they are really the ones behind GPL I
guess it's better to avoid the combination.
well if gnutls would be ready to replace it ....
GPL in general is problematic aswell, especially v3.
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
=end
Updated by nobu (Nobuyoshi Nakada) almost 15 years ago
- Status changed from Closed to Open
- ruby -v changed from 1.8 to *
=begin
=end
Updated by nobu (Nobuyoshi Nakada) almost 15 years ago
- Status changed from Open to Third Party's Issue
=begin
=end