date:20060314

Glenn Maynard [EMAIL PROTECTED]
 
 On Tue, Mar 14, 2006 at 01:09:43AM +, MJ Ray wrote:
  The practical problems beyond the DFSG have always been something
  we commented in, but not a direct freedom problem themselves.  The
  FSF used to do this too - see their criticism of obnoxious
  advertising clauses - instead of using advertising clauses like now.
 
 Free Software goals exist for real, practical reasons.  Practical problems
 *are* freedom problems. [...]

Often. Not all of them are. I think there are some of each sort in FDL.

  More pragmatically, DFSG-free was a stupid label for
  licences which helped add to the confusion over whether it was the
  licence or the liberty of the software and users that mattered to us.
 
 The license is--largely[1]--what *determines* the liberty of the software
 and its users.  The liberty is the important end result, but it's the
 licenses that get us there; restrictions placed by licenses (or lack of
 licenses) is what obstructs that liberty.  DFSG-free is not a stupid
 label; it was an effective, useful one.

Not a stupid label in general, but a stupid label for licences. There's
always a UW.  Using the DFSG as some sort of licence certification
scheme is a really bad idea and organisations that try to do so should
die messily. Please let's concentrate on the software: it's worth looking
at licences, but software is the thing of interest.

-- 
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]

Re: Results for Debian's Position on the GFDL

On Tue, Mar 14, 2006 at 08:46:16AM +0100, Florian Weimer wrote:
  It requires preserving any section titled History, required adding
  it if it's not there, and requires adding stuff to it.
 
 I agree that this is quite annoying, but the GPL has similar
 requirements, although the community at large does not comply with
 them.

The GPL does not require that the information be preserved in any way.

-- 
Glenn Maynard


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

Re: Results for Debian's Position on the GFDL

On Tue, Mar 14, 2006 at 10:28:06AM +, MJ Ray wrote:
 Not a stupid label in general, but a stupid label for licences. There's
 always a UW.  Using the DFSG as some sort of licence certification
 scheme is a really bad idea and organisations that try to do so should
 die messily. Please let's concentrate on the software: it's worth looking
 at licences, but software is the thing of interest.

I disagree.  d-legal should concentrate on the licenses.  The software
it's applied to is very rarely relevant to the freeness question; it's
the license that makes the software free or not.  Copyright holders,
can create the unusual situation of a work being free or not free in
disagreement with the license on its own, due to statements of intent--but
that's the rare exception, and rarely a good situation (say what you mean
in the license to begin with).

I'm not sure what you're suggesting.  Maybe I'll understand if you relate
this back to the original topic.  I don't believe a document placed under
the GFDL, with no invariant sections, is free.  You can look at it from
the license, or by taking document under the GFDL and looking at the
resulting freedoms, and the conclusion doesn't change.

-- 
Glenn Maynard


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

Re: Results for Debian's Position on the GFDL

Glenn Maynard [EMAIL PROTECTED]
 
 On Tue, Mar 14, 2006 at 10:28:06AM +, MJ Ray wrote:
  Not a stupid label in general, but a stupid label for licences. [...]
  Please let's concentrate on the software: it's worth looking
  at licences, but software is the thing of interest.
 
 [...] Copyright holders,
 can create the unusual situation of a work being free or not free in
 disagreement with the license on its own, due to statements of intent--but
 that's the rare exception, and rarely a good situation (say what you mean
 in the license to begin with).

I think we have seen too many check each case licences to call it rare.
There are also some licences which make software non-free if some of their
options are exercised.

 I'm not sure what you're suggesting.  Maybe I'll understand if you relate
 this back to the original topic.  I don't believe a document placed under
 the GFDL, with no invariant sections, is free. [...]

I don't believe calling something abstractly free is helpful,
nor calling a *licence* rather than a work DFSG-free. At worst, the
ambiguity of that jargon is unhelpful when discussing this with the rest
of the world.

-- 
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]

Is the GUST-FONT-NOSOURCE-LICENSE free?

2006-03-14 Thread Frank Küster

Hi,

this is an earnest question, the NOSOURCE in the name is misleading.
The license can be found at

ftp://tug.ctan.org/pub/tex-archive/fonts/antt/doc/fonts/antt/GUST-FONT-NOSOURCE-LICENSE.txt

and is quite short:

