• Ant (21/21) Dec 01 2004 I asked on the Gtk mailing list about inlining the
• Ben Hinkle (9/30) Dec 02 2004 sounds messy. I would pick one of the two licenses
• J C Calvarese (13/27) Dec 02 2004 When you brought up this subject earlier
• Ant (20/44) Dec 03 2004 (this one of the least interesting problems)
• J C Calvarese (4/22) Dec 03 2004 My head hurts trying to think about this, but I guess you're right. Than...
• Andy Friesen (9/31) Dec 04 2004 The GPL and LGPL only pertain to your rights to distribute the library,

Ant <duitoolkit yahoo.ca> writes:

I asked on the Gtk mailing list about inlining the
Gtk API documentation when I release it with the
zlib license.
The situation is not clear.

Should I make 2 distribution packages for the 2 licenses?
LGPL - including the API documentation on the code
zlib - strip all /** */ comments from the code

what to do?

also
the LGPL license says:
"...
  9. You are not required to accept this License, since you have not
signed it.  However, nothing else grants you permission to modify or
distribute the Library or its derivative works.
..."

does that excludes distributing the lib with other licenses?
It might be that I can distribute it with other licenses
but others need to conform to LPGL to modify it or redistribute it.

using LGPL with other licenses seems to be common practice.

?

Ant

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"Ant" <duitoolkit yahoo.ca> wrote in message 
news:pan.2004.12.02.05.06.12.722047 yahoo.ca...
I asked on the Gtk mailing list about inlining the
 Gtk API documentation when I release it with the
 zlib license.
 The situation is not clear.

 Should I make 2 distribution packages for the 2 licenses?
 LGPL - including the API documentation on the code
 zlib - strip all /** */ comments from the code

 what to do?

 also
 the LGPL license says:
 "...
  9. You are not required to accept this License, since you have not
 signed it.  However, nothing else grants you permission to modify or
 distribute the Library or its derivative works.
 ..."

 does that excludes distributing the lib with other licenses?
 It might be that I can distribute it with other licenses
 but others need to conform to LPGL to modify it or redistribute it.

 using LGPL with other licenses seems to be common practice.

 ?

 Ant

sounds messy. I would pick one of the two licenses
1) pick the LGPL and ship code+inline doc
2) pick zlib and ship code-inline doc + standalone doc (with whatever 
license that requires...)

With two copies of the code you'd have to double update or use one as the 
master and run some script to generate the other. That just sounds too 
complicated to be worth it. 

J C Calvarese <jcc7 cox.net> writes:

Ant wrote:
 I asked on the Gtk mailing list about inlining the
 Gtk API documentation when I release it with the
 zlib license.
 The situation is not clear.
 
 Should I make 2 distribution packages for the 2 licenses?
 LGPL - including the API documentation on the code
 zlib - strip all /** */ comments from the code
 

...

 using LGPL with other licenses seems to be common practice.
 
 ?
 
 Ant

When you brought up this subject earlier 
(http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/12695) I 
missed the reason that you wanted to move away from LGPL. I'm sure there 
are reasons why LGPL is undesirable, but it seems like a lot of trouble 
to license one LGPL and try to license some other part as something else.

Since GTK+ is licensed under the LGPL and DUI is essentially tied to 
GTK+, it seems to me that you might as well license DUI under the LGPL.

Anyways, good luck on your licensing decisions.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Ant <Ant_member pathlink.com> writes:

In article <cop1v8$2ao$1 digitaldaemon.com>, J C Calvarese says...
Ant wrote:
 I asked on the Gtk mailing list about inlining the
 Gtk API documentation when I release it with the
 zlib license.
 The situation is not clear.
 
 Should I make 2 distribution packages for the 2 licenses?
 LGPL - including the API documentation on the code
 zlib - strip all /** */ comments from the code
 

...

 using LGPL with other licenses seems to be common practice.
 
 ?
 
 Ant

When you brought up this subject earlier 
(http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/12695) I 
missed the reason that you wanted to move away from LGPL. I'm sure there 
are reasons why LGPL is undesirable, but it seems like a lot of trouble 
to license one LGPL and try to license some other part as something else.

Since GTK+ is licensed under the LGPL and DUI is essentially tied to 
GTK+, it seems to me that you might as well license DUI under the LGPL.

Anyways, good luck on your licensing decisions.

(this one of the least interesting problems)

I started with LGPL just because Gtk+ is LGPL.
Gtk+ will be installed on systems that need to run DUI programs.
however DUI is small enough to be linked into the executable.

so I have two problems with LGPL:

first because of point 5 paragraph 2

"
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library".  The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
"

"creates an executable that is a derivative of the Library"
really? I'm not sure. just uses the lib in a different way - as long
as it's not modified. then you have to follow point 6.

second because the license is too verbose,
who is going to read all of that?

Ant

J C Calvarese <jcc7 cox.net> writes:

In article <coq2p0$1hpq$1 digitaldaemon.com>, Ant says...
I started with LGPL just because Gtk+ is LGPL.
Gtk+ will be installed on systems that need to run DUI programs.
however DUI is small enough to be linked into the executable.

so I have two problems with LGPL:

first because of point 5 paragraph 2

"
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library".  The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
"

"creates an executable that is a derivative of the Library"
really? I'm not sure. just uses the lib in a different way - as long
as it's not modified. then you have to follow point 6.

second because the license is too verbose,
who is going to read all of that?

Ant

My head hurts trying to think about this, but I guess you're right. Thanks for
the explanation.

jcc7

Andy Friesen <andy ikagames.com> writes:

Ant wrote:
 I asked on the Gtk mailing list about inlining the
 Gtk API documentation when I release it with the
 zlib license.
 The situation is not clear.
 
 Should I make 2 distribution packages for the 2 licenses?
 LGPL - including the API documentation on the code
 zlib - strip all /** */ comments from the code
 
 what to do?
 
 also
 the LGPL license says:
 "...
   9. You are not required to accept this License, since you have not
 signed it.  However, nothing else grants you permission to modify or
 distribute the Library or its derivative works.
 ..."
 
 does that excludes distributing the lib with other licenses?
 It might be that I can distribute it with other licenses
 but others need to conform to LPGL to modify it or redistribute it.

The GPL and LGPL only pertain to your rights to distribute the library, 
not to what you can do with it once you've gotten it into your hands. 
If you refuse to accept the license, you are still well within your 
rights to use and develop applications that use the library, but you 
have no right to distribute them.

The only real impact I see on relicensing is that people would be able 
to create derivative works of DUI that are not LGPL.

  -- andy