ckermit: license advice

[Ian Beckwith]

Hello.

I'm in the process of adopting the ckermit package (currently in
non-free). I've been talking to upstream (Frank da Cruz from the kermit
project at columbia university), and we both would like to see ckermit
in main. He is prepared to consider changes to the license.

The license was modified in 2000 to make it more free, but sadly not
DFSG-free.

The license is at

ftp://ftp.kermit.columbia.edu/kermit/f/COPYING.TXT

and at the end of this message.

The most obvious problem is the requirement not to modify source without
permission of the kermit project.

Their reasons for this are to keep a consistent code base (They
provide free phone/email support funded by kermit license revenue,
which also makes them cautious about changing the license) and to
avoid modified versions with bad things in them trashing their
reputation.

I suggested changing it to something along the lines of "cannot
distribute modified source unless you get permission OR add prominent
disclaimer it is not official kermit and nothing to do with columbia
university" (and maybe make them change the name).

Would that be acceptable in terms of the DFSG?

The crucial paragraph is Clause A:

> Conditions for REDISTRIBUTION are as follows:
> 
> (A) The C-Kermit software, in source and/or binary form, may be
> included WITHOUT EXPLICIT LICENSE in distributions of OPERATING
> SYSTEMS that have OSI (Open Source Initiative, www.opensource.org)
> approved licenses, even if non-Open-Source applications (but not
> operating systems) are included in the same distribution.  Such
> distributions include, but are not limited to, CD-ROM, FTP site,
> Web site, or preinstalled software on a new GENERAL-PURPOSE
> computer, as long as the primary character of the distribution is
> an Open Source operating system with accompanying utilities.  The
> C-Kermit source code may not be changed without the consent of the
> Kermit Project, which will not be unreasonably withheld (this is
> simply a matter of keeping a consistent and supportable code base).

Another possible problem is the reference to Open Source Initiative
approved licenses. Together with the line in the introduction/preamble:

> The intention is to allow C-Kermit to be distributed with "free"
> operating systems such as GNU/Linux, FreeBSD, NetBSD, OpenBSD, The Hurd,
> etc, ...

I would think that amply covers debian, but IANAL.

Are there any other problems with the license?

Thanks,

Ian.

 License follows 

THE C-KERMIT 7.0 AND 8.0 LICENSE

  Last update: Thu Feb  8 17:41:07 2002

This is the new C-Kermit 7.0 and 8.0 license.  The intention is to allow
C-Kermit to be distributed with "free" operating systems such as GNU/Linux,
FreeBSD, NetBSD, OpenBSD, The Hurd, etc, even when the distributions
themselves (such as Red Hat or Caldera) might be sold and/or might include
applications that are not free, and yet still require a license to include
C-Kermit in or with "non-free" products such as commercial OS's, commercial
software packages, embedded systems, and hardware (other than general-purpose
computers preloaded with "free" operating systems), since these licenses
furnish a large portion of the Kermit Project's funding.

There have been some questions about the provision in Clause (A) that:

  The
C-Kermit source code may not be changed without the consent of the
Kermit Project, which will not be unreasonably withheld (this is
simply a matter of keeping a consistent and supportable code base).

The intention of this clause is primarily to make sure that anybody who
makes modifications sends them back to us, since we are the ones have to
support C-Kermit, and so we can carry them through to future releases (so
you don't have to make the same changes again and again).

Secondarily it is to protect Columbia University in the unlikely event of
modifications made with deliberate intent to offend or cause damage.

Any redistributor of C-Kermit under Clause (A) below should rest assured
there is no intention of preventing them from constructing a distribution in
the appropriate format (RPM or whatever) for their product or from issuing
any patches required for their products; we simply want to be informed so we
can maintain a consistent code base and a solid, supportable software
package.  We are happy to work with any redistributor an any issues that
concern them.  If you have questions, send them to [EMAIL PROTECTED]

Note: All changes to this file since 1 January 2000 (the C-Kermit 7.0
release date) are above; the license itself has not changed, except to
update the most recent copyright date.

(Begin)

Copyright (C) 1985, 2002,
  The Trustees of Columbia University in the City of New York.
  All rights reserved.

PERMISSIONS:

The C-Kermit software may be obtained directly from the Kermit Project at
Columbia University (or from any sou

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Henning Makholm]

Scripsit Andrew Suffield <[EMAIL PROTECTED]>

> Hoop jumping to evade the intent of licenses doesn't work unless you
> have expensive lawyers. Which we don't.

And even if we had, we'd want *others* without expensive lawyers to
have the freedoms we promise them nevertheless.

-- 
Henning Makholm "... and that Greek, Thucydides"

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Sven Luther]

On Tue, Jan 13, 2004 at 03:49:20PM +, Henning Makholm wrote:
> Scripsit Sven Luther <[EMAIL PROTECTED]>
> 
> > There were proposals to use the LGPL (already the licence of the ocaml
> > runtime, except a small modification like the one gcc uses), or a dual
> > LGPL + QPL licencing. Would the LGPL be ok in the case of emacs .el
> > files,
> 
> Yes; since it is more permissive than the GPL, there is no problem
> with combing LGPLed code with a GPL work.

Ok, i will forward that information, thanks for your help.

Friendly,

Sven Luther

Legal question about a model

[Roland Marcus Rutschmann]

Hi,

I found a new very promissing software for graphical mapping of EEG at
http://tempo.sourceforge.net/