%%% This is a preliminary version, barring acceptance from the LaTeX
%%% Project Team and other feedback, of the GUST Font Nosource License.
%%% This licence is for use with free fonts distributed without source code,
%%% e.g., fonts created with visual tools.
%%%
%%% For the most recent version of this license see
%%% http://www.gust.org.pl/fonts/licenses/GUST-FONT-NOSOURCE-LICENSE.txt or
%%% http://tug.org/fonts/licenses/GUST-FONT-NOSOURCE-LICENSE.txt
%
% This work may be distributed and/or modified under the
% conditions of the LaTeX Project Public License, either version 1.3a
% of this license or (at your option) any later version provided that
% the following additional clauses will be observed:
%
% 1) As there is no universally relevant concept of source files,
%no distinction is made between Work and Compiled Work;
%hence, the relevant clauses of the
%LaTeX Project Public License should be interpreted accordingly.
% 2) Due to the nature of fonts, clause 6a of the LaTeX Project
%Public License, version 1.3a, does not apply. A later version of
%the LaTeX Project Public License may number or word this clause
%differently; it is the substance that is important.
% 3) It is requested, but not legally required, that derived works be
%distributed only after changing the names of the fonts comprising
%this work and given in the accompanying file MANIFEST.txt, and that
%the files comprising the Work, as listed in MANIFEST.txt also be
%given new names. Any exceptions to this request are also
%given in MANIFEST.txt.
%
% The latest version of the LaTeX Project Public License is in
% http://www.latex-project.org/lppl.txt
% and version 1.3a or later is part of all distributions of LaTeX
% version 2004/10/01 or later.

LPPL clause 6a is just a restriction in LPPL, which is waved for works
under the GUST... license, therefore the license is basically the same
as LPPL granting some additional rights.

Except for the source issue. The concrete example, as you might have
guessed, are the ANTP fonts, which are available as PostScript Type1,
TrueType and OpenType fonts.

I have heard a talk of the author, Janusz Nowacki, last week at the
DANTE meeting, and I got the impression that in fact he uses FontForge
or a similar editor, and doesn't use its scripting facilities (much).

I'll ask him again, but it seems to me that in this case the PostScript
Outlines are in fact the preferred form of modification for the author,
and I see no reason not to accept this as source in the sense of the
DFSG, since there doesn't seem to be anything better. Consequently, the
fonts would be free.

What do you think?

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

Re: Is the GUST-FONT-NOSOURCE-LICENSE free?

2006-03-14 Thread Joe Smith



Frank Küster [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]




Except for the source issue.  The concrete example, as you might have
guessed, are the ANTP fonts, which are available as PostScript Type1,
TrueType and OpenType fonts.

I have heard a talk of the author, Janusz Nowacki, last week at the
DANTE meeting, and I got the impression that in fact he uses FontForge
or a similar editor, and doesn't use its scripting facilities (much).

I'll ask him again, but it seems to me that in this case the PostScript
Outlines are in fact the preferred form of modification for the author,
and I see no reason not to accept this as source in the sense of the
DFSG, since there doesn't seem to be anything better.  Consequently, the
fonts would be free.

What do you think?


IANAL, IANADD.

It does not matter which is the prefered form of modification as long as it 
is included.
It is not even nessisary to know which form is the preferred form for 
modification if you
are certain that one of them is. Of course in the case of actually editing 
them knowing

which form is the preferred form is quite helpful. :D

If the truetype and opentype versions are generated from the Postscript 
version a makefile or script to update those should be included.
But the licence itself sounds like it meets the DFSG to me. (I'm assuming 
that the LPPL is free, which I think is a pretty safe assumption).


Of course that licence is only really useful in the case of fonts or other 
things where binary is more or less the same as source. (XML files, CSS 
files, and shell scripts are some other examples).





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

How to free GFDL'ed documents with existing Front Cover texts

2006-03-14 Thread Frank Küster

Hi,

assume a document licensed under GFDL, with no invariant sections (and
...) has a front cover text (like A GNU Manual) and a back cover text
(like You have freedom to copy and modify this GNU Manual, like GNU
software.  Copies published by the Free Software Foundation raise funds
for GNU development.).  What should the developers do in order to make
it DFSG-free (and not annoy RMS too much)?

The GFDL says:

