headers
Frank Küster | 1 Oct 2006 15:38
Picon

Re: New auctex version coming, and the freeze

David Kastrup <dak <at> gnu.org> wrote:

> Frank Küster <frank <at> kuesterei.ch> writes:
>
>> David Kastrup <dak <at> gnu.org> wrote:
>>
>> But only under the assumption that Debian, the FSF and everybody
>> else who uses that license does read it as the FSF intended it, not
>> as it is written.
>
> The invariant sections are an explicit optional provision.  The BSD
> license has a lot more implicit possibilities of turning material
> unfree.

The invariant sections are not the problem.  They are the problem for
inclusion in Debian main, but even without them the GFDL is a badly
written license which is non-free when interpreted by the letter.  This
is the reason why I do not want to contribute to such a document, not
the fact that due to some political hassles between the FSF and Debian
the document would be outside of Debian.

>> Although that's the outcome of the Debian vote, it's still logically
>> flawed.  And I still do not want my work to be licensed under the
>> current GFDL.
>
> Let's face it: the GPL is unsuitable for a manual.  You can't hand
> somebody a copy on paper without handing him a written offer for the
> source code of it (for three years) and/or handing him the source code
> on a machine readable medium.
(Continue reading)

Permalink | Reply | 22 comments |
headers
David Kastrup | 1 Oct 2006 21:48
Picon
Picon

Re: New auctex version coming, and the freeze

Frank Küster <frank <at> kuesterei.ch> writes:

> David Kastrup <dak <at> gnu.org> wrote:
>
>> Frank Küster <frank <at> kuesterei.ch> writes:
>
>>> Although that's the outcome of the Debian vote, it's still logically
>>> flawed.  And I still do not want my work to be licensed under the
>>> current GFDL.
>>
>> Let's face it: the GPL is unsuitable for a manual.  You can't hand
>> somebody a copy on paper without handing him a written offer for
>> the source code of it (for three years) and/or handing him the
>> source code on a machine readable medium.
>
> The GFDL is also unsuitable for a manual.  When you hand out more
> than 100 copies, you must also provide the source code online for
> (for one year instead of three, well) or include the source code in
> machine-readable form.

Frank, that's a red herring.  You wanted to fork the manual under the
GPL, and there you need to include the source code for every single
hardcopy.  It is not even clear with the GPL what the act of printing
produces: a derived work or a modification?

> Moreover, it has a number of other serious flaws, as e.g. outlined
> in http://people.debian.org/~srivasta/Position_Statement.xhtml.  The
> FSF has more or less clearly (sometimes in fact less) stated that
> they intend to interpret these clauses in a free, DFSG-compliant way
> for the documents they publish.  But that doesn't guarantee that
(Continue reading)

Permalink | Reply | 17 comments |
headers
Reiner Steib | 2 Oct 2006 00:44
X-Face

Re: New auctex version coming, and the freeze

On Sun, Oct 01 2006, David Kastrup wrote:

> Frank Küster <frank <at> kuesterei.ch> writes:
>> I assumed that the problems where known to the team (I didn't have
>> time to follow the list in the last months), and therefore just
>> wanted to ask whether the bad feelings about the GFDL are general
>> enough to do something about that as a team.  Now I got the
>> impression that you haven't discussed the license so far, and Ralf's
>> mail seems to imply that there's interest in doing that.

FWIW, I don't have bad feelings about the GFDL, but I do have strong
bad feelings when someone starts to talk about "forking the manual".

> If there was consensus on the list that I am not doing a good job as a
> GNU project maintainer, or that AUCTeX should try to cease being a GNU
> project, I would be willing to pass the buck of maintenance to anybody
> with the majority of support of the list members, as long as he can
> guarantee all the infrastructure and support AUCTeX needs to continue.
[...]

I support your position.  I want AUCTeX do be a GNU project and I hope
we will be able to include it in Emacs some day.

Bye, Reiner.
--

-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
Permalink | Reply | 0 comments |
headers
Reiner Steib | 2 Oct 2006 00:50
X-Face

