My brief and torrid affair with Ruby

ruby-talk
1

Hi List:

I’ve been a lurker here for about two weeks. In that time, I’ve been
installing Ruby on a number of machines (Mac, Linux, Windows) and
generally having a grand time exploring Ruby and telling anyone who
will sit still for 3 seconds what a great language it is.

Since there’s been a recent thread on how to make Ruby more popular,
I thought I’d mention why Ruby’s popularity came to a screeching halt
this evening. In one word: “Licenses.”

Coming from a background of using Perl and some Python, I’ve become
quite casual in expecting a certain consistency of licenses within
the community. Perl and Python modules tend to be distributed under
the same license as the base language.

This approach seems less consistent in the Ruby community.

Specifically, I just happened to look at the source code in DBI.rb
and Oracle.rb and was astonished to discover that these modules are
GPL. Then I quickly found trace.rb, and proxy.rb were GPL as well.

Now, if I can get through the next section without flames please. :}

I use Perl and Python to build commercial products for my own company
and for clients.
Most of the applications I’m building are database-driven.
For me, DBI is a core functionality.
Unfortunately, until Ruby provides a non-GPL alternative I need to go
back to Perl or Python.

Does this mean I’m giving up on Ruby?
Absolutely not.
It is a great language and I’m going to have some fun using it.
I hope I can contribute some things to the community as well.
I’m just not going to be able to use it commercially for any of my products.

In summary, inconsistent licensing is the primary reason we’re not
going to be using Ruby around here.
I look forward to hearing the lists comments on this.
I know there’s be a few. :}
–Ray

···

–

2

Specifically, I just happened to look at the source code in DBI.rb
and Oracle.rb and was astonished to discover that these modules are
GPL. Then I quickly found trace.rb, and proxy.rb were GPL as well.

Well… since you are not linking or modifying the source code of these files I
would suppose that the GPL doesn’t affect you at all. You are still able to make
your own propietary program and use these external files.

Or am I wrong? I’m not sure if using a Ruby module constitutes a “derivative
work”.

Secondly, even if it is a derivative work, you can still make propietary
programs for your own company (but not for your clients). The GPL only refers to
the distribution of software. You always have to right to make secret
modifications, as long as you keep all that to yourself.

Finally, who does making your program open source inhibit you from making it
commercial? I mean, if you are currently using Perl and Python you are certainly
not hiding the source code. You can’t! What’s the problem with selling a
GPL-covered application?

It is a great language and I’m going to have some fun using it.
I hope I can contribute some things to the community as well.
I’m just not going to be able to use it commercially for any of my products.

I can assure you that you can use it at least for your internal products. As for
clients, like I said, it’ll depend on whether (a) your application is really
considered a derivative work, and (b) you really cannot sell a GPL to your
clients.

You should also consider contacting the module owners. They might grant you a
special license. But I honestly don’t see what this would get you since you can’t
hide Ruby code anyways.

Cheers,

Daniel Carrera | OpenPGP fingerprint:
Graduate TA, Math Dept | 6643 8C8B 3522 66CB D16C D779 2FDD 7DAC 9AF7 7A88
UMD (301) 405-5137 | http://www.math.umd.edu/~dcarrera/pgp.html

···

On Wed, Jul 09, 2003 at 08:57:58AM +0900, Ray Cote wrote:

3

Ray Cote wrote:

Hi List:

I’ve been a lurker here for about two weeks. In that time, I’ve been
installing Ruby on a number of machines (Mac, Linux, Windows) and
generally having a grand time exploring Ruby and telling anyone who will
sit still for 3 seconds what a great language it is.

Since there’s been a recent thread on how to make Ruby more popular, I
thought I’d mention why Ruby’s popularity came to a screeching halt this
evening. In one word: “Licenses.”

Coming from a background of using Perl and some Python, I’ve become
quite casual in expecting a certain consistency of licenses within the
community. Perl and Python modules tend to be distributed under the same
license as the base language.

This approach seems less consistent in the Ruby community.

Specifically, I just happened to look at the source code in DBI.rb and
Oracle.rb and was astonished to discover that these modules are GPL.
Then I quickly found trace.rb, and proxy.rb were GPL as well.

Now, if I can get through the next section without flames please. :}

I use Perl and Python to build commercial products for my own company
and for clients.
Most of the applications I’m building are database-driven.
For me, DBI is a core functionality.
Unfortunately, until Ruby provides a non-GPL alternative I need to go
back to Perl or Python.

Does this mean I’m giving up on Ruby?
Absolutely not.
It is a great language and I’m going to have some fun using it.
I hope I can contribute some things to the community as well.
I’m just not going to be able to use it commercially for any of my
products.

In summary, inconsistent licensing is the primary reason we’re not going
to be using Ruby around here.
I look forward to hearing the lists comments on this.
I know there’s be a few. :}
–Ray

I’m currently writing a Ruby library for accessing Oracle9i, and I’ve
released it under the Artistic License. I released the first “preview”
version last week. It’s available here:

http://jimcain.us/ruby9i

I will be releasing another version this week. If you are concerned
about licensing issues with the DBI, my library can also be accessed
with its native, low-level API, which is really not low-level, just not
DBI-compliant.

4

Hi Daniel:
Thanks for your comments.

I believe these two items from the GPL FAQ cover the question:
http://www.gnu.org/licenses/gpl-faq.html#WhyUseGPL

···

At 9:08 AM +0900 7/9/03, Daniel Carrera wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jul 09, 2003 at 08:57:58AM +0900, Ray Cote wrote:

Specifically, I just happened to look at the source code in DBI.rb
and Oracle.rb and was astonished to discover that these modules are
GPL. Then I quickly found trace.rb, and proxy.rb were GPL as well.

Well… since you are not linking or modifying the source code of
these files I
would suppose that the GPL doesn’t affect you at all. You are still
able to make
your own propietary program and use these external files.

If a library is released under the GPL (not the LGPL), does that
mean that any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the library

You have a GPL’ed program that I’d like to link with my code to
build a proprietary program. Does the fact that I link with your
program mean I have to GPL my program?
Yes.

Secondly, even if it is a derivative work, you can still make propietary
programs for your own company (but not for your clients).
Correct. I was referring to products we build and distribute to customers.

Finally, who does making your program open source inhibit you from making it
commercial? I mean, if you are currently using Perl and Python you
are certainly
not hiding the source code. You can’t! What’s the problem with selling a
GPL-covered application?
Actually, we are hiding our source code.
We use various utilities for converting Perl or Python to
double-clickable windows executables.
Ruby has this ability as well with the Exerb (though it is not quite
as ‘hidden’ as the Perl or Python examples).

There are a variety of ways of ‘hiding’ code. One of the projects
we’re currently designing consists of a sealed box delivered to the
user, a sort of ‘payment appliance’ if you will. The end user not
only has no access to the code on the machine, they have no need for
access. However, under the GPL, I would be legally bound to
distribute source code for the program on that machine.

You should also consider contacting the module owners. They might grant you a
special license.
Yes, that’s always a possibility. However, I was also addressing the
‘how to make Ruby popular issue.’ Please note that we’re talking
about a pretty fundamental module here – basic database interfacing.
If I have a choice of working in an environment where the licenses
promote commercial use or working in an environment where I need to
check and perhaps get permission for special licenses, I’m going to
take the path of least resistance.

Thanks again for your comments.
–Ray

–

5

Daniel Carrera wrote:

…

Well… since you are not linking or modifying the source code of these files I
would suppose that the GPL doesn’t affect you at all.

It seems to me that importing a module is a form of dynamic linking. I
feel strongly that this is how the FSF would interpret it.

…
Finally, who does making your program open source inhibit you from making it
commercial? I mean, if you are currently using Perl and Python you are certainly
not hiding the source code. You can’t! What’s the problem with selling a
GPL-covered application?

Hiding or not hiding the code is irrelevant. The GPL allows customers to
redistribute your code which means that your customers can easily become
your competitors, selling your code at a discount or even giving it away
for free on their website. You could only “compete” by giving away the
software yourself and shifting to a service model which is a pretty
significant change in business model!

Paul Prescod

6

From what I’ve read regarding the GPL and libraries:

If your program links to a GPL library or application using anything more
than the most generic of mechanisms (such as a stdio pipe), your program
must also be GPL.

An exception to this is if the library in question is distributed as part of
a normal operating system or development environment (language
interpreter/compiler or IDE).

Sean O'Dell

“Daniel Carrera” dcarrera@math.umd.edu wrote in message
news:20030709000836.GA1601@math.umd.edu…

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Specifically, I just happened to look at the source code in DBI.rb
and Oracle.rb and was astonished to discover that these modules are
GPL. Then I quickly found trace.rb, and proxy.rb were GPL as well.

Well… since you are not linking or modifying the source code of these
files I
would suppose that the GPL doesn’t affect you at all. You are still able
to make
your own propietary program and use these external files.

Or am I wrong? I’m not sure if using a Ruby module constitutes a
“derivative
work”.

Secondly, even if it is a derivative work, you can still make propietary
programs for your own company (but not for your clients). The GPL only
refers to
the distribution of software. You always have to right to make secret
modifications, as long as you keep all that to yourself.

Finally, who does making your program open source inhibit you from making
it
commercial? I mean, if you are currently using Perl and Python you are
certainly
not hiding the source code. You can’t! What’s the problem with selling a
GPL-covered application?

It is a great language and I’m going to have some fun using it.
I hope I can contribute some things to the community as well.
I’m just not going to be able to use it commercially for any of my
products.

I can assure you that you can use it at least for your internal products.
As for
clients, like I said, it’ll depend on whether (a) your application is
really
considered a derivative work, and (b) you really cannot sell a GPL to your
clients.

You should also consider contacting the module owners. They might grant
you a
special license. But I honestly don’t see what this would get you since
you can’t

···

On Wed, Jul 09, 2003 at 08:57:58AM +0900, Ray Cote wrote:
hide Ruby code anyways.

Cheers,

Daniel Carrera | OpenPGP fingerprint:
Graduate TA, Math Dept | 6643 8C8B 3522 66CB D16C D779 2FDD 7DAC 9AF7 7A88
UMD (301) 405-5137 | http://www.math.umd.edu/~dcarrera/pgp.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (SunOS)

iD8DBQE/C10DnxE8DWHf+OcRAsEGAKDAhmewOPOrGUJFsarwczqq2F5FGACg4SKM
T76dHUVfHJSSOBdOv6RPYDY=
=B3O0
-----END PGP SIGNATURE-----

7

Hi Daniel:
Thanks for your comments.

I believe these two items from the GPL FAQ cover the question:
http://www.gnu.org/licenses/gpl-faq.html#WhyUseGPL

If a library is released under the GPL (not the LGPL), does that
mean that any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the library

You have a GPL’ed program that I’d like to link with my code to
build a proprietary program. Does the fact that I link with your
program mean I have to GPL my program?
Yes.

Well, it’s not that simple. Ruby modules are not linked into your program the way
a binary library would be. On the other hand, they are not exactly external
programs either. So it’s not quite clear there.

Judging from the first question, I am now leaning towards saying that yes, it is a
derivative work, on the basis that (I think) a “require” actually does “stick in”
the module code into your program, hence making it a derivative. Perhaps someone
could correct or confirm this.

So, yes, it seems that you are right on that.

There are a variety of ways of ‘hiding’ code. One of the projects
we’re currently designing consists of a sealed box delivered to the
user, a sort of ‘payment appliance’ if you will. The end user not
only has no access to the code on the machine, they have no need for
access. However, under the GPL, I would be legally bound to
distribute source code for the program on that machine.

Well… you’d be legally bound to provide it upon request. I apologize if this is
a dumb question, but if the user has no use for the source anyways, what’s the
problem with the GPL?

The user doesn’t need the source. You don’t have to provide the source unless
they want it. What’s the problem?

If I have a choice of working in an environment where the licenses
promote commercial use or working in an environment where I need to
check and perhaps get permission for special licenses, I’m going to
take the path of least resistance.

Well… don’t mixup “commercial” and “propietary”. I still don’t understand why
the GPL would inhibit you from selling your commercial product. I’m sure that
there’s something obvious I’m not seeing. Perhaps you can clarify the problem?

Cheers,

Daniel Carrera | OpenPGP fingerprint:
Graduate TA, Math Dept | 6643 8C8B 3522 66CB D16C D779 2FDD 7DAC 9AF7 7A88
UMD (301) 405-5137 | http://www.math.umd.edu/~dcarrera/pgp.html

···

On Wed, Jul 09, 2003 at 09:35:47AM +0900, Ray Cote wrote:

8

Ray Cote wrote:

···

At 9:08 AM +0900 7/9/03, Daniel Carrera wrote:

Finally, who does making your program open source inhibit you from
making it
commercial? I mean, if you are currently using Perl and Python you
are certainly
not hiding the source code. You can’t! What’s the problem with
selling a
GPL-covered application?

Actually, we are hiding our source code.
We use various utilities for converting Perl or Python to
double-clickable windows executables.
Ruby has this ability as well with the Exerb (though it is not quite as
‘hidden’ as the Perl or Python examples).

There are a variety of ways of ‘hiding’ code. One of the projects we’re
currently designing consists of a sealed box delivered to the user, a
sort of ‘payment appliance’ if you will. The end user not only has no
access to the code on the machine, they have no need for access.
However, under the GPL, I would be legally bound to distribute source
code for the program on that machine.

Actually, you’re probably not hiding your source code. Are you using
perl2exe? Take a look at http://www.net-security.org/vuln.php?id=2464 .
Please note also that this probably applies to all such packaging schemes.

matt

9

Ray Cote graced us by uttering:

Daniel Carrera wrote:

Ray Cote wrote:

I’ve become quite casual in expecting a certain consistency
of licenses within the community. Perl and Python modules
tend to be distributed under the same license as the base
language.

This approach seems less consistent in the Ruby community.

Developers are aware of this in all language communities. In
fact, the tradition of Perl modules being released under the same
license as the interpreter is just that: a tradition. It’s
recommended that developers release their modules this way for
simplicity, but there’s no structure or obligation to it.

In fact, a quick grep of the CPAN reveals several modules release
under the GPL, some under the BSD license, and still others under
completely proprietary licenses.

Specifically, I just happened to look at the source code in
DBI.rb and Oracle.rb and was astonished to discover that
these modules are GPL. Then I quickly found trace.rb, and
proxy.rb were GPL as well.

Well… since you are not linking or modifying the source
code of these files I would suppose that the GPL doesn’t
affect you at all. You are still able to make your own
propietary program and use these external files.

I believe these two items from the GPL FAQ cover the question:
http://www.gnu.org/licenses/gpl-faq.html#WhyUseGPL

If a library is released under the GPL (not the LGPL), does
that mean that any program which uses it has to be under the
GPL?
Yes, because the program as it is actually run includes the
library

This is discussing libraries in the C/C++ sense. If your
commercial code includes C code which links directly with the
GPL’d binary libraries from the above-mentioned modules, this
rule might apply. If, however, you simply use the DBI or Oracle
modules in your Ruby script, this shouldn’t apply.

You have a GPL’ed program that I’d like to link with my code to
build a proprietary program. Does the fact that I link with your
program mean I have to GPL my program?
Yes.

Again, nowhere have you mentioned that you’re linking with a
library released only under the GPL.

Secondly, even if it is a derivative work, you can still
make propietary programs for your own company (but not for
your clients).

Correct. I was referring to products we build and distribute to
customers.

If you’re actually modifying the Ruby code of the module in
question and distributing it, then why shouldn’t your mods come
under the same license? And upon checking, Perl’s Artistic
License also requires this.

If you really want to use Ruby commercially, you’d do far better
to consult an attorney familiar with software licenses than to
post a questionably troll-like usenet article lamenting the loss.

HAND,
Tim Hammerquist

···

–
Windows hasn’t increased computer literacy. It’s just lowered the standard.
– From a Slashdot.org post

10

Paul Prescod paul@prescod.net writes:

Hiding or not hiding the code is irrelevant. The GPL allows customers to
redistribute your code which means that your customers can easily become
your competitors, selling your code at a discount or even giving it away
for free on their website. You could only “compete” by giving away the
software yourself and shifting to a service model which is a pretty
significant change in business model!

Not at all; as copyright owner, you still have the right to license
your code under any other terms you care to. You could offer it with
proprietary-friendly terms (as long as you don’t use GPL components),
and make money that way.

-=Eric

···

–
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
– Blair Houghton.

11

What about applications that can link with either readline or libedit?
Must these be GPL because they can be linked with readline?

I’ve been unable to find the link, but I recall reading that if the
application could be linked to a non-GPL alternative, then the
application does not have to be licensed under the GPL. Linus seems to
take this view with the kernel, since he didn’t want to force the GPL on
drivers written for other OSes that were ported to Linux (though iirc he
also said this shouldn’t be applied to anything other than the kernel).

Paul

···

On Thu, Jul 10, 2003 at 05:14:18AM +0900, Sean O’Dell wrote:

From what I’ve read regarding the GPL and libraries:

If your program links to a GPL library or application using anything more
than the most generic of mechanisms (such as a stdio pipe), your program
must also be GPL.

12

Daniel Carrera wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Daniel:
Thanks for your comments.

I believe these two items from the GPL FAQ cover the question:
http://www.gnu.org/licenses/gpl-faq.html#WhyUseGPL

If a library is released under the GPL (not the LGPL), does that
mean that any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the library

You have a GPL’ed program that I’d like to link with my code to
build a proprietary program. Does the fact that I link with your
program mean I have to GPL my program?
Yes.

Well, it’s not that simple. Ruby modules are not linked into your program the way
a binary library would be. On the other hand, they are not exactly external
programs either. So it’s not quite clear there.

Judging from the first question, I am now leaning towards saying that yes, it is a
derivative work, on the basis that (I think) a “require” actually does “stick in”
the module code into your program, hence making it a derivative. Perhaps someone
could correct or confirm this.

So, yes, it seems that you are right on that.

There are a variety of ways of ‘hiding’ code. One of the projects
we’re currently designing consists of a sealed box delivered to the
user, a sort of ‘payment appliance’ if you will. The end user not
only has no access to the code on the machine, they have no need for
access. However, under the GPL, I would be legally bound to
distribute source code for the program on that machine.

Well… you’d be legally bound to provide it upon request. I apologize if this is
a dumb question, but if the user has no use for the source anyways, what’s the
problem with the GPL?

The user doesn’t need the source. You don’t have to provide the source unless
they want it. What’s the problem?

If I have a choice of working in an environment where the licenses
promote commercial use or working in an environment where I need to
check and perhaps get permission for special licenses, I’m going to
take the path of least resistance.

Well… don’t mixup “commercial” and “propietary”. I still don’t understand why
the GPL would inhibit you from selling your commercial product. I’m sure that
there’s something obvious I’m not seeing. Perhaps you can clarify the problem?

It’s my understanding that the GPL requires anything that links to a
GPL-licensed library to have a GPL license as well. Of course in the
case of shared libraries, the executable and library are in separate
files. But when the thing is actually being executed, the object code
all occupies memory at the same time, if code in the library is being
used. According to the GPL, this is a derived work based on the GPLed
library, and so the GPL applies to the executable in memory.

···

On Wed, Jul 09, 2003 at 09:35:47AM +0900, Ray Cote wrote:

13

The problem is I can buy his app (or just copy it from someone’s computer)
and sell it for half his asking price, or just give it away if I have a
bone to pick with him. If it’s a killer consumer app, it will be available
with Kazaa, and the author will starve.

···

on 7/8/03 8:51 PM, Daniel Carrera at dcarrera@math.umd.edu wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jul 09, 2003 at 09:35:47AM +0900, Ray Cote wrote:

Hi Daniel:
Thanks for your comments.

I believe these two items from the GPL FAQ cover the question:
http://www.gnu.org/licenses/gpl-faq.html#WhyUseGPL

If a library is released under the GPL (not the LGPL), does that
mean that any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the library

You have a GPL’ed program that I’d like to link with my code to
build a proprietary program. Does the fact that I link with your
program mean I have to GPL my program?
Yes.

Well, it’s not that simple. Ruby modules are not linked into your program the
way
a binary library would be. On the other hand, they are not exactly external
programs either. So it’s not quite clear there.

Judging from the first question, I am now leaning towards saying that yes, it
is a
derivative work, on the basis that (I think) a “require” actually does “stick
in”
the module code into your program, hence making it a derivative. Perhaps
someone
could correct or confirm this.

So, yes, it seems that you are right on that.

There are a variety of ways of ‘hiding’ code. One of the projects
we’re currently designing consists of a sealed box delivered to the
user, a sort of ‘payment appliance’ if you will. The end user not
only has no access to the code on the machine, they have no need for
access. However, under the GPL, I would be legally bound to
distribute source code for the program on that machine.

Well… you’d be legally bound to provide it upon request. I apologize if
this is
a dumb question, but if the user has no use for the source anyways, what’s the
problem with the GPL?

–
Regards,
JJ

Be Kind, Be Careful, Be Yourself

14

Well, no sooner do you complain about something and…
While doing some additional digging around, I just discovered that my
copy of one of the libraries I mentioned, DBI, was a bit old and that
the author, Michael Neumann, has since changed the license to BSD.

Thanks Michael! You made my day.
–Ray

···

–

15

They don’t call GPL a legal virus for nothing:

I think the next section is more relevant. It concludes with:

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

This would seem to apply to Ruby in a similar way.

Steve

···

On Tuesday, July 8, 2003, at 08:51 PM, Daniel Carrera wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jul 09, 2003 at 09:35:47AM +0900, Ray Cote wrote:

Hi Daniel:
Thanks for your comments.

I believe these two items from the GPL FAQ cover the question:
http://www.gnu.org/licenses/gpl-faq.html#WhyUseGPL

If a library is released under the GPL (not the LGPL), does that
mean that any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the library

You have a GPL’ed program that I’d like to link with my code to
build a proprietary program. Does the fact that I link with your
program mean I have to GPL my program?
Yes.

Well, it’s not that simple. Ruby modules are not linked into your
program the way
a binary library would be. On the other hand, they are not exactly
external
programs either. So it’s not quite clear there.

Based on the above, I think it would be that simple. This is the main
reason for LGPL and other similar open-source licenses. We want to
share but we still gotta eat.

16

Daniel Carrera wrote:

Well, it’s not that simple. Ruby modules are not linked into your program the way
a binary library would be. On the other hand, they are not exactly external
programs either. So it’s not quite clear there.

Judging from the first question, I am now leaning towards saying that yes, it is a
derivative work, on the basis that (I think) a “require” actually does “stick in”
the module code into your program, hence making it a derivative. Perhaps someone
could correct or confirm this.

So, yes, it seems that you are right on that.

Suppose, though, that you have a core application that allows the user
to define what specific class should be used to perform some task. For
example, you have an app that fetches RSS feeds, but what it does with
those feeds is a plugable option. You just need to configure it to load
some class that responds to, say, handle_rss( some_rss_string ).

A users might configure it use some simple save-to-disk class, or maybe
a DBI-based class that sticks it in database.

By itself the core app code can be any license you like, since it is not
written to depend on any specific (GPL or not) helper code, and it would
seem that this sort of partitioning would keep licensing issues
seperate. Any dynamically loaded helper class that used GPL code would
in turn be GPL, but the core application should not magically change
licenses the moment a user changes configuration and has it load a GPL’d
file.

Or not so? It not, then how could anyone distribute any non-GPL’ed app
framework, or any app that allows for dynamic class loading?

Now, it might seem disingenuous to be the provider of both the core,
non-GPL app, and one or more GPL’ed helper library classes, but I don’t
think that changes the techincal merits. They are separate things: an
app, and a library, with a possible but not necessary relation.

James

17

I appreciate all the comments I’ve received on my earlier email.
Also nice to see the complete lack of flaming. What a nice list!

The problem with the term virus is that it implies malevolence: Jim Cain
I will remove the term ‘viral’ from my vocabulary in regards to the GPL.
Was not meant in a derogatory way.
Was meant simply that a GPL component used within your own program
spreads that GPL license to your own code.
This happens with your permission because you decide to use the GPL
component in the first place. Therefore, there are no ‘surprises’
here. It is pretty clear by using a GPL (not LGPL) component you are
agreeing to GPL the rest of your code as well.

