Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps

[Steve Langasek]

On Thu, Apr 17, 2003 at 12:02:31AM +0200, Raphael Hertzog wrote:
> Le Wed, Apr 16, 2003 at 03:15:19PM -0500, Steve Langasek écrivait:
> > 2. You may modify your copy or copies of the Program or any portion
> >   of it, thus forming a work based on the Program, and copy and
> >   distribute such modifications or work under the terms of Section 1
> >   above, provided that you also meet all of these conditions:
> > 
> >   [...]

> >   b) You must cause any work that you distribute or publish, that in
> >   whole or in part contains or is derived from the Program or any
> >   part thereof, to be licensed as a whole at no charge to all third
> >   parties under the terms of this License.

> I'm sorry but a perl script using DBI/DBD::mysql doesn't contain
> DBD::mysql and is not derived from DBD::mysql ... and it doesn't
> contain libmysqlclient12 and it isn't derived from libmysqlclient12.

> This is even more clear when you consider the fact that a perl script
> can use "DBI" as a general DB layer without knowing which driver is used
> behind the doors.

My question is, how is a package that depends on DBD::mysql materially
different from a compiled program that links dynamically against
libmysqlclient?  The mechanisms are different; the effect is the same.  I
believe that any sane interpretation of the GPL must treat these cases as
equivalent.  You seem to agree, though you disagree with me on how these
two cases should be treated.

> > Please let me know if you find problems with any of my reasoning above.

> The fact is that I think that you extend too easily the meaning of
> "contains" and "is derived".

> While a program directly linked can be considered like a derived work of
> the library, I don't think that you can say that program A is a derived
> work of libX if A is linked to libY which itself uses libX.

> Yes this means that you can go around the limitation of the GPL... but
> I'm confident that a fake library used only in that intent would be
> considered as violating the spirit of the GPL. However when that
> intermediate library serves a generic purpose like DBI, I doubt that
> we violate the spirit of the GPL.

So you don't believe that the letter of the GPL prohibits binary-only
distribution of an application, together with a GPL library that it's
dynamically linked against?  I believe there is room for argument here;
however, I also believe that Debian has a responsibility to err on the
side of caution when there is room for argument in interpreting a
license.

As to the spirit of the GPL, please read
.  This is
the opinion of the FSF; I'm inclined to believe, based both on past
litigation and on the fact of their strange decision to relicense under
the GPL that they will take a stance that's as hard-line as or more so
than that of the FSF.

The packages I listed in the bug report are not just consumers of the
intermediary DBI library; through decisions made by the package
maintainers, there are explicit dependencies on the DBD::mysql module.

> > Since the GPL makes no reference to technical details of linking
> > mechanisms, however, I'm confident that any interpretation that permits
> > distributing GPL-incompatible perl scripts together with a GPL perl
> > module would also permit distributing GPL-incompatible compiled binaries
> > together with GPL libraries.

> Note that the perl module is not GPL only, but GPL/Artistic (like most
> perl modules). I don't know how much trouble that brings ... :-)

In this case, I think it saves trouble: if DBD::mysql were GPL-only, then
the same argument applies even if you link against the LGPL version of
libmysqlclient.

> Does your reasoning also mean that each time a proprietary perl script
> is using a standard perl module, it uses the module under the terms of
> the Artistic license and not under the GPL because it can't comply with
> the GPL ?

Only if the proprietary perl script is bundled with the perl module.  If
the proprietary perl script isn't bundled, both licenses allow this use
(the FSF seems to disagree here, but I don't think they have legal
standing to enforce their position against someone who isn't a
distributor of the GPL code).

-- 
Steve Langasek
postmodern programmer


pgphug8uTvxWG.pgp
Description: PGP signature

Re: LPPL, take 2

[Mark Rafn]

> Scripsit Mark Rafn <[EMAIL PROTECTED]>
> > > > I'm close on this one.  "does not identify itself as unmodified in any 
> > > > way" is harder for me to understand than "identifies itself as 
> > > > modified".
> 
> > > It is just a little less restrictive.  Instead of requiring people to
> > > make a positive action to show that something is modified, they only
> > > have to prevent it from showing that it isn't.
> 
> > Hmm.  I'm not sure it's actually less restrictive.  Preventing another 
> > piece of software (the base format) from making a claim is a lot harder 
> > than making a positive claim yourself.

On Wed, 16 Apr 2003, Henning Makholm wrote:
> But it never said "the modified file must prevent other software from
> claiming blah". It said "the modified file must not itself claim blah".

Actually, it did (and no longer does).

 2. The entire Derived Work, including the Base Format, does not
identify itself as the original, unmodified Work to the user in
any way when run.

This seemed to possibly require prevention of the Base Format from
identifying the entire work in any way as unmodified.

Since changed, point moot.
--
Mark Rafn[EMAIL PROTECTED]  

Re: LPPL, take 2

[Frank Mittelbach]

Branden Robinson writes:

 > >  > >   c. In every file of the Derived Work you must ensure that any
 > >  > >  addresses for the reporting of errors do not refer to the Current
 > >  > >  Maintainer's addresses in any way.
 > >  > 
 > >  > This is somewhat new ground for a DFSG-free license.  Is it *really*
 > >  > that important?  
 > > 
 > > yes, we think it is. It is protecting the original author and/or maintainer
 > > from receiving unnecessary misdirected (and that's the point) call for help
 > > support on a product for which he made no offer to support. again this may 
 > > be
 > > a community difference, but in the TeX community people understand the
 > > bug/support address as an offer for to give support for a particular file
 > > (Work) in which it is found.
 > 
 > I understand the rationale.  I'm concerned about the wording.  Would the
 > following violate 5(c)?

on a slightly more serious note on that (how you read the whole of my last
posting :-) ...

 > It depends on what you mean by "in any way".
 > 
 > >  > Note that I'm not passionately opposed to 5c); 
 > > 
 > > I hope so; that becoming a stumbling block would be a shame.
 > 
 > Well, it's only a stumbling block if your understanding of it is very,
 > very aggressive, or if the license affords a very, very aggressive
 > interpretation of that clause.

i' not set on the phrasing of that part at all, in fact i think I can blame
Jeff for the current wording  :-) I'm very much in favor of a clear license.

