Re: OFL license analysis

[Frank Küster]

Mark Rafn <[EMAIL PROTECTED]> wrote:

>> Mark Rafn <[EMAIL PROTECTED]> wrote:
>>> This discussion seems to have gone into the weeds about WHY someone
>>> would want to make a change and whether Debian is able to make such
>>> changes reasonably.
>
> On Mon, 30 Jan 2006, Frank Küster wrote:
>> Well, only in part.  A font that you can't rely on is mostly useless...
>
> I assume the "you" in this sentence is a hapless user of a system
> whose software she does not control/understand, not the person wishing
> to make and distribute changes to the font.  Correct me if this is an
> incorrect reading.

ACK.

> A license that tries to protect a user from an incompetent
> developer/distributor/sysadmin is going to be non-free.  There's
> really no way around this.  The only way to be free is to allow a true
> fork of the software, which means a dropin replacement, even if the
> licensor disapproves.

Most existing forks *do* identify themselves as being something
different.  

>>> What ever happenened to the LaTex license, by the way?  That had the
>>> same non-freeness.
>>
>> You seem to have a different opinion on this as the debian-legal people
>> who negotiated with the LaTeX project and together developped the LPPL
>> version 1.3.  In this version, the requirement to change file names (or
>> LaTeX package names) was dropped, probably because it was regarded as
>> "too non-free", whereas it was decided that any changed version should
>> indicate that it was changed in the version string that is (or to some
>> degree only will be) part of the API.
>
> Hmm.  I claim that it is a mistake for Debian to consider something
> free if it requires binary incompatibility to distribute a modified
> version. Version strings are a funny edge-case, where if they're
> normally just human-readable information with no programmatic effect I
> can live with it, but when it becomes common to programmatically read
> them and behave differently, then it's part of the API and must be
> modifiable (or not) without restriction.

The revised LPPL says:

  a. If a component of this Derived Work can be a direct replacement
 for a component of the Work when that component is used with the
 Base Interpreter, then, wherever this component of the Work
 identifies itself to the user when used interactively with that
 Base Interpreter, the replacement component of this Derived Work
 clearly and unambiguously identifies itself as a modified version
 of this component to the user when used interactively with that
 Base Interpreter

In practice, this means that the version string displayed in the file
log of a LaTeX run will be different, and that the user, or a developer
of a package that uses "the work", has the possibility to check for the
version and act accordingly; it does of course not mean that he must do
such a check.

> It's possible that Debian made a mistake if that's what LaTeX does
> with these strings.  Wouldn't be the first time.

I guess before we continue discussing this, we both should look up in
the archives the discussion that has taken place between the LaTeX team
and Debian people.

>>> It seems a clear test: if I can't distribute a changed version that
>>> can be dropped into a system without changing other software,
>>> it ain't free.
>
>> You can never distribute a bugfixed version of a font with the same name
>> (identifiers, ...) and, without changing other software, get the same
>> system behavior.  That's not a question of freeness, it's a technical
>> problem.
>
> No, the intent is to get DIFFERENT system behavior by changing the
> free component, without changing other software or documents.  That's
> the freedom I'm worried about here.  Though the ability to get the
> same behavior is there too (perhaps a performance fix or other
> result-compatible implementation change), it's just a special case of
> the real freedom to make changes.

I know, the freedom to shoot yourself into the foot.  But I think it's
not unreasonable to require that the user is at least notified what
happened, and that can only be done by changing the identifier in an
interactive dialog, or by issuing font substitution warnings in a batch
run. 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: OFL license analysis

[Mark Rafn]

On Tue, 31 Jan 2006, Frank Küster wrote:

In practice, this means that the version string displayed in the file
log of a LaTeX run will be different, and that the user, or a developer
of a package that uses "the work", has the possibility to check for the
version and act accordingly; it does of course not mean that he must do
such a check.


Ok, that seems reasonable to me.  Much like the human-readable version 
info when running a program with -v or whatnot.


A human can tell the difference if he bothers to look.  System software 
does not change behavior based on this human identification.