,
| If the Document already includes a cover text for the same cover,
| previously added by you or by arrangement made by the same entity you
| are acting on behalf of, you may not add another; but you may replace
| the old one, on explicit permission from the previous publisher that
| added the old one.
| 
| The author(s) and publisher(s) of the Document do not by this License
| give permission to use their names for publicity for or to assert or
| imply endorsement of any Modified Version.
`

Would a statement like If you create a derivative work of this document
which is not part of a GNU project, we hereby permit you to remove the
front cover text.  Since the Free Software Foundation is unlikely to
publish copies of your derivative work, you may also remove the back
cover text.  be helpful?

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

Re: Results for Debian's Position on the GFDL

2006-03-14 Thread Joe Smith



Claus Färber [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]



There are two assumptions here that are wrong:

. US residents can only be sued in US courts.
. US courts can only decide on US copyright law.


Speaking of which, are there any cases in which a US court has made a 
decision based on a non-domestic law (in a situation where that law applied 
and the US law did not)? If there are did the court rule based on precedent 
set by the courts native to that law?



If a US court is deciding a case based on a non-dometic law, and that law is 
from a civil-law country, should the US court rule based on  precident set 
by the courts native to that law despite the fact that those courts do not 
rule based on precident, or should the US court rule based on the written 
law as the courts which are native to the law would?

Claus
--
http://www.faerber.muc.de







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

Re: Results for Debian's Position on the GFDL

On Tue, Mar 14, 2006 at 03:06:58PM -0500, Raul Miller wrote:
 For the DRM issue to be significant, we'd have to have reason to
 believe that a judge would not be familiar with the legal meaning of
 the phrase technical measures in the context of copyright law.
 Other meanings of technical measures would lead to ludicrous
 conclusions (for example: once we've started giving someone a copy we
 must keep spamming copies, never being allowed to stop).

Encrypting a document (whether via GPG or HTTPS) sure seems like a technical
measure to obstruct the reading of copies.

 And the Opaque issue only applies when the transparent copies are not
 distributed.  It's simple enough to include the transparent copies in
 any .deb, and it's simple enough to file an RC bug report against any
 package with GFDL'd content which doesn't include the transparent
 copies.

Maybe I'm misunderstanding the issue you're referring to.  My issue with
the transparent copies bit is that it prohibits converting the document
to, say, a Word document.  The GPL allows it: I can convert it to Word,
and make that my source form (using it for all future modifications,
throwing away the original HTML and all that).  The GFDL prohibits this.
The Transparent copies definition is being used like source in the
GPL, but narrowed to exclude source forms that the FSF doesn't like (even
entirely open formats, if they can't be edited with generic text editors.)

 As for the other issues you call out, I don't think this GR really
 says much about them:  Where these elements are invariant, the
 GR doesn't say anything about GFDL licensed documents which
 contain them.  Where they're not invariant, the restrictions
 imposed are not any more obnoxious than practical restrictions
 on software for non-legal reasons, or practical restrictions on
 patch clause dfsg software.

I think that, prior to this, the patch clause exception was the biggest
blunder in the history of the DFSG: calling software which you're never
allowed to reuse code from Free.  Code reuse is one of the basic goals
of free software.  It's the biggest error not so much because of the
software under these licenses (which are few), but because it's been used
to argue as you have: patch clauses even prohibit putting code in version
control; since we allow that, we should allow all kinds of other onerous
restrictions, too.

I had hoped that this might be fixed some day, but this GR moves things
a couple miles in the other direction and I no longer retain any such hope.

 It's never been clear to me that the Dissident test is a accurate
 reflection of the DFSG.  I can think of many ways for a dissident to

If a dissident is placed in serious danger if his identity is revealed,
I can't think of any way he could work around a license that requires
revealing his identity.

 work around such problems (except for dissidents who more slavishly
 follow their government's suggestions than most non-dissidents -- but
 I don't think that's a serious issue).

I'm not sure what you mean by follow their government's suggestions.
If the license says identify yourself, and identifying myself working
on cryptography software will get me thrown in a dark cell, what
government suggestion am I slavishly following?  Copyright law itself?

The government isn't the operating force in the dissident test, anyhow.
The dissident test is not simply about dissidents and governments; that's
the case used as a test, and for explaining the problem, but the test is
applicable much more generally.  That's why it's a test.

I might work for a company that feels threatened by Free Software, and
doesn't want its employees contributing to it.  (I don't, to be clear; we
actively contribute to free software.)  If I was to spread Free Software,
and was discovered, I might find myself without a job, so I'd do so
anonymously.  The Dissident test deals with the many reasons one might
need to remain anonymous in order to exercise DFSG freedoms.

(If you're thinking about you've probably signed over your copyright
already, then use future employers won't hire you.  Free licenses
shouldn't prohibit anonymity.)

 Maybe none of this is new, but aside from the Opaque and DRM issues,
 none of the proposals or supporting material on vote.debian.org
 indicate that any of these issues are to be taken seriously.

That's the problem: license problems are not being taken seriously.  The
GR casually (and, without another GR, permanently) ignores all of these
issues, saying from now on, every issue you find in the GFDL is to be
ignored, preemptively labelled free, and probably also any freeness
issues are automatically OK if you can find them in the GFDL.  The DFSG
must now be read to allow mandating identifying yourself, making random
section headers invariant, prohibiting converting to formats the author
doesn't like, and so on.

-- 
Glenn Maynard


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

Re: Results for Debian's Position on the GFDL

Raul Miller [EMAIL PROTECTED]
 For the DRM issue to be significant, we'd have to have reason to
 believe that a judge would not be familiar with the legal meaning of
 the phrase technical measures in the context of copyright law.

From the EUCD (2001/29/EC) Article 6 (3), we have in English English:
   the expression technological measures means any technology, device or
   component that, in the normal course of its operation, is designed to
   prevent or restrict acts, in respect of works or other subject-matter,
   which are not authorised by the rightholder of any copyright or any
   right related to copyright as provided for by law or the sui generis
   right provided for in Chapter III of Directive 96/9/EC.

Please explain why this doesn't include file permissions or any of the
other examples previously posted. File permissions seem to be a
technology designed to prevent or restrict unauthorised acts.

[...]
 Maybe none of this is new, but aside from the Opaque and DRM issues,
 none of the proposals or supporting material on vote.debian.org
 indicate that any of these issues are to be taken seriously.

Once we were told FDL's development is none of our business, I think
some of us maybe moved on after collating the most obvious problems.

-- 
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]

Re: better licence for fosdem, debconf, .., videos...

2006-03-14 Thread Francesco Poli

On Mon, 13 Mar 2006 01:45:55 + MJ Ray wrote:

 Francesco Poli [EMAIL PROTECTED] [...]
  It speaks about false attribution: I cannot imagine how stating
  This image is based on the desk image created by Bob could be
  considered as false attribution...
 
 I repeat: I think it depends where and how based on the desk image
 created by Bob is stated.

I can't imagine where or how it could become false: as a matter of fact,
the pornographic image is really based on the desk image created by
Bob...

 
 Further: a lot of emphasis is put on whether you are trying to credit
 Bob with a hand in your work. That is, whether it is a credit.

If it is a credit, it's not an inaccurate or false one, AFAICT.
If it is not a credit, the law doesn't forbid me to state a (true) fact.

Or am I wrong?

 See
 http://www.bailii.org/ew/cases/EWHC/Patents/1998/345.html if you want
 more explanation of both legislation and case law.

I tried to find the time to read that, but miserably failed.
Sorry.

A pretty short summary?

 
 I think it's fair that you can't credit upstream with your derivative
 or collective if they don't want you to.

I'm not so sure: even if the credit is accurate and corresponds to
reality?
As a matter of courtesy, I'm of course ready to purge any credit that
upstream doesn't like.
But is it DFSG-free to *require* me to do so upon request, as a
condition for getting all the permissions granted by the license?

-- 
:-(   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


pgpRPEyAFDpfY.pgp
Description: PGP signature

Re: Results for Debian's Position on the GFDL

On 3/14/06, MJ Ray [EMAIL PROTECTED] wrote:
 Raul Miller [EMAIL PROTECTED]
  For the DRM issue to be significant, we'd have to have reason to
  believe that a judge would not be familiar with the legal meaning of
  the phrase technical measures in the context of copyright law.

 From the EUCD (2001/29/EC) Article 6 (3), we have in English English:
the expression technological measures means any technology, device or
component that, in the normal course of its operation, is designed to
prevent or restrict acts, in respect of works or other subject-matter,
which are not authorised by the rightholder of any copyright or any
right related to copyright as provided for by law or the sui generis
right provided for in Chapter III of Directive 96/9/EC.

 Please explain why this doesn't include file permissions or any of the
 other examples previously posted. File permissions seem to be a
 technology designed to prevent or restrict unauthorised acts.

File permissions have little or nothing to do with enforcing copyright.

File permissions are an all or nothing mechanism.  You either have
given a person a copy of the copyrighted material, or you have not.

Once you've given someone a copy, file permissions are
irrelevant.  The person has a copy and can do whatever they
like with it.

If you've not given someone a copy, file permissions are irrelevant in
the same way that doors, fences, airplanes and cdrom formats are
irrelevant.  All of these (and many other things) can be a part of
the reasons why they have not yet obtained a copy.

Technical measures limit the number of times a work can be played
and/or prevent a person who has a copy from giving that copy to
someone else and/or in some other way enforce the legal rights of
the copyright holder.

  Maybe none of this is new, but aside from the Opaque and DRM issues,
  none of the proposals or supporting material on vote.debian.org
  indicate that any of these issues are to be taken seriously.

 Once we were told FDL's development is none of our business, I think
 some of us maybe moved on after collating the most obvious problems.

That doesn't seem very relevant.

--
Raul

Re: Results for Debian's Position on the GFDL

On 3/14/06, Glenn Maynard [EMAIL PROTECTED] wrote:
 On Tue, Mar 14, 2006 at 03:06:58PM -0500, Raul Miller wrote:
  For the DRM issue to be significant, we'd have to have reason to
  believe that a judge would not be familiar with the legal meaning of
  the phrase technical measures in the context of copyright law.
  Other meanings of technical measures would lead to ludicrous
  conclusions (for example: once we've started giving someone a copy we
  must keep spamming copies, never being allowed to stop).

 Encrypting a document (whether via GPG or HTTPS) sure seems like a technical
 measure to obstruct the reading of copies.

In the general case, this is not a technical measure to enforce the copyright
holder's legal rights on the recipient of the copy.

If the recipient is not allowed to decrypt the document, except under legally
restrictive circumstances, that's a different story.

  And the Opaque issue only applies when the transparent copies are not
  distributed.  It's simple enough to include the transparent copies in
  any .deb, and it's simple enough to file an RC bug report against any
  package with GFDL'd content which doesn't include the transparent
  copies.

 Maybe I'm misunderstanding the issue you're referring to.  My issue with
 the transparent copies bit is that it prohibits converting the document
 to, say, a Word document.

That's allowed.

 The GPL allows it: I can convert it to Word, and make that my source form
 (using it for all future modifications,  throwing away the original HTML and 
 all that).

Not necessarily.

As a counter example: A word document is not the preferred form for working
with .c source code, in the general case.

Of course, in some specific cases a word document might be acceptable.
Likewise, in some specific cases a word document might be transparent.

 I think that, prior to this, the patch clause exception was the biggest
 blunder in the history of the DFSG: calling software which you're never
 allowed to reuse code from Free.

I don't see any votes on this issue.  Perhaps other people in Debian
disagree with you?

 I had hoped that this might be fixed some day, but this GR moves things
 a couple miles in the other direction and I no longer retain any such hope.

Well, it wouldn't just happen by itself.  First you'd need a solid core of
acceptable software to build a distribution on.  Once you have that it's
reasonable to go about organizing the distribution in terms of
how the code can be reused.  Until then, this is a development issue,
not a package management issue.

  It's never been clear to me that the Dissident test is a accurate
  reflection of the DFSG.  I can think of many ways for a dissident to

 If a dissident is placed in serious danger if his identity is revealed,
 I can't think of any way he could work around a license that requires
 revealing his identity.

The dissident can use pseudonyms, proxies, ambiguity, and obscurity.

 I'm not sure what you mean by follow their government's suggestions.
 If the license says identify yourself, and identifying myself working
 on cryptography software will get me thrown in a dark cell, what
 government suggestion am I slavishly following?  Copyright law itself?

The suggestion that you can have only one identity.

  Maybe none of this is new, but aside from the Opaque and DRM issues,
  none of the proposals or supporting material on vote.debian.org
  indicate that any of these issues are to be taken seriously.

 That's the problem: license problems are not being taken seriously.

I think you're overgeneralizing.

--
Raul

Re: Results for Debian's Position on the GFDL

On Tue, Mar 14, 2006 at 07:15:21PM -0500, Raul Miller wrote:
 On 3/14/06, Glenn Maynard [EMAIL PROTECTED] wrote:
  Encrypting a document (whether via GPG or HTTPS) sure seems like a technical
  measure to obstruct the reading of copies.
 
 In the general case, this is not a technical measure to enforce the copyright
 holder's legal rights on the recipient of the copy.

It has many uses; that is one of them.  The same is true of encryption.

 If the recipient is not allowed to decrypt the document, except under legally
 restrictive circumstances, that's a different story.

For what it's worth, I fully agree with trying to disable the legal teeth
of DRM.  That is, I think people should be allowed to use technical measures
to do whatever they want, but I should be legally allowed to circumvent it.
Security-by-encryption is one thing; security-by-jail-time is quite
another.

(I don't think any special attempt to prevent the technical measures
themselves are necessary, since the GPL's source requirements already
did that: an encrypted, locked, unmodifiable copy is not source.)

  The GPL allows it: I can convert it to Word, and make that my source form
  (using it for all future modifications,  throwing away the original HTML 
  and all that).
 
 Not necessarily.
 
 As a counter example: A word document is not the preferred form for working
 with .c source code, in the general case.

You're nitpicking my example, not what I was saying.  The GPL allows it,
for works where Word documents are a plausible preferred form for
modification.  This makes it a reasonable source requirement, ultimately
give me the form which you actually use to make changes to the work.

The transparent copies requirement smells like a source requirement,
but it's more than that: it prohibits changing the source form to a Word
document, even if it's a work where Word is suitable (eg.  not general C
source code), and even if it really is your preferred form for modification.

The GPL doesn't prohibit doing so; it says any form can be source, if it
really is source, but you can't lie and handwave and pretend an obscured
bogus format is source if it's not.  (That's why the GPL does allow Word
as a source format for C code, if the C code is example code in a manual,
while *not* allowing you to hide your changes to the Linux kernel by
distributing the source as a Word document and calling it source when
it's not.)

(Defining source is one thing the GPL did amazingly well at.)

  Maybe I'm misunderstanding the issue you're referring to.  My issue with
  the transparent copies bit is that it prohibits converting the document
  to, say, a Word document.
 
 That's allowed.
...
 Of course, in some specific cases a word document might be acceptable.
 Likewise, in some specific cases a word document might be transparent.

   A Transparent copy of the Document means a machine-readable copy,
   represented in a format whose specification is available to the general
   public, that is suitable for revising the document straightforwardly
   with generic text editors 

You can't revise a Word document with a generic text editor.  I doubt
the format--which, I believe, changes incompatibly with each revision of
Office--is public, either.  The transparent copies definition seems to
very deliberately exclude Word documents, so using Word as your source
format seems to be prohibited.

  I think that, prior to this, the patch clause exception was the biggest
  blunder in the history of the DFSG: calling software which you're never
  allowed to reuse code from Free.
 
 I don't see any votes on this issue.  Perhaps other people in Debian
 disagree with you?

Code reuse is fundamental to Free Software.  I'd find disagreeing with
that to be akin to disagreeing that source availability or permission
to make changes to the work are fundamental--so far from my understanding
that I can't imagine how anyone could hold that view.

That said, my confidence in Debian's concept of freedom has taken a
dive just recently, and I'm much more inclined to agree that Debian
Developers may not consider code reuse important.  (But the same change
in my perception of the opinions of Debian applies to the other core
elements of Free Software.)

  I had hoped that this might be fixed some day, but this GR moves things
  a couple miles in the other direction and I no longer retain any such hope.
 
 Well, it wouldn't just happen by itself.  First you'd need a solid core of
 acceptable software to build a distribution on.  Once you have that it's
 reasonable to go about organizing the distribution in terms of
 how the code can be reused.  Until then, this is a development issue,
 not a package management issue.

I'm sorry, you lost me.  Debian is already a solid core of software without
patch clauses; only a tiny handful of software in Debian have them.  All it
would take to fix this would be to remove those (none of which are critical
to Debian, though--like any software--no doubt some

Re: Results for Debian's Position on the GFDL

On 3/14/06, Glenn Maynard [EMAIL PROTECTED] wrote:
 (I don't think any special attempt to prevent the technical measures
 themselves are necessary, since the GPL's source requirements already
 did that: an encrypted, locked, unmodifiable copy is not source.)

Ok, but the legal right to modify a work does not mean that you have
the practical ability.  More to the point, the GFDL prohibits the use
of technical measures to enforce any of the more obnoxious clauses
of the GFDL.

And, I agree, that's ugly.

   The GPL allows it: I can convert it to Word, and make that my source form
   (using it for all future modifications,  throwing away the original HTML 
   and all that).
 
  Not necessarily.
 
  As a counter example: A word document is not the preferred form for working
  with .c source code, in the general case.

 You're nitpicking my example, not what I was saying.  The GPL allows it,
 for works where Word documents are a plausible preferred form for
 modification.  This makes it a reasonable source requirement, ultimately
 give me the form which you actually use to make changes to the work.
...
A Transparent copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the general
public, that is suitable for revising the document straightforwardly
with generic text editors

 You can't revise a Word document with a generic text editor.  I doubt
 the format--which, I believe, changes incompatibly with each revision of
 Office--is public, either.  The transparent copies definition seems to
 very deliberately exclude Word documents, so using Word as your source
 format seems to be prohibited.

All you need is a broadly available shim -- for example, something to convert
word format to xml and xml back to word, to make it straightforward to
modify the word document in a generic editor.

Of course, no one has built such a thing, and to my knowledge no one plans
to design such a thing.  But it's doable.

As an aside, I edit image files using vi, quite frequently (using it as
a text editor).

Yesterday, for instance, I wanted to document what psuedo-selectors
mean in a cascading style sheet.  CSS doesn't support text output,
but it does support background images.  So I wound up creating a
few hundred labels as images.  A lot of that was done with a script,
but the base image and some of the tests were done using vi as a
generic text editor.

  I don't see any votes on this issue.  Perhaps other people in Debian
  disagree with you?

 Code reuse is fundamental to Free Software.  I'd find disagreeing with
 that to be akin to disagreeing that source availability or permission
 to make changes to the work are fundamental--so far from my understanding
 that I can't imagine how anyone could hold that view.

Nevertheless, Debian has not taken the stand that code in debian package
A must be reusable in debian package B.

No one (you included) has even cared to identify subsets of packages
where this is true.  And we have some fairly broad subsets where code
is re-usable.

   I had hoped that this might be fixed some day, but this GR moves things
   a couple miles in the other direction and I no longer retain any such 
   hope.
 
  Well, it wouldn't just happen by itself.  First you'd need a solid core of
  acceptable software to build a distribution on.  Once you have that it's
  reasonable to go about organizing the distribution in terms of
  how the code can be reused.  Until then, this is a development issue,
  not a package management issue.

 I'm sorry, you lost me.  Debian is already a solid core of software without
 patch clauses; only a tiny handful of software in Debian have them.  All it
 would take to fix this would be to remove those (none of which are critical
 to Debian, though--like any software--no doubt some people find them very
 important) and to have a successful GR to strike the patch exception.  I
 don't expect that to just happen, which is why, from time to time, I raised
 the issue on Debian lists for discussion.

That won't solve all the reusability issues.

   If a dissident is placed in serious danger if his identity is revealed,
   I can't think of any way he could work around a license that requires
   revealing his identity.
 
  The dissident can use pseudonyms, proxies, ambiguity, and obscurity.

 As far as I can tell, the GFDL does not allow using a pseudonym.

Nor does it disallow using a pseudonym.

Both covers must also clearly and legibly identify you as the publisher
of these copies.

 Pseudonyms would not identify me; the very purpose of a pseudonym is to
 not be personally identified.  Ambiguity would also violate this
 requirement.  I'm not sure what you mean by obscurity; use my name,
 and hide in a cave where nobody can find me?  I don't understand
 the proxies example, either.  (If the only way I can redistribute is
 to give it to someone else and ask him to do it for me, then I can't
 redistribute

Re: Results for Debian's Position on the GFDL

Raul Miller [EMAIL PROTECTED]
 On 3/14/06, MJ Ray [EMAIL PROTECTED] wrote:
  From the EUCD (2001/29/EC) Article 6 (3), we have in English English:
 the expression technological measures means any technology, device or
 component that, in the normal course of its operation, is designed to
 prevent or restrict acts, in respect of works or other subject-matter,
 which are not authorised by the rightholder of any copyright or any
 right related to copyright as provided for by law or the sui generis
 right provided for in Chapter III of Directive 96/9/EC.
 
  Please explain why this doesn't include file permissions or any of the
  other examples previously posted. File permissions seem to be a
  technology designed to prevent or restrict unauthorised acts.
 
 File permissions have little or nothing to do with enforcing copyright.
 
 File permissions are an all or nothing mechanism.  You either have
 given a person a copy of the copyrighted material, or you have not.

Thereby, it can prevent unauthorised copying and meets the above
definition, as far as I can see.

[...]
 Technical measures limit the number of times a work can be played
 and/or prevent a person who has a copy from giving that copy to
 someone else and/or in some other way enforce the legal rights of
 the copyright holder.

By preventing unauthorised copying, permissions can enforce the legal
rights of the copyright holder.

The other things you mention are how technological measures are
sometimes used, but that's not how it's phrased in law or in the FDL.

   Maybe none of this is new, but aside from the Opaque and DRM issues,
   none of the proposals or supporting material on vote.debian.org
   indicate that any of these issues are to be taken seriously.
 
  Once we were told FDL's development is none of our business, I think
  some of us maybe moved on after collating the most obvious problems.
 
 That doesn't seem very relevant.

It's one possible reason for other issues not appearing more.

-- 
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]

Re: Results for Debian's Position on the GFDL

On Tue, Mar 14, 2006 at 09:29:40PM -0500, Raul Miller wrote:
 On 3/14/06, Glenn Maynard [EMAIL PROTECTED] wrote:
  (I don't think any special attempt to prevent the technical measures
  themselves are necessary, since the GPL's source requirements already
  did that: an encrypted, locked, unmodifiable copy is not source.)
 
 Ok, but the legal right to modify a work does not mean that you have
 the practical ability.  More to the point, the GFDL prohibits the use
 of technical measures to enforce any of the more obnoxious clauses
 of the GFDL.

I can't think of any way that one could use technical measures to
fulfill the GPL's requirements without providing usable source.  That
is, you can't DRM the the source, since--I'd imagine--nobody can actually
edit the source in that form.  (Or, if you could, then the encryption
keys needed to do so would effectively become part of the source.)  If
technical measures are applied to the source to restrict it, it's
probably not the source anymore, by the GPL's definition.

(Speaking here only of the DRM subtopic.  You could lack the practical
abliity to use the source if it's in a weird language, but that's the
transparent copy topic--let's keep these things separate for sanity ...)

 All you need is a broadly available shim -- for example, something to convert
 word format to xml and xml back to word, to make it straightforward to
 modify the word document in a generic editor.

So you can use any format, all you have to do is reverse engineer it,
find an open format that's a complete superset of it (if one exists),
and write a two-way lossless converter?  That seems tantamount to
a prohibition--especially if, like many writers, you're not even a
programmer.  (I am, and that's still a daunting task.)

 No one (you included) has even cared to identify subsets of packages
 where this is true.  And we have some fairly broad subsets where code
 is re-usable.

I don't claim that everything must be compatible with everything else.
(Though I think it's a good goal, which is why I stick to the MIT license,
to maximize compatibility.)  With ordinary licenses, at the very minimum,
a work's license is compatible with the license itself (any others are a
bonus).  Patch clauses don't do that.  They're compatible with nothing.

 I don't believe I've ever heard of anyone even suggesting that someone's
 right to modify software should be revoked because their changelog
 entries (or whatever) are legally ambiguous.

The GFDL specifically says that it must clearly and legibly identify you.
Ambiguity and clarity are opposites, and pseudonyms do not identify you.

-- 
Glenn Maynard


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

Re: Results for Debian's Position on the GFDL

On 3/14/06, MJ Ray [EMAIL PROTECTED] wrote:
 Raul Miller [EMAIL PROTECTED]
  File permissions have little or nothing to do with enforcing copyright.
 
  File permissions are an all or nothing mechanism.  You either have
  given a person a copy of the copyrighted material, or you have not.

 Thereby, it can prevent unauthorised copying and meets the above
 definition, as far as I can see.

Same thing goes for a wooden door -- a wooden door can prevent
unauthorized copying, in the sense you're using

Same thing goes for a brick wall -- a brick wall can prevent
unauthorized copying, in the sense you're using.

Same thing goes for the atlantic ocean -- the atlantic ocean can prevent
unauthorized copying, in the sense you're using.

Notice a trend here?  None of this has anything to do with preventing
someone who has a copy from making unauthorized copies.

 The other things you mention are how technological measures are
 sometimes used, but that's not how it's phrased in law or in the FDL.

Do you seriously believe the GFDL prohibits the atlantic ocean?

--
Raul

Re: Results for Debian's Position on the GFDL

On 3/14/06, Glenn Maynard [EMAIL PROTECTED] wrote:
 The GFDL specifically says that it must clearly and legibly identify you.
 Ambiguity and clarity are opposites, and pseudonyms do not identify you.

My dad's name is Ron Miller.  Are you claiming that his name does
not identify him?

There's thousands of Ron Millers in the U.S. alone.  Are you claiming
that there's no ambiguity here?

I don't see any requirement in the GFDL that a person's identity
must be unambiguous, sworn to, attested, co-signed, pgp signed,
unique, guaranteed, warranteed, trackable, reachable, emailable,
etc.

--
Raul

Re: Results for Debian's Position on the GFDL