I contacted the author and filed an ITP. Preliminary debian packages at:
http://neuro.psychologie.uni-oldenburg.de/debian/dists/unstable/main/

Unfortunatly there is a DFSG problem:
The software is totally under GPL but ships with a graphical head-model that 
is confined to the use with tempo itself. (And this model is needed)
Is there any other possibility than bringing it into non-free?

I think this is like an icon that must only use with the original program or 
how is the legal view on this.

Regards,

Roland

-- 
Dr. Roland Marcus Rutschmann <[EMAIL PROTECTED]>
Dep. of Psychology, Univ. Oldenburg, Fak.4/A6, 26111 Oldenburg
Tel.: 0441 798 2836 Fax: +49 441 7985170,
http://neuro.psychologie.uni-oldenburg.de/~rutschmann


pgp37nvFhJvuZ.pgp
Description: signature

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Måns Rullgård]

Andrew Suffield <[EMAIL PROTECTED]> writes:

> On Tue, Jan 13, 2004 at 07:33:34PM +0100, M?ns Rullg?rd wrote:
>> Don Armstrong <[EMAIL PROTECTED]> writes:
>> 
>> > On Tue, 13 Jan 2004, Måns Rullgård wrote:
>> >> Don Armstrong <[EMAIL PROTECTED]> writes:
>> >> > As you can see, linking is not the metric used. Only derivation is.
>> >> 
>> >> Yes, and I say linking isn't a case of derivation.  I can easily
>> >> find any number of people that disagree with RMS about this, so
>> >> who's right?
>> >
>> > If you or other people claim that linking is not a case of derivation,
>> > they can advance arguments about it. Your arguments will be taken even
>> > more seriously by volunteering a reasonable chunk of change to defend
>> > such an argument in a court of law. I think 1-5M US$ ought to suffice.
>> 
>> Oh yes, I forgot.  Whoever has more money is right.
>
> In cases of ambiguity, correct. Which is why "ambiguous" means "no" as
> far as Debian is concerned.

Show me one case in law that isn't ambiguous.

-- 
Måns Rullgård
[EMAIL PROTECTED]

Re: Changes in formal naming for NetBSD porting effort(s)

[Henning Makholm]

Scripsit Branden Robinson <[EMAIL PROTECTED]>

> I'm tired of this argument.  You can interpret that as capitulation if
> that's important to you.  We appear to have divergent premises.  You
> regard trademark saber-rattling as potentially a friendly act.

That is a deliberately falsified and misleading statement of my
position. I'm saying that I do not see any evidence of saber-rattling
happening in this case. That's manifestly different from saying that
saber-rattling is friendly in those cases where it does exist.

-- 
Henning Makholm  "Det er jo svært at vide noget når man ikke ved det, ikke?"

Re: [vorlon@netexpress.net: Re: Bug#181969: [mdadams@ece.uvic.ca: Re: JasPer licensing wrt Debian Linux]]

[Branden Robinson]

On Sun, Jan 04, 2004 at 05:08:26AM +, Andrew Suffield wrote:
> On Fri, Jan 02, 2004 at 11:42:09AM -0800, Michael Adams wrote:
> > Can anyone give me an actual example of a project that
> > would like to use the JasPer JPEG-2000 codec in a non-interoperable
> > way?
> 
> Almighty duh of all duhs, JPEG-2010. Even the original authors
> probably won't be able to do it, if they accept enough patches in the
> meanwhile.
> 
> It's really amazingly stupid to write a license tied to a
> specification in a non-trivially-avoidable manner.

Can, er, someone communicate the above example to Mr. Adams with Mr.
Suffield's colorful tone attenuated a bit?  :)

-- 
G. Branden Robinson|  The noble soul has reverence for
Debian GNU/Linux   |  itself.
[EMAIL PROTECTED] |  -- Friedrich Nietzsche
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: DFSG Freeness of Patent Reciprocity Clauses

[Branden Robinson]

I was asked on IRC to contribute to this thread, so I will.  :)

On Sat, Jan 03, 2004 at 12:52:34PM -0500, Anthony DeRobertis wrote:
> We must look at the entire freeness of a work, not just the copyright 
> freeness.
> 
> However, I think patent revoking clauses that are along the lines of:
> 
>   We won't sue you for patent infringement over your use of this
>   software, provided you don't sue us for patent infringement on
>   our use of this software. [0]
> 
> are fine. Note that clauses along those lines have the wonderful effect 
> of vanishing if, when, and where software patents are not valid.
[...]
> 
> [0] Please take this with some common sense, not legal sense.

On Fri, Jan 02, 2004 at 08:13:43PM +, MJ Ray wrote:
> My opinion is that patent termination clauses must only affect patent 
> grant clauses of the same covered work. Terminating all patent grants 
> for any action, or terminating copyright grants for patent action are 
> extra restrictions. Also, I find it useful to consider the effect on a 
> saner place that has no patents for software. If licensees there are 
> affected by the patent clauses, something is probably wrong.

I concur with the above remarks of Anthony and MJ.

On Sat, Jan 03, 2004 at 12:52:34PM -0500, Anthony DeRobertis wrote:
> The IBM one seems too broad as well, but as long as IBM is not actively 
> enforcing patents on the software, our policy is to ignore patents that 
> may exist. So we can still treat it as free.