I know, the freedom to shoot yourself into the foot.  But I think it's
not unreasonable to require that the user is at least notified what
happened, and that can only be done by changing the identifier in an
interactive dialog, or by issuing font substitution warnings in a batch
run.


I think our disagreement is that you think the licensor may require the 
software to actively notify some user, where I think the licensor may 
require that it be identifiable if the recipient of the software package 
cares to look for such identification.  Is this a fair summary?


I can see no way to force notification in most systems that does not 
interfere with the fundamental freedom to make changes.

--
Mark Rafn[EMAIL PROTECTED]

Re: OFL license analysis

[Frank Küster]

Frank Küster <[EMAIL PROTECTED]> wrote:

> In practice, this means that the version string displayed in the file
> log of a LaTeX run will be different, and that the user, or a developer
> of a package that uses "the work", has the possibility to check for the
> version and act accordingly; it does of course not mean that he must do
> such a check.

Also note that due to the way TeX works this can, in principle, be done
even without that.  If you think your document should only be processed
with an unchanged version of foo.sty, you can look at every macro
provided *and*used*internally* by foo.sty and check whether it has been
changed.  Having the version number available is just more convenient...

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: OFL license analysis

[Glenn Maynard]

On Tue, Jan 31, 2006 at 01:15:06AM -0800, Mark Rafn wrote:
> A human can tell the difference if he bothers to look.  System software 
> does not change behavior based on this human identification.

Well, it might: if the software uses the "human identification" to select
which font to use when rendering a document, it's no longer merely
human identification--it's functional, too.

That raises an odd (tangental) question, though.  What if third-party
software scanned output intended for the user; for example, refusing to
run or changing behavior if the name of the software it prints isn't
"foo"?  Now it's impossible to make a functional drop-in equivalent
without identifying differently.  Same problem with any number of things
required under the assumption that they're not functional: you could
scan "strings" output for "(c) Glenn Maynard" if you don't like my code,
or refuse to run if the GPL blurb is detected if you want to hinder GPL
software.

In practice, the only reasonable approach is probably intent.  It's
pretty clear that font licensors actually do want to prohibit me from
modifying a font, distributing it, and having it drop-in over the
original.  That's a non-free goal.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: License for ATI driver documentation

[Daniel Leidert]

Am Montag, den 30.01.2006, 13:43 -0800 schrieb Walter Landry:
> Daniel Leidert <[EMAIL PROTECTED]> wrote:

[documentation license]
> > Ok. Here my suggestion:
> > 
> > /--
> > > Copyright (C) 
> > > [..]
> > \--
> > 
> > I included your suggestions and changed "documentation" to "software" in
> > item 3.) of the conditions list. Better?
> 
> Better.  The no-warranty clause should also say "software" instead of
> "documentation".  Otherwise, I think you're good to go.

Done. The latest is
http://cvs.wgdd.de/cgi-bin/cvsweb/fglrx_man/COPYING?rev=1.5.

May I ask one further question? I want to release the autogen.sh script,
the Makefile and configure script and the other stuff without any
limitation. The macros itself are licensed under a all-permissive
license (inspired by the autoconf-archive package). Is this
all-permissive license

/-
> Copying and distribution of this file, with or without modification,
> are permitted in any medium without royalty provided the copyright
> notice and this notice are preserved.
\-

ok for Makefile(s), configure scripts, ...? Or is it better to release
them into public domain? I don't think, that I should claim any rights
on them.

Regards, Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Adobe open source license -- is this licence free?

[Raul Miller]

On 1/30/06, Walter Landry <[EMAIL PROTECTED]> wrote:
> Doesn't this cause problems when the code is forked?  If someone in
> France forks the code, then they have to travel to Scotland to defend
> themselves against any frivolous lawsuits.  That allows the original
> licensors a bit more control over the code than might be desired.

This is a real issue, and I would not have any problem asking the
folks at Adobe if they could clean up the way the license addresses
this case.

But I think we should also come up with one or more somewhat
plausible suggestions, to give an idea of what we're looking for.