Re: New auctex version coming, and the freeze

On Sun, Oct 01 2006, Frank Küster wrote:

[...]
> http://people.debian.org/~srivasta/Position_Statement.xhtml.
> The FSF has more or less clearly (sometimes in fact less) stated
> that they intend to interpret these clauses in a free,
> DFSG-compliant way for the documents they publish.  But that doesn't
> guarantee that other copyright holders who use the license do the
> same, and in fact it can't guarantee that the FSF will continue to
> do so.

Could you please explain this paragraph in more detail?

Bye, Reiner.
--

-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
Permalink | Reply | 3 comments |
headers
Frank Küster | 2 Oct 2006 08:58
Picon

Re: Re: New auctex version coming, and the freeze

Reiner Steib <reinersteib+gmane <at> imap.cc> wrote:

> On Sun, Oct 01 2006, Frank Küster wrote:
>
> [...]
>> http://people.debian.org/~srivasta/Position_Statement.xhtml.
>> The FSF has more or less clearly (sometimes in fact less) stated
>> that they intend to interpret these clauses in a free,
>> DFSG-compliant way for the documents they publish.  But that doesn't
>> guarantee that other copyright holders who use the license do the
>> same, and in fact it can't guarantee that the FSF will continue to
>> do so.
>
> Could you please explain this paragraph in more detail?

Well, I'm not sure whether you are asking about what could be interpreted
as non-free, and how the FSF has promised to interpret instead, or
whether you want to know about the problem with other copyright
holders.  

As for the first issue, one particularly problematic point is the overly
broad anti-DRM clause.  FSF representatives have said that they would
not try to sue anybody for, for example, including a filesystem with a
GFDL'ed manual on it in a backup that gets protected by a password.  I'm
not sure what they said about the problem of including such a manual on
a medium that is meant to be used on a hardware that only accepts
DRM-protected media, if at the same time you also provide a non-DRM
protected medium with the same content.

As for the second issue:  The FSF also recommends the GFDL as a
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Küster | 2 Oct 2006 09:02
Picon

Re: New auctex version coming, and the freeze

David Kastrup <dak <at> gnu.org> wrote:

> Frank Küster <frank <at> kuesterei.ch> writes:
>
>> David Kastrup <dak <at> gnu.org> wrote:
>>
>>> Let's face it: the GPL is unsuitable for a manual.  You can't hand
>>> somebody a copy on paper without handing him a written offer for
>>> the source code of it (for three years) and/or handing him the
>>> source code on a machine readable medium.
>>
>> The GFDL is also unsuitable for a manual.  When you hand out more
>> than 100 copies, you must also provide the source code online for
>> (for one year instead of three, well) or include the source code in
>> machine-readable form.
>
> Frank, that's a red herring.  You wanted to fork the manual under the
> GPL, and there you need to include the source code for every single
> hardcopy.  It is not even clear with the GPL what the act of printing
> produces: a derived work or a modification?

This is right.  I was very superficially when I said about using the
"last GPL'ed" manual.  But in fact I just remembered that previously I
checked and found that it has a suitable license.  Which it indeed still
has in the released version, there's nothing in it that requires passing
on source code with printed versions (this is suboptimal, since it's an
incomplete copyleft, but at least it is consistent).

>> Moreover, it has a number of other serious flaws, as e.g. outlined
>> in http://people.debian.org/~srivasta/Position_Statement.xhtml.  The
(Continue reading)

Permalink | Reply | 9 comments |
headers
David Kastrup | 2 Oct 2006 11:04
Picon
Picon

Re: New auctex version coming, and the freeze

Frank Küster <frank <at> kuesterei.ch> writes:

> David Kastrup <dak <at> gnu.org> wrote:
>
>> Frank Küster <frank <at> kuesterei.ch> writes:
>
>>> Moreover, it has a number of other serious flaws, as e.g. outlined
>>> in http://people.debian.org/~srivasta/Position_Statement.xhtml.
>>> The FSF has more or less clearly (sometimes in fact less) stated
>>> that they intend to interpret these clauses in a free,
>>> DFSG-compliant way for the documents they publish.  But that
>>> doesn't guarantee that other copyright holders who use the license
>>> do the same, and in fact it can't guarantee that the FSF will
>>> continue to do so.
>>
>> Frank, PLEASE, PLEASE, PLEASE bring this up and explain this in the
>> feedback for the new GFDL drafts.
>
> This is completely unnecessary.  The FSF has known these concerns
> for years.

As I said: the FSF does not move fast, and they don't have the
personnel for doing so.  The GPLv3 process has taken a lot of focus
and energy lately.

> Representatives have told repeatedly that they are going to fix it,
> but nothing has happened except that once or twice RMS has said they
> won't fix anything.  And more skilled people like me will for sure
> bring this up again.  Debian even has formal delegates for that.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Stephan Hennig | 2 Oct 2006 11:06
Picon
Favicon

Re: rfe: dtk.cls support

Ralf Angeli schrieb:
> * Stephan Hennig (2006-09-30) writes:
> 
>> C-h v TeX-macro-global RET
>> C-h a TeX-macro-global RET
>> C-h d TeX-macro-global RET
>>
>> all return no matches.
> 
> Try it after you loaded a LaTeX file.

Thanks!

C-h v TeX-macro-global RET

now works.

Best regards,
Stephan Hennig
Permalink | Reply | 0 comments |
headers
Stephan Hennig | 2 Oct 2006 11:29
Picon
Favicon

Re: rfe: dtk.cls support

Ralf Angeli schrieb:
> * Stephan Hennig (2006-09-30) writes:
> 
>>> AUCTeX calls kpsewhich to figure this out. You can check it by
>>> executing
>>> kpsewhich --progname latex --expand-path "$TEXMFLOCAL"
>>> in a Windows prompt.
>>
>> That call fails even if I set TEXMFLOCAL:
>>
>> H:\home>set TEXMFLOCAL
>> TEXMFLOCAL=d:/localtexmf
>>
>> H:\home>kpsewhich --progname latex --expand-path "$TEXMFLOCAL"
>> C:/Dokumente und Einstellungen/All Users/Anwendungsdaten/MiKTeX/2.5
>>
>> H:\home>
> 
> It doesn't fail.  On the contrary.  It succeeds and shows you were the
> TEXMFLOCAL tree is located.

If that succeeded, I cannot see any option to change TEXMFLOCAL within
MiKTeX.  Neither is there any mention of TEXMFLOCAL in the documentation
nor did I find a configuration file containing the string TEXMFLOCAL.
Especially non that set it to "C:/Dokumente und Einstellungen/All
Users/Anwendungsdaten/MiKTeX/2.5".  Of course I can see that path in
"MiKTeX Options".  But there are no means to register single texmf trees
as local or global.  For that reason I wonder that your call returns
just the above mentioned path.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Küster | 2 Oct 2006 12:17
Picon

Re: New auctex version coming, and the freeze

Hi, 

I suggest to stop this, or take it off-list, since it doesn't seem to be
relevant for auctex development any more (and for a while already, I
think). 

David Kastrup <dak <at> gnu.org> wrote:

>> This is completely unnecessary.  The FSF has known these concerns
>> for years.
>
> As I said: the FSF does not move fast, and they don't have the
> personnel for doing so.  The GPLv3 process has taken a lot of focus
> and energy lately.

And was regarded to be more important than fixing an existing license
with serious flaws.

>> Representatives have told repeatedly that they are going to fix it,
>> but nothing has happened except that once or twice RMS has said they
>> won't fix anything.  And more skilled people like me will for sure
>> bring this up again.  Debian even has formal delegates for that.
>
> You don't want to have something like "this clause was opposed just by
> three developers, so we decided the concerns did not justify further
> work".  Without your input, you don't have a reason to complain.

If the FSF thinks that input by the official delegates of the Debian
project, formally speaking for around 1000 developers, people who are
well-informed and know how to talk about legal problems, does "not
(Continue reading)

Permalink | Reply | 3 comments |

Gmane