I am not at all sure that it is wise to give non-DFSG-freeness a pass on
these grounds.  IBM does, at present, have litigation pending enforcing
parts of its patent portfolio, notably in the SCO case.  That SCO is a
detestable entity is not the point.

I think it would be wise to review our toleration of this clause of the
IBM Public License.

Has Apache put this new license of theirs into production yet?  Once
they have, it might be a good time to try to organize the community in
an effort to persuade IBM to dial back the aggression in its patent
termination clause.  IBM is clearly quite capable of emptying both
barrels of the patent gun into the chests of entities who aggravate it
without opening the IBMPL's box of shells.

-- 
G. Branden Robinson| Q: How does a Unix guru have sex?
Debian GNU/Linux   | A: unzip;strip;touch;finger;mount;
[EMAIL PROTECTED] |fsck;more;yes;fsck;fsck;fsck;
http://people.debian.org/~branden/ |umount;sleep


signature.asc
Description: Digital signature

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Andrew Suffield]

On Mon, Jan 12, 2004 at 11:10:00PM -0500, Walter Landry wrote:
> > > uncertain about whether you should disable the automatic generation of
> > > .elc files.
> > 
> > Why ? We clearly are not violating the GPL by doing so, so where is the
> > problem.
> 
> If Debian sets up everything so that the user automatically makes the
> link in the postinst, a judge might see that as legally equivalent to
> distributing the compiled form.  Especially since Debian distributes
> Emacs as well.  It gets rather murky, and starts getting into what
> people's intent is.  It might be fine, but I am uncertain.

Hoop jumping to evade the intent of licenses doesn't work unless you
have expensive lawyers. Which we don't.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Andrew Suffield]

On Tue, Jan 13, 2004 at 07:33:34PM +0100, M?ns Rullg?rd wrote:
> Don Armstrong <[EMAIL PROTECTED]> writes:
> 
> > On Tue, 13 Jan 2004, Måns Rullgård wrote:
> >> Don Armstrong <[EMAIL PROTECTED]> writes:
> >> > As you can see, linking is not the metric used. Only derivation is.
> >> 
> >> Yes, and I say linking isn't a case of derivation.  I can easily
> >> find any number of people that disagree with RMS about this, so
> >> who's right?
> >
> > If you or other people claim that linking is not a case of derivation,
> > they can advance arguments about it. Your arguments will be taken even
> > more seriously by volunteering a reasonable chunk of change to defend
> > such an argument in a court of law. I think 1-5M US$ ought to suffice.
> 
> Oh yes, I forgot.  Whoever has more money is right.

In cases of ambiguity, correct. Which is why "ambiguous" means "no" as
far as Debian is concerned.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: latex2html license: "A Letter to Leeds University", round 2

[Branden Robinson]

On Fri, Jan 09, 2004 at 10:42:18PM +0100, Roland Stigge wrote:
> Hi,
> 
> thanks Matt, for polishing my first draft of the letter[1]. I
> incorporated your changes, made the wording "University of Leeds" more
> consistent and changed "Debian GNU/Linux" back to "Debian" (IMO the
> project name is "Debian", while "Debian GNU/Linux" is a product).
> 
> I will submit the attached version to the latex2html mailing list[2] to
> make sure the maintainer and the original author basically agree.
> 
> Then, I will send the letter together with copies of the current
> latex2html license and the GPLv2 to the University of Leeds.

If it's not too late, I have a suggestion.

Change:

Changing the license terms to would allow the program to return to our
main distribution and facilitate the already large user base of
LaTeX2HTML.

To:

Changing the license terms to would allow the program to return to our
main distribution and potentially further expand the already large user
base of LaTeX2HTML.

"facilitate" is not the correct term.  Also, I am not sure that a
copyright "vests" in a work.  It may do many things, but I am not sure
that "vesting" is one of them.  OTOH, after dict(1)ing, I could be
wrong.

I finally suggest that the wording of these sorts of letters be
discussed in plain text, and their near-final form reached before
rendering them in TeX format.  It's much easier to discuss plain text on
a mailing list.  Nevertheless you get style points for using LaTeX
to write a relicensing request letter to the copyright holders of
LaTeX-related software.  :)

-- 
G. Branden Robinson| I don't care if it has a GUI, or
Debian GNU/Linux   | command line, or is carved in mud
[EMAIL PROTECTED] | with a sharp spoon.
http://people.debian.org/~branden/ | -- Barry Smith


signature.asc
Description: Digital signature