As a rough first cut, perhaps:

  "Any dispute naming Adobe as a defendant, arising out of or
   related to this Agreement shall be brought in the courts of Santa
   Clara County, California, USA."

(I don't think this creates any unusual advantage for Adobe
because authors of derivative works can impose a similar
requirement on their work.)

--
Raul

Re: License for ATI driver documentation

[Walter Landry]

Daniel Leidert <[EMAIL PROTECTED]> wrote:
> Am Montag, den 30.01.2006, 13:43 -0800 schrieb Walter Landry:
> > Daniel Leidert <[EMAIL PROTECTED]> wrote:
> 
> [documentation license]
> > > Ok. Here my suggestion:
> > > 
> > > /--
> > > > Copyright (C) 
> > > > [..]
> > > \--
> > > 
> > > I included your suggestions and changed "documentation" to "software" in
> > > item 3.) of the conditions list. Better?
> > 
> > Better.  The no-warranty clause should also say "software" instead of
> > "documentation".  Otherwise, I think you're good to go.
> 
> Done. The latest is
> http://cvs.wgdd.de/cgi-bin/cvsweb/fglrx_man/COPYING?rev=1.5.

Looks good.

> May I ask one further question? I want to release the autogen.sh script,
> the Makefile and configure script and the other stuff without any
> limitation. The macros itself are licensed under a all-permissive
> license (inspired by the autoconf-archive package). Is this
> all-permissive license
> 
> /-
> > Copying and distribution of this file, with or without modification,
> > are permitted in any medium without royalty provided the copyright
> > notice and this notice are preserved.
> \-
> 
> ok for Makefile(s), configure scripts, ...? Or is it better to release
> them into public domain? I don't think, that I should claim any rights
> on them.

This license is good.  It turns out that it is difficult to really
release things into the public domain in some countries, so an
explicit license is better.

Cheers,
Walter Landry
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Trademark policy for packages?

[Simon Josefsson]

Hi!  This was intended for debian-mentors, but since it is a legal
issue, I thought it would be more appropriate here.

I'm packaging Shishi, a Kerberos implementation, for Debian.  The term
"Kerberos" is a trademark held by MIT, according to RFC 1510:

   Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos,
   Moira, and Zephyr are trademarks of the Massachusetts Institute of
   Technology (MIT).  No commercial use of these trademarks may be
   made without prior written permission of MIT.

The trademark is registered with USPTO:

http://tess2.uspto.gov/bin/showfield?f=doc&state=case6n.2.2

I am familiar with the GNU policies on trademark, and I am trying to
adhere to them when possible.

My question is: What is Debian's policy on trademarks for terms used
in documentation and package descriptions?  Do Debian require that
certain usages of a trademarked terms is permitted to be included in
Debian?

I have established a contact with the MIT Technology Licensing Office,
and while I have a basic answer permitting me the usage permitted by
law, I'm wondering if there are particular permissions that would be
useful to request as far as Debian is concerned.

Further, in this case, the "Kerberos" trademark is marked as DEAD with
the USPTO.  There is an explanation of what it means at:

http://tess2.uspto.gov/bin/gate.exe?f=help&state=case6n.2.2#FAQ_DEAD

But I don't understand the legal consequences of that.  If anyone here
know more what this means, I'd be interested.  Specifically, can the
MIT continue to claim rights to the trademark when it is DEAD?

Thanks,
Simon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Trademark policy for packages?

[Glenn Maynard]

On Tue, Jan 31, 2006 at 11:28:54PM +0100, Simon Josefsson wrote:
>Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos,
>Moira, and Zephyr are trademarks of the Massachusetts Institute of
>Technology (MIT).  No commercial use of these trademarks may be
>made without prior written permission of MIT.
> 
> The trademark is registered with USPTO:
> 
> http://tess2.uspto.gov/bin/showfield?f=doc&state=case6n.2.2
> 
> I am familiar with the GNU policies on trademark, and I am trying to
> adhere to them when possible.
> 
> My question is: What is Debian's policy on trademarks for terms used
> in documentation and package descriptions?  Do Debian require that
> certain usages of a trademarked terms is permitted to be included in
> Debian?