just for the record, here is what was/is in LPPL 1.2

  6. You must change any addresses in the modified file for the
 reporting of errors in the file or in The Program generally to
 ensure that reports for files no longer maintained by the original
 maintainers will be directed to the maintainers of the modified
 files.

i think that is clearer as the current wording, it would't fit this way in the
new license, though. In fact i think the above is also asking for too much
looking at it now, i guess what is really wanted is simply:

   You must change or remove any addresses in the Derived Work for the
   reporting of errors to ensure bug reports for the Derived Work are not
   mistakenly directed to the maintainers of the original Work.

better? (too late for me now, to think further about it)

good night
frank

Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps

[Raphael Hertzog]

Le Wed, Apr 16, 2003 at 03:15:19PM -0500, Steve Langasek écrivait:
> 2. You may modify your copy or copies of the Program or any portion
>   of it, thus forming a work based on the Program, and copy and
>   distribute such modifications or work under the terms of Section 1
>   above, provided that you also meet all of these conditions:
> 
>   [...]
> 
>   b) You must cause any work that you distribute or publish, that in
>   whole or in part contains or is derived from the Program or any
>   part thereof, to be licensed as a whole at no charge to all third
>   parties under the terms of this License.

I'm sorry but a perl script using DBI/DBD::mysql doesn't contain
DBD::mysql and is not derived from DBD::mysql ... and it doesn't
contain libmysqlclient12 and it isn't derived from libmysqlclient12.

This is even more clear when you consider the fact that a perl script
can use "DBI" as a general DB layer without knowing which driver is used
behind the doors.

> Please let me know if you find problems with any of my reasoning above.

The fact is that I think that you extend too easily the meaning of
"contains" and "is derived".

While a program directly linked can be considered like a derived work of
the library, I don't think that you can say that program A is a derived
work of libX if A is linked to libY which itself uses libX.

Yes this means that you can go around the limitation of the GPL... but
I'm confident that a fake library used only in that intent would be
considered as violating the spirit of the GPL. However when that
intermediate library serves a generic purpose like DBI, I doubt that
we violate the spirit of the GPL.

> Since the GPL makes no reference to technical details of linking
> mechanisms, however, I'm confident that any interpretation that permits
> distributing GPL-incompatible perl scripts together with a GPL perl
> module would also permit distributing GPL-incompatible compiled binaries
> together with GPL libraries.

Note that the perl module is not GPL only, but GPL/Artistic (like most
perl modules). I don't know how much trouble that brings ... :-)

Does your reasoning also mean that each time a proprietary perl script
is using a standard perl module, it uses the module under the terms of
the Artistic license and not under the GPL because it can't comply with
the GPL ?

It's so boring those license issues ...

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: LPPL, take 2

[Martin Schröder]

On 2003-04-16 14:28:44 -0500, Branden Robinson wrote:
> I understand the rationale.  I'm concerned about the wording.  Would the
> following violate 5(c)?
> 
> % LaTeX-Foobar 1.2.9, copyright 2001--2003 John A. Doe
> %
> % Please report errors to <[EMAIL PROTECTED]>.
> %
> % MODIFIED BY Jack Smith 2003/04/10 to improve widow and orphan
> % handling.
> %
> % Please report errors in this version to <[EMAIL PROTECTED]> and do
> % not use John Doe's address.

Yes (at least it's considered very bad practice). But it would
probably be tolerated (grudgingly) if the modification note came
first. Too many lusers can't read documentation and use the first
address they can find.

Best regards
Martin
-- 
Our position is that whatever grievances a nation may have, however
objectionable it finds the status quo, aggressive warfare is an illegal
means for settling those grievances or for altering those conditions.
  (Supreme Court Justice Robert Jackson, the American prosecutor at the
   Nuremberg trials, in his opening statement to the tribunal)

Re: LPPL, take 2

[Frank Mittelbach]

Branden Robinson writes:

 > >  > >   c. In every file of the Derived Work you must ensure that any
 > >  > >   addresses for the reporting of errors do not refer to the Current
 > >  > >   Maintainer's addresses in any way.
 > >  > 
 > >  > This is somewhat new ground for a DFSG-free license.  Is it *really*
 > >  > that important?  
 > > 
 > > yes, we think it is. It is protecting the original author and/or
 > > maintainer from receiving unnecessary misdirected (and that's the point)
 > > call for help support on a product for which he made no offer to
 > > support. again this may be a community difference, but in the TeX
 > > community people understand the bug/support address as an offer for to
 > > give support for a particular file (Work) in which it is found.
 > 
 > I understand the rationale.  I'm concerned about the wording.  Would the
 > following violate 5(c)?
 > 
 > % LaTeX-Foobar 1.2.9, copyright 2001--2003 John A. Doe
 > %
 > % Please report errors to <[EMAIL PROTECTED]>.
 > %
 > % MODIFIED BY Jack Smith 2003/04/10 to improve widow and orphan
 > % handling.
 > %
 > % Please report errors in this version to <[EMAIL PROTECTED]> and do
 > % not use John Doe's address.


an interesting boundary case. would the following be slander?

  Branden Robinson is a stupid person



































































I haven't said that and i don't think so, I only heard somebody saying that
sentence on the street while passing by and was wondering what it meant.

-

i think that your example is clear enough to make people understand that
original bug address is probably no longer the right thing to use, but even so
it is information that is in logical conflict with other information and so
even if put side by side users might get confused by the contradicting
data. so why should it be wrong to require it not to be contradicting?

the moment there are 20 lines of technical changes between or other information

 > % MODIFIED BY Jack Smith 2003/04/10 to improve widow and orphan
 > % handling.

and

 > % Please report errors in this version to <[EMAIL PROTECTED]> and do
 > % not use John Doe's address.

we can be quite sure that a lot people will never reach the part that says do
not use "John Doe's address", just you may not have seen this part of my
argument while looking at my email at first

frank

Re: LPPL, take 2

[Henning Makholm]

Scripsit Mark Rafn <[EMAIL PROTECTED]>
> > Mark Rafn <[EMAIL PROTECTED]> wrote:

> > > I'm close on this one.  "does not identify itself as unmodified in any 
> > > way" is harder for me to understand than "identifies itself as modified".

> > It is just a little less restrictive.  Instead of requiring people to
> > make a positive action to show that something is modified, they only
> > have to prevent it from showing that it isn't.

> Hmm.  I'm not sure it's actually less restrictive.  Preventing another 
> piece of software (the base format) from making a claim is a lot harder 
> than making a positive claim yourself.

But it never said "the modified file must prevent other software from
claiming blah". It said "the modified file must not itself claim blah".

-- 
Henning Makholm   "We will discuss your youth another time."

Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps

[Steve Langasek]

Hi Raphael,

On Tue, Apr 15, 2003 at 10:08:59PM +0200, Raphael Hertzog wrote:
> Le Tue, Apr 15, 2003 at 02:29:52PM -0500, Steve Langasek écrivait:
> > The latest version of libdbd-mysql-perl build-depends on
> > libmysqclient-dev.  I'm afraid that, although this fixed the FTBFS bug,
> > it potentially renders some software in our archive non-distributable.
> > Because the new libmysqlclient12 package is licensed under the GPL, any
> > GPL-incompatible apps which depend on libdbd-mysql-perl would be in
> > violation of the libmysqlclient12 license.

> I disagree completely with this bug.

> The perl module "links" to libmysqlclient12, but the perl module is
> available under the GPL so it's ok.

I agree that the perl module itself is not violating the license of 
libmysqlclient12.

> Any other program/script "uses" DBD::mysql but doesn't link to
> libmysqlclient12 ... so there's no problem on that side either.

Here, I have to disagree.  You draw a distinction based on "linking",
but this word only appears only once in /usr/share/common-licenses/GPL:
as a footnote referring to the fact that the LGPL *does* allow linking
to proprietary apps.

Please note that if you are right, this would be a gaping loophole in
the GPL: it would allow people to circumvent the GPL, just by wrapping
any code they want as a module for an interpreted language.  Fortunately
for the goals of the FSF, this is not the case.  If you (in this case:
Debian) are distributing GPL software, under copyright law the GPL can
(and does) place restrictions on your distribution of other software
together with the GPL software; and under the DFSG, this is acceptable
because the GPL only restricts redistribution of other software that's
*related* to the GPL code programmatically (it doesn't taint independent
software distributed alongside it).

This establishes that a license can place restrictions on scripts built
around the software and still be considered free, but of course we must
also show that the GPL actually has such a restriction.  I believe the
key is in GPL section 2:

2. You may modify your copy or copies of the Program or any portion
  of it, thus forming a work based on the Program, and copy and
  distribute such modifications or work under the terms of Section 1
  above, provided that you also meet all of these conditions:

  [...]

  b) You must cause any work that you distribute or publish, that in
  whole or in part contains or is derived from the Program or any
  part thereof, to be licensed as a whole at no charge to all third
  parties under the terms of this License.

We are "linking" scripts that depend on libdbd-mysql-perl in a manner
that's conceptually equivalent to a dynamically-linked binary:  we have
a programmatic link, in the form of a Depends: line in our package
system, that guarantees that when the user runs the script as we
distribute it, GPL code is loaded into memory.  This means that any
scripts *we* distribute that Depend: on libdbd-mysql-perl must comply
with the terms of the GPL.  This is also not inconsistent with other
views of the GPL; anyone else, who is not distributing the MySQL
libraries, can distribute such scripts freely under terms of their
choice:

  These requirements apply to the modified work as a whole.  If
  identifiable sections of that work are not derived from the Program,
  and can be reasonably considered independent and separate works in
  themselves, then this License, and its terms, do not apply to those
  sections when you distribute them as separate works.  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, whose permissions for other licensees extend to the
  entire whole, and thus to each and every part regardless of who wrote 
  it.

> > I have not had a chance to look through the list of packages that depend
> > on libdbd-mysql-perl to see if any of these are actually
> > GPL-incompatible; however, libmysqlclient10 has been reintroduced to the
> > archive for just this sort of situation.  Please consider changing your
> > build-dep back to libmysqclient10-dev and dropping the libssl-dev
> > build-dep.

> Not until you can convince me that my interpretation of the license is
> clearly wrong. 

Please let me know if you find problems with any of my reasoning above.
Since the GPL makes no reference to technical details of linking
mechanisms, however, I'm confident that any interpretation that permits
distributing GPL-incompatible perl scripts together with a GPL perl
module would also permit distributing GPL-incompatible compiled binaries
together with GPL libraries.

-- 
Steve Langasek
postmodern programmer


pgpZ9SwOtPSNJ.pgp
Description: PGP signature

motion to take action on the unhappy GNU FDL issue

[Branden Robinson]

On Wed, Apr 16, 2003 at 08:12:27PM +1000, Anthony Towns wrote:
> Anyway, to answer your original question, "GFDL = non-free" is not an
> official Debian position simply because we haven't written up a proper
> explanation of why, and haven't gone through the GFDL documents in main
> to see which ones need removing.

Well, I've been too cowardly to raise this issue of late, but given that
the temperature of debian-legal has been taken a few times over the past
several months, and there seems to be a steady or growing feeling that
Invariant Sections are not something we can live with, shall we resolve
to move forward on this issue?

I propose that we:
* draft a comprehensive critique of the GNU FDL 1.2, detailing
  section-by-section our problems with the license
* draft a FAQ regarding why we differ with FSF orthodoxy on this
  issue
* draft a document advising users of the GNU FDL how to add
  riders to their license terms such that works so licensed are
  DFSG-free, and pointing out alternative documentation licenses
  that are also DFSG-free
Then:
* exhaustively identify works in main and contrib using the GNU
  FDL[1]
* contact[2] the package maintainers and upstream authors of
  each affected source package, and include pointers to the
  above documents
* post a list of affected packages to debian-devel-announce
  and/or debian-announce, so that no one is surprised by
  whatever later actions occur
* give people some time to consider and act upon the above
  contact (some may relicense, some will tell us to go pound
  sand, others won't reply at all)
* remove packages from main and contrib whose licenses have not
  been brought into compliance with the DFSG

This is the stuff of which nasty flamewars and misspelled Slashdot
headlines are made, hence my unwillingness to do it, but it is clear to
me that letting this issue languish in ambiguity isn't good for us or
our users.  Either that we feel the GNU FDL is being used in main and
contrib in ways that are not DFSG-free, or we don't, and either way we
need to get ourselves squarely on the record.

I am seeking seconds for this proposal.

[1] I don't restrict this to GNU FDL-licensed documents that have Cover
Texts or Invariant Sections because previous discussions have indicated
that there may be still other problems with the GNU FDL 1.2.  I seem to
recall someone raising a fairly persuasive critique of section 4K, for
instance.  Thus, if we're going to nail some theses to the church door,
we might as well make sure that they're comprehensive.

[2] possibly through a mass bug-filing, but I leave this detail to
future determination

-- 
G. Branden Robinson|  "To be is to do"   -- Plato
Debian GNU/Linux   |  "To do is to be"   -- Aristotle
[EMAIL PROTECTED] |  "Do be do be do"   -- Sinatra
http://people.debian.org/~branden/ |


pgpXnRGXVi3Pz.pgp
Description: PGP signature

Re: query from Georg Greve of GNU about Debian's opinion of the F DL

[Branden Robinson]

On Tue, Apr 15, 2003 at 10:37:57AM -0400, Brian T. Sniffen wrote:
> In addition, how does the FSF expect anybody other than itself to
> distribute a GPL'd emacs with a GFDL manual?

Heh; maybe they don't.  Maybe they're tired of all these "Linux"
distributions that should be calling themselves "GNU/Linux"
distributions, and only people who play ball should be allowed to easily
access the documentation for GNU Emacs.  Everyone else can just go use
XEmacs or Vim, or some other editor that is looked down upon.  :)

-- 
G. Branden Robinson| No math genius, eh?  Then perhaps
Debian GNU/Linux   | you could explain to me where you
[EMAIL PROTECTED] | got these...   PENROSE TILES!
http://people.debian.org/~branden/ | -- Stephen R. Notley


pgpEcoQuLiyVv.pgp
Description: PGP signature

Re: LPPL, take 2

[Branden Robinson]

On Tue, Apr 15, 2003 at 10:29:44PM +0200, Frank Mittelbach wrote:
> Branden Robinson writes:
>  > Please make restrictions attach to distributions of modification, not
>  > the act of modifying in and of itself.
> 
> we think it is neither of users nor of people actively supporting (read: user
> support) and maintaining a large software system, that modification is done
> without minimal preparation for a potential distribution (because accidental
> distributions happen often enough and that puts the burden on the maintainers)
> but we think it is okay to make this a recommendation rather than a license
> requirement (as it is in the LPPL 1.2 version, e.g., there we had the
> recommendation
> 
>A Recommendation on Modification Without Distribution
>-
> 
>It is wise never to modify a file of The Program, even for your own
>personal use, without also meeting the above eight conditions for
>distributing the modified file.  While you might intend that such
>modified files will never be distributed, often this will happen by
>accident -- you may forget that you have modified the file; or it may
>not occur to you when allowing others to access the modified file
>that you are thus distributing it and violating the conditions of
>this license.  It is usually in your best interest to keep your copy
>of The Program identical with the public one.  Many programs provide
>ways to control the behavior of that program without altering its
>licensed files.

Okay; that sounds fine.  I think it's a very good idea to have a
separate "how to understand this license" document where you make your
intentions and philosophies clear.  If more authors did that,
debian-legal wouldn't have to mail them with so many questions.  :)

>  > E.g.
>  > 
>  > 5.  If you are not the Current Maintainer of The Work, you may modify
>  > your copy of The Work, thus creating a Derived Work based on The Work.
>  > You may distribute your Derived Work to whomever you choose as long as
>  > the following conditions are met:
> 
> as i said, ok though I would probably shorten the last sentense to simply
> 
>You may distribute your Derived Work as long as the following conditions
>are met:

Sounds great!

>  > >   a. You must ensure that each modified file of the Derived Work is
>  > >  clearly distinguished from the original file. This must be
>  > >  achieved by causing each such modified file to carry prominent
>  > >  notices detailing the nature of the changes,
>  > 
>  > Are you gravely opposed to external changelogs, as might be generated
>  > by, say, cvs2cl -- even if those changelogs have to be distributed along
>  > with the modified files of the Derived Work?
> 
> yes, we are. This is not how the LaTeX world works. The license is to support
> the users, the authors, and the maintainers of the Work and Changelogs are
> totally alien to LPPL type of software; there is no requirement to produce,
> let alone distribute, them.  Very few users (authors or system maintainers)
> would know how to look for one. Furthermore distributions are usually
> splitting things up into runnable versions, often source and extra
> documentation are quite difficult to find, other than documentation directly
> in the files being used.

I understand that, but again there is a difference between exhortation
and requirement.  The GNU GPL has a similar requirement, but the FSF
itself does not generally follow this practice, since it *is* part of
their culture to use ChangeLog files and tools like "cvs2cl".

Can you predict that the LaTeX community will never change such that
revision-control systems will be used which track rationales for
committed changes as file metadata?

I'm not saying that your requirement should be dropped altogether; your
intention is perfectly reasonable.  I'm saying that it shouldn't be a
license violation for someone to check an LPPLed LaTeX package into CVS
and maintain their own version, tracking the reasons for their changes
via CVS commit messages and a ChangeLog file, as long as if and when
they distribute it they either:

  1) distribute the complete and accurate ChangeLog corresponding to the
 modified LPPL-licensed file(s) in question; OR
  2) insert the contents of the complete and accurate ChangeLog into the
 body of the modified LPPL-licensed file(s) in question

Both approaches seem reasonable to me, and to reflect real-world
software development practice.

>  > >   c. In every file of the Derived Work you must ensure that any
>  > >  addresses for the reporting of errors do not refer to the Current
>  > >  Maintainer's addresses in any way.
>  > 
>  > This is somewhat new ground for a DFSG-free license.  Is it *really*
>  > that important?  
> 
> yes, we think it is. It is protecting the original author and/or maintainer
> from receiving unnecessary misdirected (and that's the point) call for

Re: query from Georg Greve of GNU about Debian's opinion of the F DL

[Peter S Galbraith]

[I've found this unsent message which I wrote yesterday]

Brian T. Sniffen <[EMAIL PROTECTED]> wrote:

> You've heard all this before, but I haven't seen you answer it.  Why
> does the GFDL prohibit me from making an emacs reference card from the
> manual?  Sure, I could make a one-sided card where the other side is
> the Manifesto, but that wastes half my space.

If the manifesto marked as invariant?  I didn't know that!

I don't have the texinfo sources here, only the Info version.
There's a node:

* GNU Free Documentation License:: The license for this documentation.

It spells out how to use the license but doesn't apply it for this
document.  e.g. I can't find the copyright declaration for that document
where the invariant sections are to be listed.
 
> In addition, how does the FSF expect anybody other than itself to
> distribute a GPL'd emacs with a GFDL manual?  As far as I can see,
> they cannot be distributed together.  Emacs links against the manual
> files, interpreting them programmatically -- this is how it takes me
> straight to the info page referring to particular variables or
> functions.  It is, after all, a self-documenting editor.  But the GFDL
> imposes additional requirements over the GPL, so they may not be
> distributed linked.

It sounds to me that Debian should request that the FSF grant the
exception to distribute the two works linked like that.  Following the
FSF's licenses to the letter would mean the removal of the manual from
the emacs package, which isn't good for our users.

Peter

Re: Suggestion to maintainers of GFDL docs

[Peter S Galbraith]

Simon Law <[EMAIL PROTECTED]> wrote:

> On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith wrote:
> > Consider this a suggestion to maintainers of packages that contain
> > documentation that are under the GFDL, especially if it contains
> > invariant sections.  Imagine if an Emacs user visited Info and saw this:
> > 
> > * Menu:
> > 
> > * Distrib:: How to get the latest Emacs distribution.
> > * Copying:: The GNU General Public License gives you permission
> >   to redistribute GNU Emacs on certain terms;
> >   it also explains that there is no warranty.
> > * GNU Free Documentation License:: The license for this documentation.
> > * Why you shouldn't use the GFDL:: Debian doesn't recommend using this 
> > license.
> > 
> > And what if this new section listing reasons _not_ to use this license
> > were made...  invariant!
> > 
> > If the FSF wants to give redistributors a soapbox, perhaps we should use
> > it.
> 
>   Although incredibly clever, 

Thanks!
>   this is not the sort of thing that
> we should do.  It would be very hypocritical to use a non-free mechanism
> to try to advance free documentation.

Well, I suppose the section wouldn't need to be invariant to be
effective.  It could simply mention that it _could have been invariant_
and that's why the license isn't very protective of freedom.

>   Plus, it would make people angry; and who needs to anger more
> people?
> 
> Simon

Perhaps.  I admit that my judgement might be affected by the current
discussion with Georg Greve.  But the section wouldn't need to be
written in an inflammatory manner.  In fact it would be much more
effective if it were not.

I'm just worried that a lot of projects will use this license because
it's the FSF-approved method.  That's what we did at
http://gri.sourceforge.net and I will change that now that I know
better.  Luckily, it's not too late for us.  But for other projects with
a great number of contributors it's probably already very difficult to
change the license.  This issue needs more visibility.

Peter

Re: Suggestion to maintainers of GFDL docs

[Simon Law]

On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith wrote:
> Consider this a suggestion to maintainers of packages that contain
> documentation that are under the GFDL, especially if it contains
> invariant sections.  Imagine if an Emacs user visited Info and saw this:
> 
> * Menu:
> 
> * Distrib::   How to get the latest Emacs distribution.
> * Copying::   The GNU General Public License gives you permission
> to redistribute GNU Emacs on certain terms;
> it also explains that there is no warranty.
> * GNU Free Documentation License:: The license for this documentation.
> * Why you shouldn't use the GFDL:: Debian doesn't recommend using this 
> license.
> 
> And what if this new section listing reasons _not_ to use this license
> were made...  invariant!
> 
> If the FSF wants to give redistributors a soapbox, perhaps we should use
> it.

Although incredibly clever, this is not the sort of thing that
we should do.  It would be very hypocritical to use a non-free mechanism
to try to advance free documentation.

Plus, it would make people angry; and who needs to anger more
people?

Simon

Re: Suggestion to maintainers of GFDL docs

[Peter S Galbraith]

Anthony Towns  wrote:

> On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith wrote:
> > * Why you shouldn't use the GFDL:: Debian doesn't recommend using this
> license.
> > And what if this new section listing reasons _not_ to use this license
> > were made...  invariant!
> > 
> > If the FSF wants to give redistributors a soapbox, perhaps we should
> use
> > it.
> 
> We already have a soapbox -- debian-announce@lists.debian.org and
> www.debian.org. We don't need to tie our opinions to technical
> documentation to have them heard.

Sure, but doing it this way might drive the point across a lot better.
These info files advertise this license to potential authors, so
having a rebuttal in the same place is effective.

Anyway, it's just an idea.  And it's up to individual package
maintainers anyway.  If we ever publish such a list, I might use it in
such a way.

Peter

Re: Suggestion to maintainers of GFDL docs

[Anthony Towns]

On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith wrote:
> * Why you shouldn't use the GFDL:: Debian doesn't recommend using this 
> license.
> And what if this new section listing reasons _not_ to use this license
> were made...  invariant!
> 
> If the FSF wants to give redistributors a soapbox, perhaps we should use
> it.

We already have a soapbox -- debian-announce@lists.debian.org and
www.debian.org. We don't need to tie our opinions to technical
documentation to have them heard.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``Dear Anthony Towns: [...] Congratulations -- 
you are now certified as a Red Hat Certified Engineer!''


pgpyeMndpa6xy.pgp
Description: PGP signature

Suggestion to maintainers of GFDL docs

[Peter S Galbraith]

Consider this a suggestion to maintainers of packages that contain
documentation that are under the GFDL, especially if it contains
invariant sections.  Imagine if an Emacs user visited Info and saw this:

* Menu:

* Distrib:: How to get the latest Emacs distribution.
* Copying:: The GNU General Public License gives you permission
  to redistribute GNU Emacs on certain terms;
  it also explains that there is no warranty.
* GNU Free Documentation License:: The license for this documentation.
* Why you shouldn't use the GFDL:: Debian doesn't recommend using this license.

And what if this new section listing reasons _not_ to use this license
were made...  invariant!

If the FSF wants to give redistributors a soapbox, perhaps we should use
it.

Peter

Re: query from Georg Greve of GNU about Debian's opinion of the F DL

[Peter S Galbraith]

Georg C. F. Greve <[EMAIL PROTECTED]> wrote:

>  || On Tue, 15 Apr 2003 09:31:26 -0400
>  || Peter S Galbraith <[EMAIL PROTECTED]> wrote: 
> 
>  psg> It doesn't perserve freedom at all.  It grants any redistributor
>  psg> the right to add unremovable rants to the loss of the user's
>  psg> freedom.
>  
> So you are afraid of somebody adding a part that you don't like and
> making it invariant? 

Absolutely.  See my previous reply.  Releasing software under the GPL
assures me that I can merge in derived works from other contributors
back into my original work.  Using the GFDL means I might not be able to
do that without being forced to add useless crap along with it.  The GPL
protects the original author and the end user from the abuses of
redistributors; the GFDL allows these abuses.
 
> I'm sorry, but if somebody wrote something into a document that was
> important to him and you didn't like it and removed it to distribute
> that as a newer version of the document, you'd be violating that
> persons Copyright. GNU Free Documentation License or no.

No if it were released under the GPL.  Compare to:

 "I'm sorry, but if somebody wrote something into SOFTWARE that was
  important to him and you didn't like it and removed it to distribute
  that as a newer version of the SOFTWARE, you'd be violating that
  persons Copyright."

Care to defend that again?

>  psg> There you go again.  It's not about disk space.  It's about
>  psg> freedom.
> 
> Exactly. 
> 
> That is why I didn't accept the technical idea that it wasn't possible
> to ship the whole document with the GUI that wishes to display parts
> of it or the necessity to hard-code parts of the document into the
> program.

Imposing technical limitations is non-free.

>  psg> Do you really represent the FSF?
> 
> Yes.
> 
>  psg> Do they know how you really feel about these issues?
> 
> I would think so.

Well, I'm sorry to say I no longer feel that freedom is safe in the
hands of the FSF.  I will rethink future copyright assignments to the
FSF.
 
-- 
Peter S. Galbraith, Debian Developer  <[EMAIL PROTECTED]>
 http://people.debian.org/~psg
GPG key 1024/D2A913A1 - 97CE 866F F579 96EE  6E68 8170 35FF 799E

Re: query from Georg Greve of GNU about Debian's opinion of the F DL

[Peter S Galbraith]

Georg C. F. Greve <[EMAIL PROTECTED]> wrote:

> Especially the GPL is striking a new balance between the rights of the
> author and the freedoms of the users that puts both above the wishes
> of middlemen. 
> 
> The GFDL deeks to do the same thing. Only this time you find yourself
> in the position of middleman and have to take care to not violate the
> rights of either party.

Quite the opposite actually.  Any redistributor can add invariant
sections which makes sharing difficult.

When you release code under the GPL, you're sure that contributors must
distribute their work under the same license.  So if they did
interesting work in the derived work you can merge it back into the
original as long as you add their name to the Copyright.

Now you release the documentation under the GFDL without any invariant
sections.  A contributor releases an extended version of the docs but
includes a long rant as an invariant section.  You can't merge the work
back in without including the long rant verbatim.  This doesn't protect
the original author nor the end users very well.

-- 
Peter S. Galbraith, Debian Developer  <[EMAIL PROTECTED]>
 http://people.debian.org/~psg
GPG key 1024/D2A913A1 - 97CE 866F F579 96EE  6E68 8170 35FF 799E

Re: query from Georg Greve of GNU about Debian's opinion of the F DL

[Edmund GRIMLEY EVANS]

Georg C. F. Greve <[EMAIL PROTECTED]>:

> Although I have said it before, I'll say it again: I don't consider
> the GFDL to be perfect, but from the free documentation licenses I
> have seen so far, it seems to be the most solid one for the reasons
> I've described.

What do you mean by a "free documentation licence"?

> Of course technical manuals require change. So it may be possible that
> authors use invariant sections in an unwise way, covering parts that
> need to be changed to keep the manual useful. In that case such
> manuals should maybe be put into contrib.

So you agree that some documents licensed under the GFDL are not free.

I think people are unhappy about the FSF publishing a licence with
"Free" in its title, which does not however guarantee that stuff
licensed under it is free; GFDL documentaton is only free if the GFDL
is applied wisely. I'm glad the GPL doesn't have this feature.

Personally, I will stick to using the GPL, even for non-software.
Other people seem to have had the same idea. For example, here is an
on-line Esperanto dictionary licensed under the GPL:
http://www.uni-leipzig.de/esperanto/voko/revo/

Edmund

Re: query from Georg Greve of GNU about Debian's opinion of the F DL

[Anthony Towns]

On Wed, Apr 16, 2003 at 10:52:55AM +0200, Georg C. F. Greve wrote:
> I'm sorry, but if somebody wrote something into a document that was
> important to him and you didn't like it and removed it to distribute
> that as a newer version of the document, you'd be violating that
> persons Copyright. GNU Free Documentation License or no.

Yes, that's how copyright works. You're not allowed to change things without
permission.

*Free* licenses give you that permission. The GNU "Free" Documentation
License specifically *does not* give you that permission when invariant
sections are involved.

In particular, in the case of GPLed software, you _can_ take
any small part of the program and reuse it without any significant
encumberance. Sure, you might have to GPL your work, and sure, you might
have to display a copyright notice when run interactively, but you can do it.

For example, without violating copyright or hoping that some exception
applies, I can't excerpt:

]   GDB can do four main kinds of things (plus other things in support of
] these) to help you catch bugs in the act:
]
]* Start your program, specifying anything that might affect its
]  behavior.
]
]* Make your program stop on specified conditions.
]
]* Examine what has happened, when your program has stopped.
]
]* Change things in your program, so you can experiment with
]  correcting the effects of one bug and go on to learn about another.
]
]You can use GDB to debug programs written in C and C++.  For more
] information, see *Note Supported languages: Support.  For more
] information, see *Note C and C++: C.

from the current GDB manual without also including the full, and
completely irrelevant, "Free Software Needs Free Documentation" diatribe.

> Again that has nothing to do with the GFDL.

To reiterate. Copyright allows you a very high degree of control over
what modifications may be made to your work. Copyright licenses allow you
to exercise that control. Free licenses, that is, licenses that match the
DFSG which is how Debian defines "free", allow you to make a wide range of
modifications that don't necessarily preserve the original authors intent.

> However: If it was under GFDL without making use of invariant
> sections, you'd be safe to use it the way you described.

Documents licensed under the GFDL that don't make use of invariant
sections, or front/back-cover texts, or the other loopholes to allow
non-free additions to the documentation, are DFSG-free.

> If somebody doesn't like the GPL and tells me: "All I wanted were
> these few lines, why should I adhere to the GPL because of that?"

No. The generalisation is "All I wanted was these few lines, why should
I have to take this whole chunk of irrelevant garbage as well?", and the
analogy is to licenses that say "You can do whatever you want with this
software -- distribute it, modify it, whatever, as long as it always
meets standard Foo". Such licenses are non-free.

> In my eyes the GFDL is clearly a free license. 

Good for you.

> Of course technical manuals require change. So it may be possible that
> authors use invariant sections in an unwise way, covering parts that
> need to be changed to keep the manual useful. In that case such
> manuals should maybe be put into contrib.

The only way a freely licensed document would go into contrib is if it
were in a format that was only readable using non-free software. If a
document is in itself not free, it goes in non-free.

It sets a disappointing example that the Free Software Foundation does not
trust free licenses (that allow modification by anyone in almost any way)
to protect the intent and history of some of their most precious works,
including the GPL itself and the GNU Manifesto. For comparison:

* The Debian Constitution 
  is made available under the Open Publication License

* The Debian Developers Reference and Debian Policy are made available
  under the GPL

* The Debian Social Contract and Debian Free Software Guidelines
   are made available
  under the OPL and "Other organizations may derive from and build
  on this document. Please give credit to the Debian project
  if you do." Derived works include the Open Source Definition,
  the Open Directory Project Social Contract, the Gentoo Linux
  Social Contract, presumably the MusicBrainz Social Contract,
  and possibly the Free University Project Social Contract.

It's hard to see, from here, how allowing people to derive from your
core documents is a bad thing -- even when you're focussed on letting
people derive from the software you produce.

Anyway, to answer your original question, "GFDL = non-free" is not an
official Debian position simply because we haven't written up a proper
explanation of why, and haven't gone through the GFDL documents in main
to see which ones n

Re: query from Georg Greve of GNU about Debian's opinion of the F DL

[James Troup]

"Georg C. F. Greve" <[EMAIL PROTECTED]> writes:

> I'm sorry, but if somebody wrote something into a document that was
> important to him and you didn't like it and removed it to distribute
> that as a newer version of the document, you'd be violating that
> persons Copyright. 

Err, what complete BS.  So, to take a (hypothetical) real world
example[1], you're telling me that if the upstream author of the GNU
Privacy Handbook (under the GFDL with no invariant sections or other
options) added a 10Mb rant about how cows were secret leaders of a
world-wide cabal poised to take over the earth RSN, I couldn't remove
it because I'd be violating his copyright?  Pfft.  What rubbish.

Do you really not get that one of the fundamental freedoms (of the
free software community) is the freedom to fork and/or make changes
that the original author is against?  It's not something to be used
hastily or regularly, but it's a fundamental freedom never the less.

Or are you just so caught up in trying to defend the GFDL that you'll
say almost anything to further that cause?

> GNU Free Documentation License or no.

Really... so why is this in the GFDL then?

|The purpose of this License is to make a manual, textbook, or other
|written document "free" in the sense of freedom: to assure everyone
|the effective freedom to copy and redistribute it, with or without
 ^  ***
|modifying it, either commercially or noncommercially. Secondarily,
 
|this License preserves for the author and publisher a way to get
|credit for their work, while not being considered responsible for
|modifications made by others.

>  psg> Do you really represent the FSF?
> 
> Yes.
> 
>  psg> Do they know how you really feel about these issues?
> 
> I would think so.

Well, if that's true then it's a real shame because my opinion of the
FSF has fallen to an all time low.

> In my eyes the GFDL is clearly a free license. 

It's reasonably clear to me that there's a good consensus on
debian-legal that GFDL (using invariant sections at least) is not and
you don't seem to be convincing anyone otherwise...

-- 
James

[1] Real world in the sense that I maintain the gnupg-doc package
which contains the GPH.  Hypothetical in the sense that the
example's clearly OTT to prove a point.

Re: query from Georg Greve of GNU about Debian's opinion of the F DL

[Georg C. F. Greve]

 || On Tue, 15 Apr 2003 09:31:26 -0400
 || Peter S Galbraith <[EMAIL PROTECTED]> wrote: 

 psg> It doesn't perserve freedom at all.  It grants any redistributor
 psg> the right to add unremovable rants to the loss of the user's
 psg> freedom.
 
So you are afraid of somebody adding a part that you don't like and
making it invariant? 

I'm sorry, but if somebody wrote something into a document that was
important to him and you didn't like it and removed it to distribute
that as a newer version of the document, you'd be violating that
persons Copyright. GNU Free Documentation License or no.

Of course that person writing something unpleasant into it might be
violating the rights of the previous authors if they feel
misrepresented.

Again that has nothing to do with the GFDL.


 psg> It's copied from http://www.debian.org/Bugs/Developer#severities
 psg> If that text were licensed with invariant sections, I'd have to
 psg> include them in this one-page help screen.

I agree that making that particular text with invariant sections would
be extremely unpractical and make little sense. Nobody says you have
to use invariant sections, though. And I certainly didn't say every
document should contain invariant sections.

However: If it was under GFDL without making use of invariant
sections, you'd be safe to use it the way you described.

Right now you'd probably have to treat it as potentially invariant as
a whole to be on the entirely safe legal side.


 psg> Oh, I'm sorry.  I thought this content was under a free license.
 psg> You now seem to be saying otherwise.  The strings you attach to
 psg> your content make it non-free.
 
Don't misrepresent what I said. 

I haven't attached anything, I was asking a question.

And yes. 

If somebody doesn't like the GPL and tells me: "All I wanted were
these few lines, why should I adhere to the GPL because of that?" my
answer is that they are perfectly welcome to reimplement them
themselves if they don't like the license chosen by the author.


In my understanding freedom is not "I can do whatever I want to
whatever I want." I know there is a fundamental disagreement about
this question between the BSD and the GNU people, but you know which
side I am on.


 psg> There you go again.  It's not about disk space.  It's about
 psg> freedom.

Exactly. 

That is why I didn't accept the technical idea that it wasn't possible
to ship the whole document with the GUI that wishes to display parts
of it or the necessity to hard-code parts of the document into the
program.


 psg> Do you really represent the FSF?

Yes.

 psg> Do they know how you really feel about these issues?

I would think so.


Although I have said it before, I'll say it again: I don't consider
the GFDL to be perfect, but from the free documentation licenses I
have seen so far, it seems to be the most solid one for the reasons
I've described.

I agree that invariant sections can be quite difficult for technical
documentation -- especially if used unwisely.

The GFDL offers the users and distributors such as Debian a higher
degree of legal security, however, as someone who has not used the
possible measure of invariant section will have a much harder time
suing for violation of his or her moral rights than someone using a
license that didn't offer such measures.


In my eyes the GFDL is clearly a free license. 

Of course technical manuals require change. So it may be possible that
authors use invariant sections in an unwise way, covering parts that
need to be changed to keep the manual useful. In that case such
manuals should maybe be put into contrib.

Regards,
Georg

-- 
Georg C. F. Greve   <[EMAIL PROTECTED]>
Free Software Foundation Europe  (http://fsfeurope.org)
Brave GNU World(http://brave-gnu-world.org)


pgpbBYXvqmjQl.pgp
Description: PGP signature

Re: query from Georg Greve of GNU about Debian's opinion of the FDL

[Anthony Towns]

On Mon, Apr 14, 2003 at 06:21:11PM +0200, Georg C. F. Greve wrote:
> But unlike prose, most software derives its justification to exist
> From its function, not its aesthetics.
> The very same people who have been lumping together totally different
> areas of law such as copyright, patents and trademarks under the
> "intellectual property rights" terminology are still careful enough to
> differentiate between software and what they call "content."

BTW, lumping things that are different isn't the only thing other people
do to come to unhelpful conclusions, separating things that are similar
in exactly the way that you have is too.

In particular, the above argument is the exact one people to use to say
that software is not a form of speech, and should not be given the strong
protections many expect to be given to speech. It's refuted by example
by Dravid Touretzky at http://www.cs.cmu.edu/~dst/DeCSS/Gallery/, fwiw.

It's obvious and trivial to claim that there are differences between your
average speech, or your average book, or your average picture and your
average program. It's not correct to go on from there to say that some
things deserve more protection than others. If you want to distribute the
GNU Manifesto in a non-free manner, that's fine and your choice. If you
want to distribute the glibc and gcc documentation in a non-free manner,
that's fine and your choice too. Trying to establish loopholes in what
the community accepts as "free" in order to avoid getting caught in a
double standard isn't fine, however, even if you don't realise that's
what you're doing, and you're doing it with the best intentions for the
long term interests of free software.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

  ``Dear Anthony Towns: [...] Congratulations -- 
you are now certified as a Red Hat Certified Engineer!''


pgpZoS6PgDZJv.pgp
Description: PGP signature