Quake WADs (was: Packaging Linuxant's driverloader?)

[Branden Robinson]

On Fri, Jan 09, 2004 at 07:42:06AM -0500, Walter Landry wrote:
> MJ Ray <[EMAIL PROTECTED]> wrote:
> > On 2004-01-09 03:48:49 + Joel Konkle-Parker <[EMAIL PROTECTED]> 
> > wrote:
> > 
> > > I guess the meat of my question applies to ndiswrapper
> > >  as well. ndiswrapper itself is GPL,
> > > but to work properly, requires the Windows drivers for the network
> > > devices it is trying to configure. Does this somehow prevent it
> > > from going into Debian, or could the package just request those
> > > files from a Windows partition or something?
> > 
> > Does ndiswrapper require them to work properly? The main part of 
> > ndiswrapper is a kernel module that I think provides an API normally 
> > found on Windows. The package also provides tools to load and use the 
> > Windows drivers. Even with no Windows driver loaded, the API is there, 
> > so it could be seen as "working properly" but unused. As far as I can 
> > tell, the Windows drivers are not used by the build process at all.
> 
> I think it is analogous to Quake.  Quake's source is free, but to do
> anything useful (or fun) requires the shareware wads.  So until
> someone actually writes a free driver that ndiswrapper can use, I
> would say that it belongs in contrib.

I heard (on IRC) that someone wrote some DFSG-free WAD files for Quake
-- some sort data set to facilitate a World War II battle simulation.

If this fact is validated, the quake packages might be able to be moved
to main.  This is definitely something that can happen if the Free
WAD(s) are packaged, and uploaded to main themselves.

Anyone know any more about this?

-- 
G. Branden Robinson|  You live and learn.
Debian GNU/Linux   |  Or you don't live long.
[EMAIL PROTECTED] |  -- Robert Heinlein
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: summary of software licenses in non-free

[Branden Robinson]

On Sat, Jan 10, 2004 at 06:53:55PM -0500, Glenn Maynard wrote:
> On Sat, Jan 10, 2004 at 05:44:36PM -0500, Anthony DeRobertis wrote:
> > (if it's even valid, bitmap fonts can't be 
> > copyrighted in the US)
> 
> This doesn't help Debian; I think the "bitmap font copyright" thing
> is an isolated strangeness of US law.

I don't think it's strange; it's one of the increasingly rare islands of
sanity in the U.S. legal code.  :)

-- 
G. Branden Robinson| Suffer before God and ye shall be
Debian GNU/Linux   | redeemed.  God loves us, so He
[EMAIL PROTECTED] | makes us suffer Christianity.
http://people.debian.org/~branden/ | -- Aaron Dunsmore


signature.asc
Description: Digital signature

Re: summary of software licenses in non-free

[Branden Robinson]

On Sat, Jan 10, 2004 at 11:11:52AM -0600, Steve Langasek wrote:
> [Cc:ed to debian-legal, as the detailed examination of licenses is more
> on-topic for that list; d-l folks, feel free to drop the reference to
> d-vote if further nitpicking is required ;)]
[...]
> On Sat, Jan 10, 2004 at 06:57:09PM +1100, Craig Sanders wrote:
> 
> > some people expressed doubt about the claims i made regarding the actual
> > contents of non-free.  i said that very few packages were proprietary, that
> > almost all were 'almost-free' (aka 'semi-free').
> > sgb modified files must be renamed and clearly identified.  why 
> > is this in
> > non-free?
> 
> ISTR this license element came up for discussion in the context of the
> LaTeX license; I /thought/ the conclusion was that requiring changes to
> filenames in the source was ok, but that requiring changes to filenames
> in the binary package was not.  Debian-legal, please correct me if I'm
> wrong.

I don't believe that's correct.  A requirement to change the filename at
any stage was dropped from the latest draft of the LPPL that Frank
Mittelbach posted to debian-legal (summer 2003).

I personally[1] would maintain that a requirement to change a filename
is an unacceptable restriction on one's freedom to modify the work.  The
LaTeX Project no longer appears to be interested in contending this
issue, and I know of no other copyright holder of software packaged by
the Debian Project who does.

[1] other subscribers to -legal may feel differently

-- 
G. Branden Robinson|
Debian GNU/Linux   | Ab abusu ad usum non valet
[EMAIL PROTECTED] | consequentia.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Måns Rullgård]

Don Armstrong <[EMAIL PROTECTED]> writes:

> On Tue, 13 Jan 2004, Måns Rullgård wrote:
>> Don Armstrong <[EMAIL PROTECTED]> writes:
>> > As you can see, linking is not the metric used. Only derivation is.
>> 
>> Yes, and I say linking isn't a case of derivation.  I can easily
>> find any number of people that disagree with RMS about this, so
>> who's right?
>
> If you or other people claim that linking is not a case of derivation,
> they can advance arguments about it. Your arguments will be taken even
> more seriously by volunteering a reasonable chunk of change to defend
> such an argument in a court of law. I think 1-5M US$ ought to suffice.

Oh yes, I forgot.  Whoever has more money is right.

-- 
Måns Rullgård
[EMAIL PROTECTED]

Re: Changes in formal naming for NetBSD porting effort(s)

[Branden Robinson]

On Thu, Jan 01, 2004 at 10:29:24PM +, Henning Makholm wrote:
> Scripsit Branden Robinson <[EMAIL PROTECTED]>

[snip]

I'm tired of this argument.  You can interpret that as capitulation if
that's important to you.  We appear to have divergent premises.  You
regard trademark saber-rattling as potentially a friendly act.  I don't.
It appears unlikely that either of us will change our positions.

Once SPI's trademark committee has built up a full head of steam, I
suggest that any Debian developer who receives a message regarding our
actual or potential usage of a U.S. trademark forward the issue to that
committee for analysis.  It's my understanding that actual lawyers with
competence in this area will be participating.

-- 
G. Branden Robinson|Damnit, we're all going to die;
Debian GNU/Linux   |let's die doing something *useful*!
[EMAIL PROTECTED] |-- Hal Clement, on comments that
http://people.debian.org/~branden/ |   space exploration is dangerous


signature.asc
Description: Digital signature

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Don Armstrong]

On Tue, 13 Jan 2004, Måns Rullgård wrote:
> Don Armstrong <[EMAIL PROTECTED]> writes:
> > As you can see, linking is not the metric used. Only derivation is.
> 
> Yes, and I say linking isn't a case of derivation.  I can easily
> find any number of people that disagree with RMS about this, so
> who's right?

