On Sun, 15 May 2011 11:32:57 +0200 Lucas Nussbaum wrote: > (Please keep debian-ruby@ Cced) Done. > > Hi, Hi Lucas! I am glad to see you haven't completely given up working on Ruby in Debian! > > 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 http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL 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. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Attachment:
pgp99If28A5sk.pgp
Description: PGP signature