I'm not sure what Debian's policies are; since trademark only infrequently
comes up, I have a feeling they're a still bit unformed.  This is just my
impression of where things are today.

Past discussions have come to the conclusion, I think, that a trademark
license can't grant what Debian would require of a copyright license.  That's
because a license to use a trademark freely, in any way, would be equivalent
to abandoning it completely.  If Coke says "you can use Coke(tm) to refer to
anything, even Pepsi or ice coffee", they'd essentially be relinquishing
their trademark completely.

But, unlike copyright licenses, you can always escape a trademark license
by not using it, and doing so doesn't prevent you from using the actual work.
Debian even allows licenses to require that (DFSG#4).  I'm not sure exactly
where Debian should draw the line between a trademark license that should be
preemptively escaped (by renaming the work upon packaging), and one that can
be left.

A trademark license that says "you must pass our test suite before you're
allowed to distribute anything with our trademark" would obviously be
among the former: Debian would simply not use the trademark.  On the other
side, Debian uses lots of trademarks, such as "Linux", which are enforced,
but under more lenient terms.

I'm not sure about "no commercial use of these trademarks".  People sell
Debian CDs all the time, and I don't know if that qualifies.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Trademark policy for packages?

[Henning Makholm]

Scripsit Simon Josefsson <[EMAIL PROTECTED]>

> I'm packaging Shishi, a Kerberos implementation, for Debian.  The term
> "Kerberos" is a trademark held by MIT, according to RFC 1510:
...
> My question is: What is Debian's policy on trademarks for terms used
> in documentation and package descriptions?  Do Debian require that
> certain usages of a trademarked terms is permitted to be included in
> Debian?

Does the use of a trademark word to refer unambiguously to a specific
technical protocol in package descriptions and documentation (that is,
not in marketing materials) even require a trademark license? I know
that it certainly does not in Denmark, but of course that does not say
anything about the rest of the world.

-- 
Henning Makholm"I have seen men with a *fraction* of
 your trauma pray to their deity for death's
 release. And when death doesn't arrive immediately,
   they reject their deity and begin to beg to another."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GR proposal: GFDL with no Invariant Sections is free

[Francesco Poli]

On Mon, 30 Jan 2006 21:45:25 -0500 Glenn Maynard wrote:

> On Tue, Jan 31, 2006 at 12:52:00PM +1100, Andrew Donnellan wrote:
[...]
> > Let's face it: Debian wouldn't exist without the FSF.
> 
> Maybe not.  Neither would a lot of other things.  That's a strawman
> that doesn't change where things are today.  The FSF deserves respect
> for their part in getting us here, but not so much that they're exempt
> from critical review.

Exactly.
The FSF has the great merit of having built the free software community.
RMS was the first to formalize the "free software" concept.
The GNU is a very important part of today's free software code base.

But nowadays, the FSF leadership seems to play the "let's restrict it a
bit more" game, driving the community farther and farther away from the
original "free software" concept...   :-(

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpA0Hdk3FoV4.pgp
Description: PGP signature

Re: Trademark policy for packages?

[MJ Ray]

Henning Makholm
> Does the use of a trademark word to refer unambiguously to a specific
> technical protocol in package descriptions and documentation (that is,
> not in marketing materials) even require a trademark license? I know
> that it certainly does not in Denmark, but of course that does not say
> anything about the rest of the world.

I'm pretty sure that it doesn't in England either and I'd expect it to
be across the EU. http://www.iusmentis.com/trademarks/crashcourse/rights/

Out of context, that quote from RFC 1510 looks just plain wrong, but
I can see why the holder would want it to be believed.

In general, I suggest not inappropriately acknow(tm)ledging trademarks,
but trying to use any marks honestly and accurately anyway, whether they
are registered or not. The only time they should be a problem is when a
copyright holder tries for a SuperTrademark through bad copyright terms.

In particular, I can't recall exactly what DEAD means for USPTO. I'd
expect it to be difficult to enforce.

-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]