[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: license check: ruby 1.9.3

On Sun, 15 May 2011 11:32:57 +0200 Lucas Nussbaum wrote:

> (Please keep debian-ruby@ Cced)


> Hi,

Hi Lucas!
I am glad to see you haven't completely given up working on Ruby in

> In the upcoming Ruby release, there will be a license change from
> GPLv2||Ruby to BSD||Ruby.

Which is basically equivalent to say that Ruby is switching to the
(2-clause) BSD license: Ruby upstream could very well drop the Ruby
license entirely, since the (2-clause) BSD license is so permissive
that I cannot see any reason (as a recipient) to choose to comply with
the Ruby license, instead of with the BSD license...

In other words, it seems to me that the (2-clause) BSD license gives
the recipient all the permissions given by the Ruby license, and some
more, with less restrictions.
This means that  BSD||Ruby == BSD

Hence, from here after, I think we can discuss *as if* Ruby version
1.9.3 were released under the terms of the (2-clause) BSD license.

> Since the situation is rather complex, and
> involves linking with both readline and openssl, I'd like to check that
> our interpretation is correct.

This is tricky, since, as it well known, the OpenSSL license is
GPL-incompatible, and GNU Readline is a GPL-licensed library.

> 1. Relevant copyright and licensing information
> ===============================================
> In short, Ruby is dual-licensed under the Ruby license (which is probably free)
> and a 2-clause BSD license.

I am not too sure that the Ruby license really meets the DFSG (section
2. smells like too restrictive, from my point of view), but, as I said,
this should not be an issue, since the other possible license choice
(2-clause BSD license) is perfectly fine, from a DFSG point of view.

> 2. Ruby build process and generated files / packages
> ====================================================
> The ruby build process generates several shared libraries.
> All files are currently shipped in the same binary package.
> Questions
> =========
> 1. Are we really allowed to ship all those files in the same binary package?

I personally think that this should not be an issue, as long as the
various differently (and incompatibly) licensed libraries are separate
libraries, not linked (directly or indirectly) together.

I mean, taking for instance GNU Readline and OpenSSL: as long
as /usr/lib/ruby/1.9.1/x86_64-linux/readline.so
and /usr/lib/ruby/1.9.1/x86_64-linux/openssl.so are separate libraries,
not linked with each other, and as long as you do not ship a third work
that links (directly or indirectly) with both readline.so and
openssl.so, there should be no problem in shipping the two libraries in
the same package.

At least, this is how I think it works.
Anyone who knows better is encouraged to correct me.

Obviously, it would be easier and more understandable, from a user's
point of view, if the incompatibly licensed Ruby extensions were
shipped in different binary packages: it would be easier to spot
possible license incompatibilities in third packages (for instance in
packages shipping Ruby applications), by just looking at dependencies...

> 2. Can a non-GPL Ruby application load one of the Ruby extensions linked with a
> GPL libraries? (I'm not sure if there's jurisprudence on this from other
> scripting languages)

I think you mean "Can a GPL-incompatible Ruby application [...] ?"
If this is the case, it seems that the FSF's interpretation is that a
GPL-incompatible Ruby application cannot load a Ruby extension that
binds the application with a GPL-licensed library.
See the answer to
especially the second, third, and fourth paragraph:

| However, when the interpreter is extended to provide “bindings” to
| other facilities (often, but not necessarily, libraries), the
| interpreted program is effectively linked to the facilities it uses
| through these bindings. So if these facilities are released under the
| GPL, the interpreted program that uses them must be released in a
| GPL-compatible way. The JNI or Java Native Interface is an example of
| such a binding mechanism; libraries that are accessed in this way are
| linked dynamically with the Java programs that call them. These
| libraries are also linked with the interpreter. If the interpreter is
| linked statically with these libraries, or if it is designed to link
| dynamically with these specific libraries, then it too needs to be
| released in a GPL-compatible way.
| Another similar and very common case is to provide libraries with the
| interpreter which are themselves interpreted. For instance, Perl comes
| with many Perl modules, and a Java implementation comes with many Java
| classes. These libraries and the programs that call them are always
| dynamically linked together.
| A consequence is that if you choose to use GPL'd Perl modules or Java
| classes in your program, you must release the program in a
| GPL-compatible way, regardless of the license used in the Perl or Java
| interpreter that the combined Perl or Java program will run on. 

However, I am not aware of any case where this FSF legal theory has
been tested in court.

> 3. Can a Ruby application load both the openssl extension, and one of the GPL
> extensions (e.g readline)?

If I understand correctly, the FSF claims that this cannot be done.
This is again covered by the above-quoted answer, as an extension of
the reasoning.

Again, there seems to have been no case yet where this FSF legal theory
has been tested in court.

> Thanks

You're welcome.

 New GnuPG key, see the transition document!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

Attachment: pgpVYoO96asQ4.pgp
Description: PGP signature

Reply to: