GPL question

Hello,
Suppose that I want to translate a Perl module into Ruby. The Perl module
is available under Perl’s dual license: Artistic and GPL.

Does that mean that I cannot release the Ruby version under Ruby’s dual
license? Since Ruby’s licenses don’t include the Artistic, I would have
to recive the module under the GPL. But the GPL won’t leat me relase the
code under a dual license that includes the GPL. Is that right?

···


Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

Hello,
Suppose that I want to translate a Perl module into Ruby. The Perl
module is available under Perl’s dual license: Artistic and GPL.

IANAL, but maybe the first question is whether this is a derived work as
defined under the GPL. Are you just taking the API or specs and making
a Ruby module, or are you going more line by line? Would even that
count as derived if you’re rewriting it and not copying it literally?
It seems the GPL only deals with actual cut and paste:

2. You may modify your copy or copies of the Program or any portion
   of it, thus forming a work based on the Program, [...]

Further it says:

These requirements apply to the modified work as a whole.  If
identifiable sections of that work are not derived from the
Program and can be reasonably considered independent and separate
works in themselves, then this License, and its terms, do not
apply to those sections when you distribute them as separate
works. [...]

It doesn’t seem to say anything about translation, but maybe I’m
missing something.

Does that mean that I cannot release the Ruby version under Ruby’s
dual license? Since Ruby’s licenses don’t include the Artistic, I
would have to recive the module under the GPL. But the GPL won’t leat
me relase the code under a dual license that includes the GPL. Is
that right?

I don’t know what Ruby’s license would have to do with this, except if
you derive your class from something GPL’d on the Ruby side. But as
far as I understand the GPL, you can’t relicense modified copies
(paragraph 2b says modified copies must be distributed “under the
terms of this License”), you can’t impose additional restrictions on
the original work (paragraph 6).

This is mostly all beside the point, though. If it’s not a derived
work, it’s yours, and you can do what you will (which will hopefully
include the GPL or LGPL). Failing that, you could just ask the author
or authors. They’re the ones granting the license after all, and
they, not the GPL, own the work.

···

On Sun, 16 Feb 2003 06:59:11 +0900 Daniel Carrera dcarrera@math.umd.edu wrote:


Ryan Pavlik rpav@users.sf.net

“Spinal hazards are hazardous…” - 8BT

The dual license means that you can pick one or the other as the basis
for your use of the Perl module. Because of differences between the
Artistic license and the GPL you cannot pick both for purposes of your
derivative work. Note that a translation is usually a derivative work.
Whichever one you pick, you have to follow the terms of that license.

The GPL is the more restrictive of the two licenses – if you pick the
GPL you must license your derivative work to others pursuant to the GPL
only (you can’t authorize use of the derivative work pursuant to the
Artistic license or any other non-GPL license).

If you pick the Artistic license as the basis of your use of the Perl
module to create a derivative work the licensing of your derivative
work to others must comply with the Artistic license. Section 3.a. of
the Artistic License is the relevant one and all of Section 3 is
reproduced below. As I read it, you can redistribute your derivative
work pursuant to any license that is free (as to cost and ability to
modify) and permits redistribution. I think both of Ruby’s licenses
meet this standard of “Freely Available”.

Artistic License Section 3:

"3. You may otherwise modify your copy of this Package in any way,
provided that you insert a prominent notice in each changed file
stating how and when you changed that file, and provided that you do at
least ONE of the following:

a. place your modifications in the Public Domain or otherwise make them
Freely Available [this means no fee charged and a right to
redistribute], such as by posting said modifications to Usenet or an
equivalent medium, or placing the modifications on a major archive site
such as uunet.uu.net, or by allowing the Copyright Holder to include
your modifications in the Standard Version of the Package.

b. use the modified Package only within your corporation or
organization.

c. rename any non-standard executables so the names do not conflict
with standard executables, which must also be provided, and provide a
separate manual page for each non-standard executable that clearly
documents how it differs from the Standard Version.

d. make other distribution arrangements with the Copyright Holder."

···

On Saturday, February 15, 2003, at 04:59 PM, Daniel Carrera wrote:

Hello,
Suppose that I want to translate a Perl module into Ruby. The Perl
module
is available under Perl’s dual license: Artistic and GPL.

Does that mean that I cannot release the Ruby version under Ruby’s dual
license?

“Daniel Carrera” dcarrera@math.umd.edu wrote in message
news:20030215215907.GA743@math.umd.edu

Hello,
Suppose that I want to translate a Perl module into Ruby. The Perl module
is available under Perl’s dual license: Artistic and GPL.

Does that mean that I cannot release the Ruby version under Ruby’s dual
license? Since Ruby’s licenses don’t include the Artistic, I would have
to recive the module under the GPL. But the GPL won’t leat me relase the
code under a dual license that includes the GPL. Is that right?

Well - I don’t know the artistic license - but if close to Ruby you could
probably get the authors permission to use the Ruby’s license.
If you are only copying functionality and not grabbing C-source the license
would not be a real issue although it’s always a grey area peeking into
source.

Mikkel

“Daniel Carrera” dcarrera@math.umd.edu wrote in message
news:20030215215907.GA743@math.umd.edu

Hello,
Suppose that I want to translate a Perl module into Ruby. The Perl module
is available under Perl’s dual license: Artistic and GPL.

Does that mean that I cannot release the Ruby version under Ruby’s dual
license? Since Ruby’s licenses don’t include the Artistic, I would have
to recive the module under the GPL. But the GPL won’t leat me relase the
code under a dual license that includes the GPL. Is that right?

Well - I don’t know the artistic license - but if close to Ruby you could
probably get the authors permission to use the Ruby’s license.
If you are only copying functionality and not grabbing C-source the license
would not be a real issue although it’s always a grey area peeking into
source.

Mikkel

If the original work is licensed under the Artistic and GPL, why can’t
the derivative work also be licensed in the same way? I don’t
understand why, could you explain? Thanks.

···

On Sat, 2003-02-15 at 18:06, Mark Wilson wrote:

The dual license means that you can pick one or the other as the basis
for your use of the Perl module. Because of differences between the
Artistic license and the GPL you cannot pick both for purposes of your
derivative work.


– Jim Weirich jweirich@one.net http://w3.one.net/~jweirich

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)

It’s probably a difference that makes no difference. There are two
licenses in Daniel’s question: the first is the license of the Perl
module and the second is the license of the derivate work he creates.
Because the Perl module can be used pursuant to the Artistic License or
the GPL, as a technical matter you choose one or the other at your
discretion. Note that the dual license is actually “or” and not “and”.

If you distribute a derivative work pursuant to anything other than the
GPL only, then you’ve chosen to use the Artistic License for the Perl
module. So it doesn’t really matter, I suppose. You still have to
follow the terms of the Artistic License, which, unlike the GPL,
permits incorporation into a commercial and/or closed source product.

Where it does matter is if something is GPL only. Then your derivative
work can only be distributed pursuant to the GPL (or pursuant to a
separate license with the copyright owner of the program). Of course,
for many of the most useful GPL programs, there are many authors and
therefore many copyright holders and one would have to get agreement
from all of them to license other than through the GPL.

Finally, Ruby’s license is closer to FreeBSD license, in that you are
free to incorporate the code into your own commercial product and close
off the source to what you wrote, if you wanted to.

···

On Saturday, February 15, 2003, at 11:12 PM, Jim Weirich wrote:

On Sat, 2003-02-15 at 18:06, Mark Wilson wrote:

The dual license means that you can pick one or the other as the basis
for your use of the Perl module. Because of differences between the
Artistic license and the GPL you cannot pick both for purposes of your
derivative work.

If the original work is licensed under the Artistic and GPL, why can’t
the derivative work also be licensed in the same way? I don’t
understand why, could you explain? Thanks.

Finally, Ruby’s license is closer to FreeBSD license, in that
you are free to incorporate the code into your own commercial

Really? I somehow though that dual license can hardly be treated
as “closer to”. Following your logic, the statement “Ruby’s
license is closer to GPL, in that half of the possibility is
GPL”.

product and close off the source to what you wrote, if you
wanted to.

And that makes sense virtually only with grant-funded
development, no business interest directly involved.

Not to (re)start the debate, but it’s a common misconception that
GPL is less business-friendly: see e.g. Sleepycat’s interview:
http://www.winterspeak.com/columns/102901.html .

PS: we at osdn.org.ua would like to prepare good and hopefully
adequate overview of free software licenses for Developers’
Conference we’re planning to do in May 2003 (Kiev, Ukraine).
Links to existing ones would be greatly appreciated.

···

On Sun, Feb 16, 2003 at 03:17:40PM +0900, Mark Wilson wrote:


---- WBR, Michael Shigorin mike@altlinux.ru
------ Linux.Kiev http://www.linux.kiev.ua/

It seems that it comes down to the usage of the word “or” in the dual
license. Hmmm. The mathmetician in me wants to ask if that is an
"exclusive or" or an “inclusive or”. I have no idea what the lawyers
would say. It seems obvious to me that if the original author choose
dual licensing, then he would have no problems with derived works
choosing the same dual licensing terms. But then I recognize that what
is obvious and what is legal are two entirely different realms.

Thanks for the clarification. As a software writer, I try to stay
familiar with legal issues of the different licenses.

···

On Saturday, February 15, 2003, at 11:12 PM, Jim Weirich wrote:

If the original work is licensed under the Artistic and GPL, why can’t
the derivative work also be licensed in the same way? […]

On Sun, 2003-02-16 at 01:17, Mark Wilson wrote:

It’s probably a difference that makes no difference. There are two
licenses in Daniel’s question: the first is the license of the Perl
module and the second is the license of the derivate work he creates.
Because the Perl module can be used pursuant to the Artistic License or
the GPL, as a technical matter you choose one or the other at your
discretion. Note that the dual license is actually “or” and not “and”.


– Jim Weirich jweirich@one.net http://w3.one.net/~jweirich

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)

But that says they have two licences: essentially a non-GPL one for making
money out of, and the GPL for spreading mindshare.

If I am a company who wants to embed BerkeleyDB in my product, without
revealing my source to the whole world, I have to take the non-GPL one.

···

On Sun, Feb 16, 2003 at 08:01:54PM +0900, Michael Shigorin wrote:

Not to (re)start the debate, but it’s a common misconception that
GPL is less business-friendly: see e.g. Sleepycat’s interview:
http://www.winterspeak.com/columns/102901.html .

Oops, should have read further:

"The Sleepycat license says that you may download and use Berkeley DB
at no charge, provided that

  • you do not redistribute your application code off of a single
    physical site; or

  • you make the complete source code for your application freely
    available at no charge.

These are, effectively, the same terms as the GPL. We didn’t use the
GPL for historical reasons – carrying the BSD license and copyrights
from 1.85 would not have been possible under a straight GPL. However,
the license was designed to work exactly the way the GPL does."

So in fact Sleepycat does NOT use the GPL. And it is significantly
different: for example, I can install GPL-derived software on as many of my
own company’s sites as I like, without having to either contact the
copyright owner or release my source to anyone.

Regards,

Brian.

Not to (re)start the debate, but it’s a common misconception that
GPL is less business-friendly: see e.g. Sleepycat’s interview:
http://www.winterspeak.com/columns/102901.html .
But that says they have two licences: essentially a non-GPL one
for making money out of, and the GPL for spreading mindshare.

Not GPL, but enough like that and differing “for historical
reasons only” (bah!).

If I am a company who wants to embed BerkeleyDB in my product,
without revealing my source to the whole world, I have to take
the non-GPL one.

Definitely. But that’s an usual proprietary "business-friendly"
one and not, say, BSD-like.

BTW, that’s seemingly the sense of dual-licensing – if someone
wants to buy the code to produce closed one on top of it, they’re
welcome as long as they fulfil the other part of the deal – pay
the money. In this light, dual “BSD-like + GPL-like” licensing
doesn’t make much sense to me personally, but I’m gonna getting
hit here and now for that :slight_smile:

(philosophically, Sleepycat’s approach is adding completely
different licensing possibility to live off it, and doing dual
free license seems like one predating the whole purpose of the
other, and vice versa)

···

On Sun, Feb 16, 2003 at 08:49:36PM +0900, Brian Candler wrote:


---- WBR, Michael Shigorin mike@altlinux.ru
------ Linux.Kiev http://www.linux.kiev.ua/