If you or other people claim that linking is not a case of derivation,
they can advance arguments about it. Your arguments will be taken even
more seriously by volunteering a reasonable chunk of change to defend
such an argument in a court of law. I think 1-5M US$ ought to suffice.

> > The question is: Is the code a derivative work of Emacs? RMS seems
> > to believe that it is. As the FSF is the group in a position to
> > prosecute such a case, we generally will acquiese to their
> > viewpoint unless you
> 
> So why don't you just blindly believe it when (possibly evil)
> companies make claims beneficial to them?

If a company interprets their apparently DFSG-Free license in a manner
that is non-free, or causes other software to be non-distributable, we
have two choices: Live with their interpretation, or fight their
interpretation.

As Debian itself generally does not have the resources to fight over
the copyright holder's interpretation of the terms of their own work,
especially when the interpretation is seemingly reasonable, we
generally fix the problem either by changing licensing of conflicting
works, removing the work in question, or working outside of the legal
system with upstream to clarify the terms of the work.


Don Armstrong

-- 
If I had a letter, sealed it in a locked vault and hid the vault
somewhere in New York. Then told you to read the letter, thats not
security, thats obscurity. If I made a letter, sealed it in a vault,
gave you the blueprints of the vault, the combinations of 1000 other
vaults, access to the best lock smiths in the world, then told you to
read the letter, and you still can't, thats security.
 -- Bruce Schneier

http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Henning Makholm]

Scripsit Sven Luther <[EMAIL PROTECTED]>

> There were proposals to use the LGPL (already the licence of the ocaml
> runtime, except a small modification like the one gcc uses), or a dual
> LGPL + QPL licencing. Would the LGPL be ok in the case of emacs .el
> files,

Yes; since it is more permissive than the GPL, there is no problem
with combing LGPLed code with a GPL work.

-- 
Henning Makholm "The practical reason for continuing our
  system is the same as the practical reason
  for continuing anything: It works satisfactorily."

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Sven Luther]

On Tue, Jan 13, 2004 at 10:21:31AM -0500, Jeremy Hankins wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > Yeah, but as i see it, there is no need for such a licence change, and
> > the upstream author being an intelligent person, will probably
> > immediately see it, and respond to me : but there is no need for such
> > a change. And then, were do i stand ? I was expecting help from
> > debian-legal to know what to respond to him, but look at what i get.
> 
> I understand that you asked for help providing a reason for a license
> change.  But d-l isn't the best place to go for that help in this case;
> the FSF is.  They have people who answer questions about GPL
> compatibility, and I'm sure they can explain their reasoning much more
> authoritatively than we can.  They're the experts on GPL compatibility,
> not us.  If you send mail to [EMAIL PROTECTED] and politely explain the
> situation I'm sure they'd be willing to help you.

Yeah, sure. but the ftp-master mostly act on debian-legal's advice, so
this is the natural place for this, especially when i get a bug report
like this one.

Anyway, i am in discussion with upstream about this now.

Friendly,

Sven Luther

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Jeremy Hankins]

Sven Luther <[EMAIL PROTECTED]> writes:

> Yeah, but as i see it, there is no need for such a licence change, and
> the upstream author being an intelligent person, will probably
> immediately see it, and respond to me : but there is no need for such
> a change. And then, were do i stand ? I was expecting help from
> debian-legal to know what to respond to him, but look at what i get.

I understand that you asked for help providing a reason for a license
change.  But d-l isn't the best place to go for that help in this case;
the FSF is.  They have people who answer questions about GPL
compatibility, and I'm sure they can explain their reasoning much more
authoritatively than we can.  They're the experts on GPL compatibility,
not us.  If you send mail to [EMAIL PROTECTED] and politely explain the
situation I'm sure they'd be willing to help you.

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Sven Luther]

On Mon, Jan 12, 2004 at 08:53:42AM -0500, Walter Landry wrote:
> Sven Luther <[EMAIL PROTECTED]> wrote:
> > Forgot to add debian-legal to CC, done now.
> > 
> > On Mon, Jan 12, 2004 at 08:43:45AM +0100, luther wrote:
> > > On Sun, Jan 11, 2004 at 05:03:05PM +0200, Kalle Olavi Niemitalo wrote:
> > > > Package: ocaml
> > > > Version: 3.07.2a-2
> > > > Severity: serious
> > > > 
> > > > While looking for the invalid `if' form in caml-types.el, I
> > > > noticed that the Emacs Lisp files of OCaml are "distributed under
> > > > the terms of the Q Public License version 1.0".  According to
> > > > ,
> > > > RMS thinks "that a program that uses Emacs facilities needs to
> > > > be GPL-covered".
> > > 
> > > O, bother.
> > > 
> > > > If RMS is right about this, then it would seem that these files
> > > > cannot be distributed.
> > > 
> > > if RMS is right, then i will ask upstream to modify their licence, after
> > > all i am in good enough relation with them that i have other means of
> > > solving this kind of issues than the threat to remove stuff.
> > > 
> > > But let's first ask debian-legal about this.
> > > 
> > > Debian-legal, can you give me advice about this issue, so i can go to
> > > upstream with informed opinions and legal theory ?
> > > 
> > > I have some doubts about this, since th GPL is all about distribution,
> > > not use, and since we distribute the .el in source form and have them
> > > compiled on the users system, and the actual linking only occurs at use
> > > time, there is no way a GPL distribution restriction should apply.

Ok, i contacted upstream, and at least some of the authors have
expressed an interest in changing licence. Some questions have come up
though.

There were proposals to use the LGPL (already the licence of the ocaml
runtime, except a small modification like the one gcc uses), or a dual
LGPL + QPL licencing. Would the LGPL be ok in the case of emacs .el
files, or is there a problem with that ? 

The dual licencing is, i think, to cover the case where in the future a
non-GPLed emacs clone would spring forth and could thus use these .el
without having to go to all the trouble to asking every author of every
modification to agree to modify its licence for it.

Friendly,

Sven Luther

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Henning Makholm]

Scripsit [EMAIL PROTECTED] (Måns Rullgård)

> > No. The GPL restricts the creation of derivative works. Linking is
> > considered by the FSF to be a case of derivation, but it is certainly
> > not the only way that a derived work can be generated.

> And since when does the FSF have the final word in legal matters.

If the FSF sues us (or someone else) for distributing Emacs together
with code that they don't want Emacs distributed with, then the FSF's
word about how the licence is to be interpreted will have a very
strong weight in court, given that they are the copyright holders as
well as the authors of the license.

They cannot make claims that *clearly* are not substantiated by the
license, but if there is any reasonable doubt about how the license
is to be interpreted, we must expect that a court will rule in favor
of the author's interpretation.

The FSF would probably have a hard time claiming any copyright
interest in the distribution of elisp source that they had nothing to
do with - but we certainly need permission from the FSF to distribute
Emacs itself. The conditions for getting that permission are outlined
in the GPL, but when there is more than one possible interpretation of
the GPL, the one FSF likes most wins.

-- 
Henning Makholm  Set your feet free!

Re: Bug#211765: Request for someone to talk to copyright holders

[Branden Robinson]

On Fri, Jan 09, 2004 at 02:38:45PM -0600, Steve Langasek wrote:
> On Fri, Jan 09, 2004 at 03:25:25PM -0500, Branden Robinson wrote:
> > On Fri, Jan 09, 2004 at 11:19:00PM +1000, Anthony Towns wrote:
> > > So, is there anyone here with the time and energy to look into this issue,
> > > and ideally others?
[...]
> > Particularly valuable in this particular case would probably be someone
> > who is a known quantity to SGI.
> 
> I'm aware of one developer who is currently an SGI employee; I'll check
> with him to see what approach he recommends.

Thank you *very* much; please keep the bug number and the -legal mailing
list posted.

-- 
G. Branden Robinson| One doesn't have a sense of humor.
Debian GNU/Linux   | It has you.
[EMAIL PROTECTED] | -- Larry Gelbart
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Måns Rullgård]

Don Armstrong <[EMAIL PROTECTED]> writes:

> On Tue, 13 Jan 2004, Sven Luther wrote:
>> And, were is the problem ? The GPL is especifically against
>> distributing the result of the linking of GPLed code with
>> uncompatible code.
>
> No. The GPL restricts the creation of derivative works. Linking is
> considered by the FSF to be a case of derivation, but it is certainly
> not the only way that a derived work can be generated.

And since when does the FSF have the final word in legal matters.

>> It doesn't say anything against distributing GPLed and GPL
>> incompatible but free code in the same tarball or package, as long
>> as it is not linked together.
>
> From §2:
>
>  But when you distribute the same sections as part of a whole
>  which is a work based on the Program, the distribution of the
>  whole must be on the terms of this License,
>
> As you can see, linking is not the metric used. Only derivation is.

Yes, and I say linking isn't a case of derivation.  I can easily find
any number of people that disagree with RMS about this, so who's
right?

>> If that was not the case, then all our GPLed packages would have
>> been undistributable, since at least the GPL document itself is
>> clearly non-free.
>
> No. The license itself is _not_ a work based on a GPLed
> program. Therefore its aggregation with the work in question isn't at
> issue. Furthermore, it's likely that licenses may not actually be
> copyrightable... and regardless, licenses generally exist in a gray
> area anyway, so they're not a particularly useful example.

You guys seem to dismiss any argument you don't like as belonging to a
gray area.  *Everything* about licenses or other legalities is gray.

>> I don't know, i have the impression that the response i am getting
>> here are not based on legal theory and reading and interpreting the
>> licence, but on some pre-decision made because of that RMS quote.
>
> The question is: Is the code a derivative work of Emacs? RMS seems to
> believe that it is. As the FSF is the group in a position to prosecute
> such a case, we generally will acquiese to their viewpoint unless you

So why don't you just blindly believe it when (possibly evil)
companies make claims beneficial to them?

-- 
Måns Rullgård
[EMAIL PROTECTED]

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Sven Luther]

On Mon, Jan 12, 2004 at 08:53:42AM -0500, Walter Landry wrote:
> Sven Luther <[EMAIL PROTECTED]> wrote:
> > Forgot to add debian-legal to CC, done now.
> > 
> > On Mon, Jan 12, 2004 at 08:43:45AM +0100, luther wrote:
> > > On Sun, Jan 11, 2004 at 05:03:05PM +0200, Kalle Olavi Niemitalo wrote:
> > > > Package: ocaml
> > > > Version: 3.07.2a-2
> > > > Severity: serious
> > > > 
> > > > While looking for the invalid `if' form in caml-types.el, I
> > > > noticed that the Emacs Lisp files of OCaml are "distributed under
> > > > the terms of the Q Public License version 1.0".  According to
> > > > ,
> > > > RMS thinks "that a program that uses Emacs facilities needs to
> > > > be GPL-covered".

Notice that he also say :

> Do you think that elisp codes that `require' Emacs GPL'ed modules need
> to be GPL'eg themselves?  Or is Emacs and all its libraries simply
> considered an interpreter, and the license of the elisp code isn't
> relevant (and could even be closed, released only in byte-compiled
> form)?  It would be good to clarify your position on the gnu web pages
> somewhere.

In this case, isn't it that the .el only use elisp as an interpreter,
and does not link to emacs ? As well as emacs being able to run said
.elc, without necessarily linking to it, a bit like an GPLed java
virtual machine would be able to run closed source java bytecode ?

I am not sure here, but a emacs/lisp expert would have to say.

In any case, rms is much less strong in its argumentation that you would
have left me to think.

Anyway, i am writing to upstream, and it may well be that the problem
will soon become moot.

Friendly,

Sven Luther

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Don Armstrong]

On Tue, 13 Jan 2004, Sven Luther wrote:
> And, were is the problem ? The GPL is especifically against
> distributing the result of the linking of GPLed code with
> uncompatible code.

No. The GPL restricts the creation of derivative works. Linking is
considered by the FSF to be a case of derivation, but it is certainly
not the only way that a derived work can be generated.

> It doesn't say anything against distributing GPLed and GPL
> incompatible but free code in the same tarball or package, as long
> as it is not linked together.

From §2:

 But when you distribute the same sections as part of a whole
 which is a work based on the Program, the distribution of the
 whole must be on the terms of this License,

As you can see, linking is not the metric used. Only derivation is.

> If that was not the case, then all our GPLed packages would have
> been undistributable, since at least the GPL document itself is
> clearly non-free.

No. The license itself is _not_ a work based on a GPLed
program. Therefore its aggregation with the work in question isn't at
issue. Furthermore, it's likely that licenses may not actually be
copyrightable... and regardless, licenses generally exist in a gray
area anyway, so they're not a particularly useful example.

> I don't know, i have the impression that the response i am getting
> here are not based on legal theory and reading and interpreting the
> licence, but on some pre-decision made because of that RMS quote.

The question is: Is the code a derivative work of Emacs? RMS seems to
believe that it is. As the FSF is the group in a position to prosecute
such a case, we generally will acquiese to their viewpoint unless you
present sound and convincing theory as to why the work should
reasonably be considered a work not derived from Emacs. Preferably by
engaging in a conversation with the FSF themselves and convincing them
of their error (if they are indeed wrong.)

> And what do you give as reason for why the change is needed ?

The change might actually be forced, rather than merely "needed".

> Anyway, i have looked at the files in question again, and of the 10
> or so emacs files, two are under the GPL (well, one is even under
> the GPL v1 or later), while 7 have no licence text and 1 only is
> QPLed, i will thus ask the ocaml-team about this, 

The 7 files without a license text need to be changed to have a
license, presumably GPL (or something else that is generally
considered to be GPL compatible.) The text that is QPLed should
probably be dual licensed QPL/GPL or just removed from the upstream
distribution entirely when you package it for Debian.


Don Armstrong

-- 
"...Yet terrible as UNIX addiction is, there are worse fates. If UNIX
is the heroin of operating systems, then VMS is barbiturate addiction, the
Mac is MDMA, and MS-DOS is sniffing glue. (Windows is filling your sinuses
with lucite and letting it set.) You owe the Oracle a twelve-step program."
 --The Usenet Oracle

http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Sven Luther]

On Mon, Jan 12, 2004 at 11:10:00PM -0500, Walter Landry wrote:
> Sven Luther <[EMAIL PROTECTED]> wrote:
> > On Mon, Jan 12, 2004 at 08:53:42AM -0500, Walter Landry wrote:
> > > DFSG #2:
> > > 
> > >   The program must include source code, and must allow distribution in
> > >   source code as well as compiled form.
> > 
> > But we don't do distribute compiled forms, and it doesn't really make
> > sense to do so.
> 
> Note that DFSG #2 says "must allow distribution".  Debian is not
> allowed to distribute binaries, regardless of whether it would like
> to.

Yep, Debian is. There is absolutely no reason to distribute compiled
.elc files, even if we don't do it. The only restriction is on linking,
which will only happen on the users machine anyway.

> > > It sounds like we can't distribute compiled forms.  You could put this
> > > in non-free, since we can distribute the source.  In that case, I am
> > 
> > Ah, but we are going to remove non-free anyway, so i clearly won't do
> > that.
> > 
> > > uncertain about whether you should disable the automatic generation of
> > > .elc files.
> > 
> > Why ? We clearly are not violating the GPL by doing so, so where is the
> > problem.
> 
> If Debian sets up everything so that the user automatically makes the
> link in the postinst, a judge might see that as legally equivalent to

Nope, not in the postinst, but only when launching emacs.

> distributing the compiled form.  Especially since Debian distributes
> Emacs as well.  It gets rather murky, and starts getting into what
> people's intent is.  It might be fine, but I am uncertain.

Mmm, i don't know legal stuff so well, so i cannot say. My impression is
that a judge will laugh in your face if we ever come to him about such a
petty complaint, but well.

> > > So I think talking to the upstream is a good idea.
> > 
> > Sure, but on more serious ground than this. Notice that the bugreport
> > claims that RMS thinks that ..., not that it is actually true.
> 
> Regardless of what RMS thinks, do you think that the compiled forms
> are legally distributable?  I am far from an expert on lisp compilers,

Yes. They are just compiled bytecode, not linked with emacs in any way.
If i understood it well, they have even less emacs in them than .o files
have gcc code in them, and gcc has a special excemption for libcrt.o or
whatever this stuff is named that goes into all binary files produced by
gcc.

> but I would think that the lisp compiler mingled itself with the code
> just as much as a C compiler.

I fear this is not the case. And anyway, this is then the lisp compiler,
not emacs we are then speaking about.

Anyway, i will write an email to upstream about this all by myself,
thanks for your time though.

Friendly,

Sven Luther

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

[Sven Luther]

On Mon, Jan 12, 2004 at 05:18:40PM -0500, Brian T. Sniffen wrote:
> Sven Luther wrote:
> >On Mon, Jan 12, 2004 at 02:12:13PM -0500, Brian T. Sniffen wrote:
> >
> >>Sven Luther wrote:
> >>
> >>>On Mon, Jan 12, 2004 at 01:00:54PM -0500, Jeremy Hankins wrote:
> >>>
> >>>
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> 
> 
> >>uncertain about whether you should disable the automatic generation
> >>of .elc files.
> >
> >Why ? We clearly are not violating the GPL by doing so, so where is
> >the problem.
> 
> If the situation is perfectly clear and uncontroversial to you, either
> you don't know what you're talking about, or everyone else is confused
> but you.  I put my money on the former.  Saying you disagree is one
> thing, saying any other perspective is clearly wrong is silly.
> >>>
> >>>
> >>>Come on, we don't distribute binaries of it, so how could this break the
> >>>GPL ?
> >>
> >>Simple: Debian distributes Emacs and this elisp file.  Futher, it 
> >>distributes a mechanism for combining them and causing them to 
> >>interoperate.  Thus, any Debian Distribution installation of both is a 
> >>derived work of both Emacs and this elisp file.  The components must be 
> >>available under the terms of the GPL, so that individual component -- 
> >>the elisp file -- must be available under the terms of the GPL.
> >
> >
> >Yep, but whatever you say, the GPL is a licence which applies on
> >distribution only, not use.
> 
> Indeed.  And you are pointing out that we distribute Emacs and this 
> elisp file together, more closely intermingled than "mere aggregation" 
> would imply.

And, were is the problem ? The GPL is especifically against distributing
the result of the linking of GPLed code with uncompatible code. It
doesn't say anything against distributing GPLed and GPL incompatible but
free code in the same tarball or package, as long as it is not linked
together. If that was not the case, then all our GPLed packages would
have been undistributable, since at least the GPL document itself is
clearly non-free.

I don't know, i have the impression that the response i am getting here
are not based on legal theory and reading and interpreting the licence,
but on some pre-decision made because of that RMS quote. I am quite
disapointed.

> >>>The DFSG issue might be a different story, but even there, i am not sure
> >>>it is correct though, since the GPL cause problem at link time, not at
> >>>binary distribution time. And nothing is stopping us to distribute
> >>>binaries of the .el compiled by a non-GPL lisp compiler or something.
> >>
> >>Good luck finding a non-GPL'd compiler for a dynamically scoped Lisp 
> >>with bindings similar to Elisp.
> >
> >
> >Well, it should be easy to write one, at least one which would parse and
> >use the incriminating files.
> 
> That creation after the fact does not change whether the elisp file was 
> created as a derivative work of Emacs.

Yeah, and ? As long as we don't distribute linked stuff it should be ok.

> >>So I think talking to the upstream is a good idea.
> >
> >Sure, but on more serious ground than this. Notice that the bugreport
> >claims that RMS thinks that ..., not that it is actually true.
> 
> Ok.  So, for the sake of argument, assume he's dead wrong, but thinks so
> nonetheless.  We should still, imho, behave as if he's correct, given
> that he/FSF owns copyright on emacs.  This is what we normally do: give
> the copyright holder generous (and sometimes unreasonable) benefit of
> the doubt in terms of what rights they have and can enforce.  Deciding
> what to do here doesn't involve taking a position on whether RMS is
> right or wrong (thank god!).
> >>>
> >>>
> >>>Well, sure, but this would not help me convince upstream.
> >>
> >>Do you really think the upstream authors are so rude?
> >
> >What has that to do with anything ? Look how silly this argument sounds ? 
> >
> >Imagine me telling the upstream author that he should please change the
> >licence of his files, because RMS may feel offended ? Be serious please.
> >
> >This is debian-legal, not debian-please-stay-polite.
> 
> I think it's taken for granted that Debian will try to be polite. 

Oh, come on, let's have a good laugh together. I have not known a more
rude bunch of people than the debian developers. I expect everything
from debian, but politeness is not one of those. And the current
tentative to remove non-free as a threat to upstream authors is
definitively not one on the side of politeness or respect.

> Requests for change are much nicer than threats of legal action.  We 
> don't need a clear threat of a lawsuit to act -- a polite request is 
> enough.  Such is true of most polite people, isn't it?

Yeah, but you have to notice that this is not only a mere change of
licence, it is a request for the upstream author to give away more of
its right to the code he wrote. And also, it may have been