Jim Cain and Stephyn Butcher pointed out that the GPL applies to code
that is linked to or interprets GPL-licensed modules. Perl and Java
modules in particular are referenced as examples.

…the tradition of Perl modules…same license as interpreter is
just that: a tradition. Tim Hammerquist
Agreed. However, I believe the vast majority of modules are released
with a license that is friendly to the commercial and proprietary use
of the code.

After posting my email, I discovered that one of the ruby modules
installed by rubyinstaller.sourceforge.net had been updated by the
author who had changed the license from GPL to BSD. According to the
web site, “This is the BSD license which is less restrictive than
GNU’s GPL (General Public License).” Thank you Michael Neumann.

I would like to conclude by getting back to my original reason for
posting and that was the recent “How to make Ruby more popular”
thread.

In my opinion, one way to ensure the growing popularity of Ruby is to
promote the tradition of releasing Ruby modules under licenses
friendly to commercial and proprietary use.

Thanks again for all the thoughtful comments.

Let’s now return to our regularly-scheduled coding.
–Ray

···

–

18

Eric Schwartz wrote:

Paul Prescod paul@prescod.net writes:
…

Not at all; as copyright owner, you still have the right to license
your code under any other terms you care to. You could offer it with
proprietary-friendly terms (as long as you don’t use GPL components),
and make money that way.

The discussion was about the use of GPLed components. My point was that
if you use those components you can no longer license it under any terms
you care to and that in turn means that it is not really practical to
“sell” it in the sense of selling the bits. Once you allow
redistribution, someone else can redistribute your code at a price much
lower than your own.

Paul Prescod

19

“Paul Brannan” pbrannan@atdesk.com wrote in message
news:20030710203215.GB18259@atdesk.com…

From what I’ve read regarding the GPL and libraries:

If your program links to a GPL library or application using anything
more
than the most generic of mechanisms (such as a stdio pipe), your program
must also be GPL.

What about applications that can link with either readline or libedit?
Must these be GPL because they can be linked with readline?

I’ve been unable to find the link, but I recall reading that if the
application could be linked to a non-GPL alternative, then the
application does not have to be licensed under the GPL. Linus seems to
take this view with the kernel, since he didn’t want to force the GPL on
drivers written for other OSes that were ported to Linux (though iirc he
also said this shouldn’t be applied to anything other than the kernel).

I think this is noted as a gray area of the GPL, but would be determined on
a case-by-case basis. My guess here is, whichever looks to be “the default”
will be used to judge; meaning, if you design to link to either library (GPL
and non-GPL), but you distribute an appropriate non-GPL version of the
library, then you’re ok.

Sean
···

On Thu, Jul 10, 2003 at 05:14:18AM +0900, Sean O’Dell wrote:

20

The GPL is not viral. It is a license. You either take it or you don’t. The
GPL does not magically alter the licensing of your work, copyright law just
doesn’t do that.

GPL estipulates as a condition that if you make a derivative work you have to
release it as GPL. This is NOT the same thing as making your derivative work GPL
without your concent. Your derivative work is yours, and copyright law cannot
change how you choose to release it. Rather, if you release something including
GPL code under a non-GPL license, you are in violation of the GPL license and you
must correct the situation. One way to correct the situation is to change the
license of your work. Another, is to stop using the GPL code whose license you
are not complying with.

The GPL does NOT hope over to other people’s code. It is not viral. It’s a
license. If you don’t like it you don’t use it. But it will NOT force something
on you.

Contrast this with the “Shared Source” license which does effectively contaminate
the developer (not the code, the developer) since it prevents the developer from
using ideas from the code as inspiration for later work (the GPL, does not
restrict this, only the copying of code).

Daniel Carrera | OpenPGP fingerprint:
Graduate TA, Math Dept | 6643 8C8B 3522 66CB D16C D779 2FDD 7DAC 9AF7 7A88
UMD (301) 405-5137 | http://www.math.umd.edu/~dcarrera/pgp.html

···

On Wed, Jul 09, 2003 at 10:57:11AM +0900, Stephyn Butcher wrote:

They don’t call GPL a legal virus for nothing: