Re: A radical approach to rewriting the DFSG

[Branden Robinson]

On Sun, May 30, 2004 at 06:28:12AM +0100, Henning Makholm wrote:
> I have been toying with the possibility of rewriting the DFSG such
> that it enumerates which things a free license *can* do, rather than
> just give examples of things it *cannot*. I think that such a revision
> could get the guidelines to be much closer to the *actual* practise of
> how we evaluate licenses than if we simply make local adjustments to
> the current DFSG. The downside is that the whole truth cannot be
> condensed into the "ten commandments" schema of the current DFSG.

I personally do not think it is a good idea to undertake this endeavor
as a DFSG replacement.

I explicated my "theory of DFSG" operation in a mail to this list in
March of 2003:

  http://lists.debian.org/debian-legal/2003/03/msg00211.html

That said, I do very much appreciate your work in very methodically
documenting the many silly loopholes and exceptions we have accreted
over the years to due to our haste and carelesness -- and also the many
slick tricks licensors have tried to play to undermine the spirit of
free software while abiding by some expressions of its "letter".)

I think your document will end up being very valuable to us, but I
personally do not feel that its approach makes it suitable as a
replacement for the DFSG.

Please don't interpret anything in this message as a backhanded
compliment, though I am sure we probably disagree as to what the DFSG
should be.  It was obviously a lot of hard work to prepare this
document, and reading it was like a trip down the debian-legal flamewar
memory lane, with the outcomes neatly boiled down.

I think your work on this document is a valuable service to the Project.

-- 
G. Branden Robinson|   Psychology is really biology.
Debian GNU/Linux   |   Biology is really chemistry.
[EMAIL PROTECTED] |   Chemistry is really physics.
http://people.debian.org/~branden/ |   Physics is really math.


signature.asc
Description: Digital signature

Re: A radical approach to rewriting the DFSG

[Henning Makholm]

I wrote,

> My results so far are at
>

and then a lot of people wrote comments, most of which I have still
not followed up on, due to the demands of my day job. I won't be able
to do debian-legal things for the next week or so either; I'll try to
process the resulting thread when I get back to the surface. Rotten
timing on my part, I suppose...

-- 
Henning Makholm "Slip den panserraket og læg
  dig på jorden med ansigtet nedad!"

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On Wed, 02 Jun 2004 20:07:06 -0400 Nathanael Nerode wrote:

> The essence of what I would accept is this:
> 
> "If you claim, legally, that my work can't be
> distributed/used/modified freely by people in general, then *you*
> can't distribute/use/modify my work either".  A "if you think this
> should happen to everyone else, it should happen to you too" clause.
> 
> This prevents people from actually literally taking free software
> proprietary (not just derivative works, but the originals) -- this
> could otherwise be done using patents.

It seems a good approach: it may work.

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpDtvBC0Th3X.pgp
Description: PGP signature

Re: A radical approach to rewriting the DFSG

[Nathanael Nerode]

Glenn Maynard wrote:

> On Wed, Jun 02, 2004 at 09:14:23PM -0400, Nathanael Nerode wrote:
>> > php4/copyright: may "PHP" appear in their name, without prior
>> > written
> 
> I should have quoted this one in full:
> 
>   4. Products derived from this software may not be called "PHP", nor
>  may "PHP" appear in their name, without prior written permission
>  from [EMAIL PROTECTED]  You may indicate that your software works in
>  conjunction with PHP by saying "Foo for PHP" instead of calling
>  it "PHP Foo" or "phpfoo"

The big problem is that Debian's PHP4 package *is* a product derived from
that software; just look at the diff, which contains significant changes. 
And Debian's package doesn't fall under the exception in the second
sentence, because it's called "php4".  If it were called, uh, "Debian for
PHP4", I suppose it might.

I don't think the PHP copyright holders thought about what their clause
actually meant under copyright law.  :-P  (Accordingly, I'd hope they'd be
willing to clarify what they meant -- or ideally fix their license -- but
they had better be contacted.)

-- 
There are none so blind as those who will not see.

Re: A radical approach to rewriting the DFSG

[Glenn Maynard]

On Wed, Jun 02, 2004 at 09:14:23PM -0400, Nathanael Nerode wrote:
> > php4/copyright: may "PHP" appear in their name, without prior written

I should have quoted this one in full:

  4. Products derived from this software may not be called "PHP", nor
 may "PHP" appear in their name, without prior written permission
 from [EMAIL PROTECTED]  You may indicate that your software works in
 conjunction with PHP by saying "Foo for PHP" instead of calling
 it "PHP Foo" or "phpfoo"
 
-- 
Glenn Maynard

Re: A radical approach to rewriting the DFSG

[Nathanael Nerode]

Glenn Maynard wrote:

> On Wed, Jun 02, 2004 at 08:12:28PM -0400, Nathanael Nerode wrote:
>> It's been allowed mostly because they don't really enforce it.  For
>> instance, Debian's modified version of Apache, which is a derived work,
>> has
>> "apache" in its name.  Furthermore, they've stated that they don't intend
>> to enforce it strictly, and it's not present in the new license.
>> 
>> I certainly wouldn't accept this clause in a license without additional
>> assurances from the copyright holder.  We said as much to X-Oz.
> 
> libssl-dev/copyright: *nor may "OpenSSL" appear in their names without
> prior written

Eeeew.  Well, isn't OpenSSL well on its way to being replaced by GnuTLS in
Debian anyway?

> apache-utils/copyright: nor may "mod_ssl" appear in their names
> without prior

Ewww

> php4/copyright: may "PHP" appear in their name, without prior written

Ow.  Debian is clearly violating the PHP4 licence unless capital letters vs.
small letters are significant.  Better contact the copyright holders.

> permission subversion/copyright:nor may "Tigris" appear in their names
> without prior written

Perhaps Tigris could be contacted?  Interestingly, Debian is actually
*complying* with this license, unlike the others, since "Subversion" isn't
named "Tigris".

> and a particularly evil one,
> 
> sudo/copyright:  may "Sudo" appear in their names without specific
> prior written

Again, unless capitalization is significant, Debian is violating the terms
of this license.  Someone (not me) should contact the copyright holder.

Thanks for pointing these out.

-- 
There are none so blind as those who will not see.

Re: A radical approach to rewriting the DFSG

[Glenn Maynard]

On Wed, Jun 02, 2004 at 08:12:28PM -0400, Nathanael Nerode wrote:
> It's been allowed mostly because they don't really enforce it.  For
> instance, Debian's modified version of Apache, which is a derived work, has
> "apache" in its name.  Furthermore, they've stated that they don't intend
> to enforce it strictly, and it's not present in the new license.
> 
> I certainly wouldn't accept this clause in a license without additional
> assurances from the copyright holder.  We said as much to X-Oz.

libssl-dev/copyright: *nor may "OpenSSL" appear in their names without 
prior written
apache-utils/copyright: nor may "mod_ssl" appear in their names without 
prior
php4/copyright: may "PHP" appear in their name, without prior written 
permission
subversion/copyright:nor may "Tigris" appear in their names without prior 
written

and a particularly evil one,

sudo/copyright:  may "Sudo" appear in their names without specific prior 
written

> >> > N. Acknowledgements in documentation
> >> 
> >> > The license for a free program may require that end-user
> >> > documentation which accompanies the program contains a short
> >> > acknowledgement that credits the author.
> > 
> > /usr/share/doc/apache/copyright
> > 
> > 3. The end-user documentation included with the redistribution,
> >if any, must include the following acknowledgment:
> >   "This product includes software developed by the
> >Apache Software Foundation (http://www.apache.org/)."
> >Alternately, this acknowledgment may appear in the software itself,
> >if and wherever such third-party acknowledgments normally appear.
> 
> They normally appear in /usr/share/doc/*/copyright, in Debian.  :-)  Does
> that make a difference?  I think this is a "loose" clause.

I think that's a reasonable interpretation.  For some reason, I was
interpreting "the software itself" as "the binary itself"; I suppose the
endlessly repeated arguments about "software" finally managed to confuse
me.

Are there any licenses requiring an acknowledgement in the documentation
which /usr/share/doc/*/copyright doesn't satisfy, which we should examine?
If not, "N. Acknowledgements in documentation" can probably be removed.

-- 
Glenn Maynard

Re: A radical approach to rewriting the DFSG

[Nathanael Nerode]

Glenn Maynard wrote:

> As a brief observation unrelated to this subthread: this also implicitly
> deals with the GPL#8 problem, by not requiring any special casing for
> the GPL at all.
> 
> On Tue, Jun 01, 2004 at 12:00:03AM +0100, Andrew Suffield wrote:
>> I'd like to append something like the following:
>> 
>> The license may not place further constraints on the naming or
>> labelling of the derivative work. This includes specifying the form of
>> such notices, or the manner in which derivative works must be named.
> 
> /usr/share/doc/apache/copyright
> 
> 5. Products derived from this software may not be called "Apache",
>nor may "Apache" appear in their name, without prior written
>permission of the Apache Software Foundation.
> 
> I think that this is something that shouldn't have been allowed, but has
> since become extremely widespread, and it probably wouldn't be productive
> to start rejecting it--it's a problem, but a relatively minor one.

It's been allowed mostly because they don't really enforce it.  For
instance, Debian's modified version of Apache, which is a derived work, has
"apache" in its name.  Furthermore, they've stated that they don't intend
to enforce it strictly, and it's not present in the new license.

I certainly wouldn't accept this clause in a license without additional
assurances from the copyright holder.  We said as much to X-Oz.

>> > N. Acknowledgements in documentation
>> 
>> > The license for a free program may require that end-user
>> > documentation which accompanies the program contains a short
>> > acknowledgement that credits the author.
>> 
>> That's horrible. This could mean that we have to include the blasted
>> things in the release notes. Survey of licenses and a tighter
>> restriction before we write this one in, please. I'm not sufficiently
>> familiar with such clauses to be able to pull one out of the air.
> 
> /usr/share/doc/apache/copyright
> 
> 3. The end-user documentation included with the redistribution,
>if any, must include the following acknowledgment:
>   "This product includes software developed by the
>Apache Software Foundation (http://www.apache.org/)."
>Alternately, this acknowledgment may appear in the software itself,
>if and wherever such third-party acknowledgments normally appear.

They normally appear in /usr/share/doc/*/copyright, in Debian.  :-)  Does
that make a difference?  I think this is a "loose" clause.

> 
> (I only realized recently how horrible this license is.)
> 

-- 
There are none so blind as those who will not see.

Re: A radical approach to rewriting the DFSG

[Nathanael Nerode]

>> Scripsit Nathanael Nerode <[EMAIL PROTECTED]>

>> > I would be quite comfortable allowing patent "retaliation"
>> > restrictions, but
>> > only if they were very carefully tailored.  Specifically, license
>> > rights must terminate only if the work is alleged to constitute patent
>> > infringement (no action based on unrelated causes), and they must
>> > terminate only for the person who alleged that it did (no harming third
>> > parties).


Andrew Suffield wrote:
> I recommend the following:
> 
> Phrase the proposed restriction in a way that is not specific to
> patents. Then construct a scenario where you apply it to copyright. Is
> it still an acceptable restriction?

The essence of what I would accept is this:

"If you claim, legally, that my work can't be distributed/used/modified
freely by people in general, then *you* can't distribute/use/modify my work
either".  A "if you think this should happen to everyone else, it should
happen to you too" clause.

This prevents people from actually literally taking free software
proprietary (not just derivative works, but the originals) -- this could
otherwise be done using patents.

-- 
There are none so blind as those who will not see.

Re: A radical approach to rewriting the DFSG#

[Andrew Suffield]

On Tue, Jun 01, 2004 at 02:33:32PM -0400, Glenn Maynard wrote:
> On Tue, Jun 01, 2004 at 10:52:22AM +0100, Andrew Suffield wrote:
> > > /usr/share/doc/apache/copyright
> > > 
> > > 3. The end-user documentation included with the redistribution,
> > >if any, must include the following acknowledgment:
> > >   "This product includes software developed by the
> > >Apache Software Foundation (http://www.apache.org/)."
> > >Alternately, this acknowledgment may appear in the software itself,
> > >if and wherever such third-party acknowledgments normally appear.
> > 
> > We're invoking the second part of this across the board. The first one
> > alone would not be free; fortunately it is a disjunction, allowing us
> > to ignore the first part.
> 
> The second part ("Alternately ...") makes it easier for Debian, but doesn't
> make it more free.  Lots of software runs on hardware without the capability
> to display text (eg. embedded use), and their only choice is the first option.

I would interpret "wherever such third-party acknowledgements normally
appear" to mean /usr/share/doc/apache/copyright or similar - stuff the
thing in the binary package in a suitable file, and you're done.

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


signature.asc
Description: Digital signature

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On Sun, 30 May 2004 13:24:55 +0200 Francesco Poli wrote:

> > Comments will be appreciated - both about the general angle of
> > attack, and about my specific draft. I have probably forgotten about
> > a detail here and there.
> 
> First comments

Antoher couple of comments:

* "A derived work can be anything from a slightly modified versions of
the original work to a completely new work that includes parts of the
original work in a new contexts. The term also includes translation of
works into other languages, compilation of programs to machine code or
bytecode, and other transformations that prepare the work for being
used."
typo: s/versions/version/
typo: s/contexts/context/
proposed generalization: s/bytecode/pseudo-code/
   or maybe  s/bytecode/intermediate languages/

* "Rationale: A user in a remote location (say, any computer that is not
connected to the Internet) must have the freedom to contract with a
business to create a copy of the software and transport it to him. If
the licensing of the software prevents the business from getting a
profit out of this, the software is not truly free."
question: why such a complicated example?
Free software is not against business. It just aims to a different (and
better) kind of business (with respect to proprietary-software based
business).
In other words: if commercial distribution is prohibited by the license,
then it's clearly non-free software.
I cannot see the need for a strange example to explain this...

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgp9Eqt9DBVo8.pgp
Description: PGP signature

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On Mon, 31 May 2004 01:04:36 -0400 Glenn Maynard wrote:

> 2. Source code
>   "The source for a work is a machine-readable form that is
>   appropriate for modifying the work or inspecting its structure and
>   inner workings."
> 
> Is there a benefit to using a different definition than the GPL?

Personally, I don't think there is... I would prefer the definition of
source code adopted by the GPL: it's less vague.

> 
> One case where this seems different is images.  For example, I have
> several PNGs, generated by Photoshop.  The PNG itself is appropriate
> for modifying the work, but it's not the preferred form for
> modification. Going by feel, it's not the source of the work at all.

I agree. The PNG format is not source, if it's generated from some other
format. It can be source, though, when editing is being performed
directly on it.
In other words, the most suitable definition of source code seems the
"preferred form for making modifications".

> 
> This also reveals a case that hasn't been resolved: do we expect
> source for PNGs, when such a form exists?

I think we should.

> In practice, we don't,

Strange!  :-|

> and I tend to classify it as "that would be nice, but it's not a
> worthwhile battle".

Why? What if someone wants to modify those images?

> Another major case of this (and one which is less
> ambiguous) is fonts. It would be nice to find a consensus on these,
> rather than having a new set of guidelines that still doesn't address
> the issue.

I thought that DFSG#2 was already addressing the issue ("The program
must include source code").

> 
> (I'll admit that "I don't want Debian to have to drop most of its
> high- quality fonts" is probably a major factor in my opinion on this,
> which sounds somewhat like "I don't want Debian to have to drop
> Netscape".)

Are there so many high-quality fonts with no actual source code in
Debian?
More important: are there so few high-quality fonts with source
available in Debian?


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpSF4aHr1OfI.pgp
Description: PGP signature

Re: A radical approach to rewriting the DFSG#

[Glenn Maynard]

On Tue, Jun 01, 2004 at 10:52:22AM +0100, Andrew Suffield wrote:
> > /usr/share/doc/apache/copyright
> > 
> > 3. The end-user documentation included with the redistribution,
> >if any, must include the following acknowledgment:
> >   "This product includes software developed by the
> >Apache Software Foundation (http://www.apache.org/)."
> >Alternately, this acknowledgment may appear in the software itself,
> >if and wherever such third-party acknowledgments normally appear.
> 
> We're invoking the second part of this across the board. The first one
> alone would not be free; fortunately it is a disjunction, allowing us
> to ignore the first part.

The second part ("Alternately ...") makes it easier for Debian, but doesn't
make it more free.  Lots of software runs on hardware without the capability
to display text (eg. embedded use), and their only choice is the first option.

-- 
Glenn Maynard

Re: A radical approach to rewriting the DFSG#

[Andrew Suffield]

On Mon, May 31, 2004 at 07:31:51PM -0400, Glenn Maynard wrote:
> On Tue, Jun 01, 2004 at 12:00:03AM +0100, Andrew Suffield wrote:
> > I'd like to append something like the following:
> > 
> > The license may not place further constraints on the naming or
> > labelling of the derivative work. This includes specifying the form of
> > such notices, or the manner in which derivative works must be named.
> 
> /usr/share/doc/apache/copyright
> 
> 5. Products derived from this software may not be called "Apache",
>nor may "Apache" appear in their name, without prior written
>permission of the Apache Software Foundation.

Bletch. Still, no "derived works must have NMU versions" clauses.

> > > N. Acknowledgements in documentation
> > 
> > > The license for a free program may require that end-user
> > > documentation which accompanies the program contains a short
> > > acknowledgement that credits the author.
> > 
> > That's horrible. This could mean that we have to include the blasted
> > things in the release notes. Survey of licenses and a tighter
> > restriction before we write this one in, please. I'm not sufficiently
> > familiar with such clauses to be able to pull one out of the air.
> 
> /usr/share/doc/apache/copyright
> 
> 3. The end-user documentation included with the redistribution,
>if any, must include the following acknowledgment:
>   "This product includes software developed by the
>Apache Software Foundation (http://www.apache.org/)."
>Alternately, this acknowledgment may appear in the software itself,
>if and wherever such third-party acknowledgments normally appear.

We're invoking the second part of this across the board. The first one
alone would not be free; fortunately it is a disjunction, allowing us
to ignore the first part.

Hell, the first part would probably fail DFSG #9 (contamination).

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


signature.asc
Description: Digital signature

Re: A radical approach to rewriting the DFSG

[Raul Miller]

On Mon, May 31, 2004 at 10:54:13PM +0100, Andrew Suffield wrote:
> Phrase the proposed restriction in a way that is not specific to
> patents. Then construct a scenario where you apply it to copyright. Is
> it still an acceptable restriction?

I think this would be a mistake.

Patents are more different from copyrights than use is from copying.

With copyrights, there is [fairly clear] copyright holder.  This is the
author(s) or someone who has been assigned copyright.

With patents, it's not clear what patents are relevant, who the patent
holders are, nor whether the patents are valid.

Additionally, most copyrights are valid -- we can safely assume that if
there is no copyright notice on something that we can't redistribute
it, and if there is we have a reasonable certainty that it's correct.
Most patents are not valid -- we can't assume that the absense of a patent
license means that we can't distribute something and we can't assume that
the presence of patent information means that the patent is valid (in the
U.S., when a patent issue is taken to court, it's assumed that the patent
is valid and it's the responsibility of the defendant to prove otherwise,
but it's still the case that most patents issued on software are issued
without any consideration of what's obvious nor of what prior art exists).

Historically, that's meant that we've been careful about copyrights,
and that we've largely ignored patents except where someone has been
active in claiming that a patent applies to some class of software.

And that's another thing that's different about patents -- a patent
typically covers many programs, including those which haven't been
written yet, and including those which are written in complete ignorance
of the patent.

-- 
Raul

Re: A radical approach to rewriting the DFSG

[Glenn Maynard]

As a brief observation unrelated to this subthread: this also implicitly
deals with the GPL#8 problem, by not requiring any special casing for
the GPL at all.

On Tue, Jun 01, 2004 at 12:00:03AM +0100, Andrew Suffield wrote:
> I'd like to append something like the following:
> 
> The license may not place further constraints on the naming or
> labelling of the derivative work. This includes specifying the form of
> such notices, or the manner in which derivative works must be named.

/usr/share/doc/apache/copyright

5. Products derived from this software may not be called "Apache",
   nor may "Apache" appear in their name, without prior written
   permission of the Apache Software Foundation.

I think that this is something that shouldn't have been allowed, but has
since become extremely widespread, and it probably wouldn't be productive
to start rejecting it--it's a problem, but a relatively minor one.

> > N. Acknowledgements in documentation
> 
> > The license for a free program may require that end-user
> > documentation which accompanies the program contains a short
> > acknowledgement that credits the author.
> 
> That's horrible. This could mean that we have to include the blasted
> things in the release notes. Survey of licenses and a tighter
> restriction before we write this one in, please. I'm not sufficiently
> familiar with such clauses to be able to pull one out of the air.

/usr/share/doc/apache/copyright

3. The end-user documentation included with the redistribution,
   if any, must include the following acknowledgment:
  "This product includes software developed by the
   Apache Software Foundation (http://www.apache.org/)."
   Alternately, this acknowledgment may appear in the software itself,
   if and wherever such third-party acknowledgments normally appear.

(I only realized recently how horrible this license is.)

-- 
Glenn Maynard

Re: A radical approach to rewriting the DFSG

[Andrew Suffield]

On Tue, Jun 01, 2004 at 12:06:15AM +0200, Francesco Poli wrote:
> > As long as there is no
> > restriction on how much additional software must be included, the
> > requirement could be satisfied by either:
> [...]
> > * a one byte file containing "w", which would be a valid sh script to
> > run the "w" command.
> 
> Wow! TSSSITHOCS!
> (The shortest shell-script in the history of computer science)
>   ;-)

No, I believe that is the same as what will probably be the last
"smallest quine" winner of the IOCCC: a zero-byte file.

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


signature.asc
Description: Digital signature

Re: A radical approach to rewriting the DFSG

[Andrew Suffield]

On Sun, May 30, 2004 at 06:28:12AM +0100, Henning Makholm wrote:
> I have been toying with the possibility of rewriting the DFSG such
> that it enumerates which things a free license *can* do, rather than
> just give examples of things it *cannot*. I think that such a revision
> could get the guidelines to be much closer to the *actual* practise of
> how we evaluate licenses than if we simply make local adjustments to
> the current DFSG. The downside is that the whole truth cannot be
> condensed into the "ten commandments" schema of the current DFSG.
> 
> My results so far are at
>
> 
> Comments will be appreciated - both about the general angle of attack,
> and about my specific draft. I have probably forgotten about a detail
> here and there.

I think that we should retain the DFSG in their current form (but
revised), but it would seem viable to *add* something like this as
another document with equivalent priority. As always, interpretation
of the boundary cases falls to us; we're writing guidelines here, not
a program.

That aside, here's a few observations of the forest:

> A. The right to use

> A user must have the right to execute the work on a computer if it is
> a program; to display and read it if it is a text, and so forth.

This appears to fail my old test:

---
Your document is not free unless its license permits me to print it
out and beat you with the hardcopy, as an expression of my opinion of
the quality of your work.
---

This paragraph seems to explain the boundary cases but not the core
one. I'd be happier with something like this:

A user must have the right to use the work, for any purpose. For
example, if it is a computer program, this would include the right to
execute the work on a computer if it is a program; if it is a text,
this would include the right to display and read it in any form.

> B. The right to copy and distribute

> A user must have the right to create copies of the work in any
> medium, and to give such copies to whomever he decides to distribute
> to.

Missed the most important part here, too. Let's haul 5A up here;
duplication is not really an issue for this document:

A user must have the right to create unlimited copies of the work in
any medium, and to give such copies to whomever he decides to
distribute to. It must be permitted for these copies to be given
without requiring a royalty or other fee from any parties involved.

> D. The right to distribute derived works

> A user must have the right to give copies of derived works created
> by himself or others to whomever he decides to distribute to.

And again:

A user must have the right to give copies of derived works created by
himself or others to whomever he decides to distribute to. The user
must be allowed to distribute these derived works under the terms of
the original license.

> 6. Patents

> [Something needs to be said here.] 

I disagree on general principle. We should not concern ourselves with
specific laws in this fashion; rather, we should concern ourselves
with what you are and are not permitted to do, under *any* relevant
laws. That applies to copyright as much as patent law.


Now some tree-gazing:

> The source for a work is a machine-readable form that is appropriate
> for modifying the work or inspecting its structure and inner
> workings. It is usually immediately clear what the source form is,
> but sometimes it is a judgement call what to consider source.

Are there actually any known cases where it is not bloody obvious?
Non-free advocates like to throw this around, but all their examples
are immediately seized upon and dissected, and the "source" turns out
to be obvious after all once you have stripped away all the confusion
they wrapped the problem in. I can see what the source to an image or
font is, even if some people want to close their eyes and stick their
fingers in their ears. I'd rather drop this if possible; I don't want
to falsely encourage the notion that this is a difficult thing to
determine.

> D. Forced distribution of source with binaries

> The right to distribute the work (or derivates) may exclude
> distribution in forms other than source where the distribution is
> not accompanied with the source.

That reads awfully.

The right to distribute the work in forms other than source may be
made conditional on the inclusion of the source with any such
distribution.

And "conditional" is just ambiguous enough to capture things like the
complicated clause 3 of the GPL.

> E. Integrity of the original work

> The license may require derived works to carry notices that make it
> clear that they are not the original.

> The license may require derived works to carry a different name or
> version number from the original work.

> However, such requirements may not be constructed such that they
> interfere with the usual use of the derived work (assuming that the
> derived work is of the same kind as the original one).

I

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On Sun, 30 May 2004 09:06:18 -0700 Josh Triplett wrote:

> Francesco Poli wrote:
> > * question: "Such a restriction is exactly as silly as it sounds.
> > However, some otherwise free programs come with licenses that
> > specify that the program must not be sold alone but only as part of
> > an aggregate software distribution."
> > Do you regard those programs as free? Is there any consensus on d-l
> > about this awkward restriction?
> 
> I believe the general consensus is that since the requirement is so
> trivially satisfiable, it is considered free.

Ah, I see your argument. Well, you're right that a trivial workaround
exists for such a restriction. As a consequence, the restriction is
almost absent. Awkward, but almost absent... 

> As long as there is no
> restriction on how much additional software must be included, the
> requirement could be satisfied by either:
[...]
> * a one byte file containing "w", which would be a valid sh script to
> run the "w" command.

Wow! TSSSITHOCS!
(The shortest shell-script in the history of computer science)
  ;-)


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgp7EIZAdLjRY.pgp
Description: PGP signature

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On Mon, 31 May 2004 01:07:02 -0400 Glenn Maynard wrote:

[...]
> Part 5 seems like it should be an appendix, and not part of the core
> guidelines.

I agree: much better to separate those /examples/ from the actual
guidelines.


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgphRAOjiWbvT.pgp
Description: PGP signature

Re: A radical approach to rewriting the DFSG

[Andrew Suffield]

On Mon, May 31, 2004 at 03:27:06AM +0100, Henning Makholm wrote:
> Scripsit Nathanael Nerode <[EMAIL PROTECTED]>
> 
> > I actually don't think the GPL Preamble is entirely legally irrelevant; it
> > would presumably color the legal interpretation of the GPL if a question of
> > interpretation came up.
> 
> Hm, what about "a non-legal piece of text", then?

The word you are seeking is "normative".

> > I would be quite comfortable allowing patent "retaliation" restrictions, but
> > only if they were very carefully tailored.  Specifically, license rights
> > must terminate only if the work is alleged to constitute patent
> > infringement (no action based on unrelated causes), and they must terminate
> > only for the person who alleged that it did (no harming third parties).
> 
> The trouble with patents - in this context - is that we don't really
> have any solid consensus to be codified.
> 
> I'm fairly certain, however, that the *current* consensus is that a
> free license cannot retailiate against patent attacks by revoking
> *copyright* licenses. I'm not quite energetic enough tonight to try to
> track down list referneces, but can anyone remember a case where this
> was *not* the conclusion?

Frankly, I think the whole notion of rolling patent and copyright
licenses into a single document is monumentally stupid and fraught
with trouble. If you need to write a patent license, write a
*distinct* license.

That aside, we've never actually special-cased copyright before in our
phrasing or application of the DFSG, and I don't think we should do
this for patents.

I recommend the following:

Phrase the proposed restriction in a way that is not specific to
patents. Then construct a scenario where you apply it to copyright. Is
it still an acceptable restriction?

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


signature.asc
Description: Digital signature

Re: A radical approach to rewriting the DFSG

[Glenn Maynard]

I've asked you in the past to fix your mailer, so it doesn't break
threads.  You have laid waste to several large threads on d-devel.
You're still doing so.  Please fix it; breaking threads is breaking
conversations, when threads become large.

On Mon, May 31, 2004 at 09:47:28AM -0300, Humberto Massa wrote:
> > Is there a benefit to using a different definition than the GPL?
> 
> You've said it below. The "preferred form for modification" is vague as 
> to "whom does prefer it"? "Appropriate" is a far less ambiguous term, 
> and the rest of the phrase ("for modifying ... and inspecting ...") 
> makes it IMVHO perfectly unambiguous.

To the person modifying it.  Not the original author; if I modify
a work, and in the process of doing so, my preferred form changes,
then the source changes.

> > One case where this seems different is images. For example, I have
> > several PNGs, generated by Photoshop. The PNG itself is appropriate
> > for modifying the work, but it's not the preferred form for
> > modification. Going by feel, it's not the source of the work at all.
> 
> But it is (the source), according to the definition phrased above. 

It's source according to my interpretation of the word "source".  The
example is intended to show that I believe the definition is wrong (too
loose), at least for this case.  I think using a definition of "source"
that differs notably from common use is going to lead to confusion at best.

> Or not? It's possible that information is lost (like layers?) H.

PSDs store layers, as well as a lot of other things: text layers (text
string + font settings), filtering settings, etc.  However, the resulting
PNG is still a form appropriate for modifying the work; I've modified
many such PNGs.  (Indeed, after doing so, the source for that PNG becomes
the PNG.)

> Hehe. Anyway, I think in another thread we concluded (or I concluded ??? 
> makes a lot of difference) that .ttf font files and the metafont format 
> are completely interchangeable, because you can represent the same 
> information in both formats. IIRC, the "more-open" metafont format is 
> more expressive, too, so, there is no need to worry about fonts.

To conclude that .TTF files are source, I'd want to see a person experienced
in professional font editing saying "yes, a .TTF file is the form I'd ask
for from the original author if I wanted to make modifications to a font".
If a font is actually authored in some other format (even if it's for
a proprietary tool), and the resulting TTFs aren't equivalent, then it's
simply not source.

Another way of looking at it: if the original author lost the proprietary
data file, would he curse and start looking for backups, or would he just
load up the TTF?  If the former, then the TTF is not source.  (If the
latter, it's probably source, unless the author doesn't really care about
the font anymore.)

(I don't know much about font hinting, but I'd suspect that a real source
format for fonts might include things like comments: "this is hinted this
way for this reason".)

I'm still not claiming that we should demand such source files or not--"what
is source" vs "do we want that source" are two distinct questions, and we
can't answer the second without being able to answer the first.

-- 
Glenn Maynard

Re: A radical approach to rewriting the DFSG

[Humberto Massa]

@ 31/05/2004 02:21 : wrote Glenn Maynard :


 2. Source code "The source for a work is a machine-readable form that
 is appropriate for modifying the work or inspecting its structure and
 inner workings."

 Is there a benefit to using a different definition than the GPL?



You've said it below. The "preferred form for modification" is vague as 
to "whom does prefer it"? "Appropriate" is a far less ambiguous term, 
and the rest of the phrase ("for modifying ... and inspecting ...") 
makes it IMVHO perfectly unambiguous.



 One case where this seems different is images. For example, I have
 several PNGs, generated by Photoshop. The PNG itself is appropriate
 for modifying the work, but it's not the preferred form for
 modification. Going by feel, it's not the source of the work at all.



But it is (the source), according to the definition phrased above. Or 
not? It's possible that information is lost (like layers?) H.



 This also reveals a case that hasn't been resolved: do we expect
 source for PNGs, when such a form exists? In practice, we don't, and
 I tend to classify it as "that would be nice, but it's not a
 worthwhile battle". Another major case of this (and one which is less
 ambiguous) is fonts. It would be nice to find a consensus on these,
 rather than having a new set of guidelines that still doesn't address
 the issue.

 (I'll admit that "I don't want Debian to have to drop most of its
 high- quality fonts" is probably a major factor in my opinion on
 this, which sounds somewhat like "I don't want Debian to have to drop
 Netscape".)



Hehe. Anyway, I think in another thread we concluded (or I concluded ??? 
makes a lot of difference) that .ttf font files and the metafont format 
are completely interchangeable, because you can represent the same 
information in both formats. IIRC, the "more-open" metafont format is 
more expressive, too, so, there is no need to worry about fonts.


--
br,M

Re: A radical approach to rewriting the DFSG

[Henning Makholm]

Scripsit Glenn Maynard <[EMAIL PROTECTED]>

> By my (poor) understanding, contract law and copyright law are not the
> same; perhaps "contract" can be removed. Also, perhaps s/country/region/
> ("the laws of California"); s/mean/means/.

Yup. Braino, fixed.

-- 
Henning Makholm  "I consider the presence of the
  universe to be a miracle. The universe
 and everything in it. Can you deny it?"

Re: A radical approach to rewriting the DFSG

[Glenn Maynard]

"In contrast, a choice-of-law merely specifies which country's contract
law will be used to resolve disputes over what the license text mean."

By my (poor) understanding, contract law and copyright law are not the
same; perhaps "contract" can be removed.  Also, perhaps s/country/region/
("the laws of California"); s/mean/means/.

-- 
Glenn Maynard

Re: A radical approach to rewriting the DFSG

[Glenn Maynard]

On Mon, May 31, 2004 at 12:49:17AM -0400, Raul Miller wrote:
> > I had hoped that the general approach would make this unnecessary -
> > the text ought to be framed such that it speaks only of the freedom of
> > the actual license grant made by the author. 
> 
> Part 5 doesn't seem to fit this description.

Part 5 seems like it should be an appendix, and not part of the core
guidelines.

-- 
Glenn Maynard

Re: A radical approach to rewriting the DFSG

[Glenn Maynard]

On Mon, May 31, 2004 at 04:33:47AM +0100, Henning Makholm wrote:
> I understand and respect your opinion. However, it seems likely that a
> GR to "update" the DFSG *will* be proposed by someone within the next
> handful (or two) of months.  I think that if we are to update it at
> all, it deserves being done properly.

Another use of this is as another way to examine the DFSG: any case
where the result of a license evaluation under these guidelines (at
least after some more polishing) differs from one under the DFSG
is an interesting one to consider.  ("What do we really want?")

> > I think it's a feature of the DFSG that it does not reference any
> > particular set of laws (copyright, patent, trademark).
> 
> There is space in my draft to say something about patents. It'll
> probably end up referring back to the other sections, after specifying
> roughly that we're only interested in patents that are actively
> enforced and not obviously invalid.

What I'm suggesting is that the fundamental core of the guidelines
(which feels like part 3) not mention any of these.  I'm not sure if
that's as important with this approach as it was with the DFSG, though.

>N. Acknowledgements in documentation
> 
>  The license for a free program may require that end-user
>  documentation which accompanies the program contains a short
>  acknowledgement that credits the author.

What about this?

  5. Redistributions of any form whatsoever must retain the following
 acknowledgment:
 "This product includes the Zend Engine, freely available at
 http://www.zend.com";

> > 4. j: "Specific exception for GPL #2(c)"
> 
> > A note that this does not apply to verbatim statements may be appropriate.
> 
> Hmm, for some kinds of clauses we accept verbatim statements, and for
> some we do not. They are all obnoxious anyway; is it really worth the
> extra complexity of the guidelines [1] to insist on preserving the
> freedom to edit exactly in the cases where we happen to have it now?

I'm just looking for the 4j exception to be limited more closely to what
is needed for the GPL.  I can't think of any licenses that require a verbatim
statement on startup, but 4j seems to allow it.

(Of course, I'm being picky on this because I personally think that restriction
is onerous--as I've argued in the past--and that we should be careful to
prevent this boundary case from being nudged any further.)

> Perhaps a compromise could be to say that all that can be required is
> a *short* notice?

Since the clause already makes reference to the GPL (perhaps it should
say "GPL 2.0"), perhaps "... most ordinary way, under the terms of
GPL 2.0 #2(c)"?  That would explicitly say that the restriction can not
be more restrictive than what the GPL requires.

E. ... "The license may require derived works to carry notices that make
it clear that they are not the original."

Should this also allow requiring dating, which GPL #2(a) requires?

Also, I believe GPL2a does not prohibit these notices from being removed
in the future, which is important.  Assuming the "revision control logs
count as carried notices" interpretation is valid, if I can't remove
the notices, then I'd have to copy those notices into the file for source
snapshots.  However, allowing removal doesn't seem to be required by 4E.

... "The license may require derived works to carry a different name or
version number from the original work."

Here's a sticky one:

   5. Products derived from this software may not be called "Apache",
  nor may "Apache" appear in their name, without prior written
  permission of the Apache Software Foundation.

This is definitely overreaching; it prohibits code reuse in any project
named "Apache Helicopter Flight Simulator".  Since this is the Apache
license, lots of other projects have followed their lead on this clause,
too.

> > /usr/share/doc/libkrb53/copyright
> >   WARNING: Retrieving the OpenVision Kerberos Administration system
> >   source code, as described below, indicates your acceptance of the
> >   following terms.
> 
> Argh! I doubt that a court will agree with that statement. And I'm not
> sure that it is free. Has this been discussed on debian-legal before?
> Google says no. FWIW, the terms that one has to accept are very free
> themselves.

I only noticed this while grepping for "acceptance" in
/usr/share/doc/*/copyright.  (I'm starting to wish for a package,
even non-free, containing all copyright files; /usr/share/doc/XXX/copyright ->
/usr/share/licenses/XXX.)

2. Source code
  "The source for a work is a machine-readable form that is appropriate
  for modifying the work or inspecting its structure and inner workings."

Is there a benefit to using a different definition than the GPL?

One case where this seems different is images.  For example, I have
several PNGs, generated by Photoshop.  The PNG itself is appropriate
for modifying the work, but it's not the preferred form for modification.
Going by feel, it's n

Re: A radical approach to rewriting the DFSG

[Raul Miller]

On Mon, May 31, 2004 at 02:48:19AM +0100, Henning Makholm wrote:
> I had hoped that the general approach would make this unnecessary -
> the text ought to be framed such that it speaks only of the freedom of
> the actual license grant made by the author. 

Part 5 doesn't seem to fit this description.

-- 
Raul

Re: A radical approach to rewriting the DFSG

[Henning Makholm]

Scripsit Lewis Jardine <[EMAIL PROTECTED]>

> Maybe an explicit statement of this point would be a useful addition,
> possibly in the introduction?

I think you're right in general, but I'm not happy with your exact
text:

> Note that the /license/ is the terms of the /license text/ as
> interpreted by the author, _not_ the terms of the /license text/ as
> interpreted by any third-party. Any /license text/, even if free
> when interpreted in the most common manner, may be interpreted by
> the author in such a way as to make the /license/ non-free. "

I think it would be bad idea to entrench the "the author is always
right" rule of thumb in the DFSG itself. We *usually* respect the
author's wishes, but in a tentacles-of-evil situation we may need to
explicitly disagree with a strange license-text interpretation that
the author acquires *after* the Debian system has become dependent on
his work.

Instead, I have written:

If the author has granted rights by stating that a specific
license text applies to the work, the word license
refers to the meaning of the license text in the specific
context of the particular work.

Thus, even if the same license text applies to two
different works, one work can be free and the other non-free,
because of differences in the way the authors apply a generic
license text, or because the meaning of the licence text
explicitly depends on inherent properties of the licensed work.

-- 
Henning Makholm  "*Tak* for de ord. *Nu* vinker nobelprisen forude."

Re: A radical approach to rewriting the DFSG

[Henning Makholm]

Scripsit Glenn Maynard <[EMAIL PROTECTED]>

> FWIW, I don't particularly like this idea.  The DFSG, in practice,
> is working very well, and the "case law" developing around it is
> practical and, at least on debian-legal, well-understood.

I understand and respect your opinion. However, it seems likely that a
GR to "update" the DFSG *will* be proposed by someone within the next
handful (or two) of months.  I think that if we are to update it at
all, it deserves being done properly.

Personally I ought to like the current status quo - it makes me part
of an initialistic priesthood which knows the Right Way to read our
obscure sacred text. More power to us!

It is true that the current DFSG plus our collective memory is fairly
adequate as an instrument for reaching a desicion when somebody brings
a license to us for scrutiny.

However, it is not easy for outsiders to understand the current DFSG.
I suspect that many of the non-free licenses we see are written by
people who *try* to write a license that meets the DFSG (or the OSD),
just while implementing as much CYA as possible. Then they release
their software under a not-quite-free license and we have to keep it
out of Debian. We get to keep Debian clean, but apart from that the
upstream loses, we lose, and our users lose.

It would be better if an upstream license author had a document to
refer to that was clearer about what can and can't be done in a free
license. We now have the debian-legal FAQ, which is a tremendous
improvement over the state of a year ago (and will be even greater
once it gets a link from www.d.o/legal, by the way).

But it would be even better if the actual guidelines were less
obscure. I'm trying to cater for a wannabe license author who goes out
on the web and grabs every set of semi-formal rules he can find about
what software freedom means, and prints them out before he goes to
that meeting with the Legal Department. He probably does not read FAQs
unless he becomes *aware* that he has a question.

> Perhaps you could call this the "Henning Free Stuff Guidelines" for now?
> Having the same abbreviation is inconvenient.

They are now "DFSG^HM".

> I think it's a feature of the DFSG that it does not reference any
> particular set of laws (copyright, patent, trademark).

There is space in my draft to say something about patents. It'll
probably end up referring back to the other sections, after specifying
roughly that we're only interested in patents that are actively
enforced and not obviously invalid.

However, before I can write that section, I need to decide what I
think our consensus about patent retribution traps is.

As for trademarks: To the best of my knowledge we do not even now
require trademarks to be licensed DFSG-freely.

> What about the old Apache license:

> 3. The end-user documentation included with the redistribution,
>if any, must include the following acknowledgment:
>   "This product includes software developed by the
>Apache Software Foundation (http://www.apache.org/)."
>Alternately, this acknowledgment may appear in the software itself,
>if and wherever such third-party acknowledgments normally appear.

> Any exception for this should be careful; some would try to require inclusion
> of a full page of funding and sponsorship credits, for example.

Current attempt:

   N. Acknowledgements in documentation

 The license for a free program may require that end-user
 documentation which accompanies the program contains a short
 acknowledgement that credits the author.

> 4. j: "Specific exception for GPL #2(c)"

> A note that this does not apply to verbatim statements may be appropriate.

Hmm, for some kinds of clauses we accept verbatim statements, and for
some we do not. They are all obnoxious anyway; is it really worth the
extra complexity of the guidelines [1] to insist on preserving the
freedom to edit exactly in the cases where we happen to have it now?

Perhaps a compromise could be to say that all that can be required is
a *short* notice?

[1] It increase the complexity of my attempt to write down explicit
guidelines, but it is also already increases the complexity of the
line we're implicitly drawing while we interpret the current DFSG.

> > ..."A free license cannot require that the user notices the author prior

> Did you mean to suggest s/notices/notify/?

Yes. Fixed.

> > (The license can specify that exercising the rights granted by the license,
> > absent alternative permissions, will be interpreted as acceptance of the
> > license.)

> A nitpick: does "rights granted by the license" include grants of rights that
> users have anyway?

It is not meant to, certainly. I edited to:

   ... will be interpreted by the author as acceptance of its
   terms. It cannot unilaterally make this interpretation legally
   binding, however.

> /usr/share/doc/libkrb53/copyright
>   WARNING: Retrieving the OpenVision Kerberos Administration system
>   source code, as desc

Re: A radical approach to rewriting the DFSG

[Glenn Maynard]

On Mon, May 31, 2004 at 03:27:06AM +0100, Henning Makholm wrote:
> I understand what you're saying, but when I attempt to explain it such
> that it is clear for an uninitiated reader what the problem is, it
> gets very convoluted. Can't we just hope that an attempt to ITP a
> license text as a work in its own right will get rejected as pointless
> by the ftpmasters, such that this does not become a DFSG matter in the
> first place?

Such a package would be far more useful to me ("archive of free and non-
free licenses") than some other packages (eg. bible-kjv-text).  For example,
I frequently refer to /usr/share/common-licenses to look up clauses; a
package installing other free and non-free licenses in there would be
helpful.  So, it might be hard to reject them on the basis that they're
pointless.

> I'm fairly certain, however, that the *current* consensus is that a
> free license cannot retailiate against patent attacks by revoking
> *copyright* licenses. I'm not quite energetic enough tonight to try to
> track down list referneces, but can anyone remember a case where this
> was *not* the conclusion?

I think that many people are arguing this, but that there isn't consensus.
Personally, I'm undecided: I think patents are such a serious threat to
free software that using one of the only levers we have as a defense is
sensible, but I agree that if at all, it needs to be done right (eg. not
preventing defensive patent use, etc).

Also, if "done right", it may not be very effective.  Would Fraunhofer really
care if they lost the right to use LAME?[1]  If they lost the right to use a
huge chunk of free software due to one lawsuit, they might, but I think there
is strong consensus that terminating a license due to an unrelated lawsuit is
going too far.  A litigation firm holding patents may not actually use the
technology at all, anyway.

[1] poor example, since this is more of a defense against stealth patents;
I just don't have a good example of that handy.

-- 
Glenn Maynard

Re: A radical approach to rewriting the DFSG

[Henning Makholm]

Scripsit Nathanael Nerode <[EMAIL PROTECTED]>

> I actually don't think the GPL Preamble is entirely legally irrelevant; it
> would presumably color the legal interpretation of the GPL if a question of
> interpretation came up.

Hm, what about "a non-legal piece of text", then?

> Typo, should be "derivatives", not "derivates".  But it would be better to
> rewrite the sentence.

Well, yes. It now reads: "Several popular license texts explicitly
forbid the creation of works derived from the license text itself."

> Also, it should be made clear that this exception does not apply to license
> texts shipped on their own, rather than as the licenses for something.

I understand what you're saying, but when I attempt to explain it such
that it is clear for an uninitiated reader what the problem is, it
gets very convoluted. Can't we just hope that an attempt to ITP a
license text as a work in its own right will get rejected as pointless
by the ftpmasters, such that this does not become a DFSG matter in the
first place?

> Also, it's not just license texts which get a special break; other legal
> recitations, sich as warranty disclaimers, are also allowed to be
> non-modifiable.

Hm, most warranty disclaimers that would otherwise need this are not
sufficiently original that copyright *can* prevent them from being
reused, are they?

Well, I think I'll just define the disclaimer as being part of the
license text. That should solve it.

> Add clarification:
> (The license can specify that exercising the rights granted by the license,
> absent alternative permissions, will be interpreted as acceptance of the
> license.)

Added, with minor editing.

> Clarifications here about the exact meaning of 'venue' vs. 'law', etc, so
> that the usual confusions don't pop up?

Clarification added.

> And a non-nitpick.
 
> I would be quite comfortable allowing patent "retaliation" restrictions, but
> only if they were very carefully tailored.  Specifically, license rights
> must terminate only if the work is alleged to constitute patent
> infringement (no action based on unrelated causes), and they must terminate
> only for the person who alleged that it did (no harming third parties).

The trouble with patents - in this context - is that we don't really
have any solid consensus to be codified.

I'm fairly certain, however, that the *current* consensus is that a
free license cannot retailiate against patent attacks by revoking
*copyright* licenses. I'm not quite energetic enough tonight to try to
track down list referneces, but can anyone remember a case where this
was *not* the conclusion?

> Well, these were just some thoughts.  Have fun with them.

Thanks.

-- 
Henning Makholm  "Also, the letters are printed. That makes the task
of identifying the handwriting much more difficult."

Re: A radical approach to rewriting the DFSG

[Lewis Jardine]

Henning Makholm wrote:

Scripsit Raul Miller <[EMAIL PROTECTED]>


You might want to add a general statement about optional clauses which
require release-time steps from the "author", which would cause problems
if invoked, but which haven't been invoked.



I had hoped that the general approach would make this unnecessary -
the text ought to be framed such that it speaks only of the freedom of
the actual license grant made by the author. It does not even [1]
consider the question of a generic license *text* being free or not.


Maybe an explicit statement of this point would be a useful addition, 
possibly in the introduction?


" The /license/ means the authors' act of granting of basic rights and 
possibly other rights on specific conditions."


" The /license/ means the authors' act of granting of basic rights and 
possibly other rights on specific conditions. Note that the /license/ is 
the terms of the /license text/ as interpreted by the author, _not_ the 
terms of the /license text/ as interpreted by any third-party. Any 
/license text/, even if free when interpreted in the most common manner, 
may be interpreted by the author in such a way as to make the /license/ 
non-free. "




[1] I.e.: if it does it is a bug.




--
Lewis Jardine
[EMAIL PROTECTED]

Re: A radical approach to rewriting the DFSG

[Henning Makholm]

Scripsit Raul Miller <[EMAIL PROTECTED]>

> You might want to add a general statement about optional clauses which
> require release-time steps from the "author", which would cause problems
> if invoked, but which haven't been invoked.

I had hoped that the general approach would make this unnecessary -
the text ought to be framed such that it speaks only of the freedom of
the actual license grant made by the author. It does not even [1]
consider the question of a generic license *text* being free or not.

[1] I.e.: if it does it is a bug.

-- 
Henning Makholm "Jeg forstår mig på at anvende sådanne midler på
   folks legemer, at jeg kan varme eller afkøle dem,
som jeg vil, og få dem til at kaste op, hvis det er det,
  jeg vil, eller give afføring og meget andet af den slags."

Re: A radical approach to rewriting the DFSG

[Josh Triplett]

Glenn Maynard wrote:
> What about the old Apache license:
> 
> 3. The end-user documentation included with the redistribution,
>if any, must include the following acknowledgment:
>   "This product includes software developed by the
>Apache Software Foundation (http://www.apache.org/)."
>Alternately, this acknowledgment may appear in the software itself,
>if and wherever such third-party acknowledgments normally appear.
> 
> A lot of other software uses this, eg. Subversion.  It has three problems:
> it gives a verbatim text (eg. no translations, can't fix or remove the URL
> if it becomes outdated); requires it in the "end-user documentation", which
> I believe is stronger than the X11 license's "supporting documentation"; and
> it accumulates, if code is used from several projects with this type of 
> clause.
> (The "alternatively" lessens the "end-user documentation" problem, but only if
> there's a place for acknowledgments--there may not be, eg. on embedded 
> devices.)

IMHO, "end-user documentation" refers to any documentation shipped to
the end-user, including /usr/share/doc/*/copyright.  As long as the
documentation file is shipped to the user (the INSTALL file wouldn't
work, for example), it should qualify as "end-user documentation".  If
the license really required it to appear in a piece of documentation
suitable to show end-users how to operate the software, then the
software would not be distributable at all if no such documentation
existed.  I seriously doubt that is the intent of the license.

- Josh Triplett

Re: A radical approach to rewriting the DFSG

[Glenn Maynard]

FWIW, I don't particularly like this idea.  The DFSG, in practice,
is working very well, and the "case law" developing around it is
practical and, at least on debian-legal, well-understood.

Perhaps you could call this the "Henning Free Stuff Guidelines" for now?
Having the same abbreviation is inconvenient.

On Sun, May 30, 2004 at 04:52:15PM -0400, Nathanael Nerode wrote:
> Henning Makholm wrote:
> >

3. ... "Here, an author means everyone who holds or owns a copyright
applicable to the work."

I think it's a feature of the DFSG that it does not reference any
particular set of laws (copyright, patent, trademark).

(If I write a piece of software, patent an algorithm in it, place it
in the public domain, so that I'm not an "author" by this definition,
and enforce my patent, the work is not free.)

4. Acceptable restrictions
 A. Copyright notices
 B. Warranty disclaimers
 C. License texts

What about the old Apache license:

3. The end-user documentation included with the redistribution,
   if any, must include the following acknowledgment:
  "This product includes software developed by the
   Apache Software Foundation (http://www.apache.org/)."
   Alternately, this acknowledgment may appear in the software itself,
   if and wherever such third-party acknowledgments normally appear.

A lot of other software uses this, eg. Subversion.  It has three problems:
it gives a verbatim text (eg. no translations, can't fix or remove the URL
if it becomes outdated); requires it in the "end-user documentation", which
I believe is stronger than the X11 license's "supporting documentation"; and
it accumulates, if code is used from several projects with this type of clause.
(The "alternatively" lessens the "end-user documentation" problem, but only if
there's a place for acknowledgments--there may not be, eg. on embedded devices.)

However, I havn't seen anybody claiming that this is non-free and filing bugs
to that effect; only that it's ugly.

Any exception for this should be careful; some would try to require inclusion
of a full page of funding and sponsorship credits, for example.

4. j: "Specific exception for GPL #2(c)"

A note that this does not apply to verbatim statements may be appropriate.

> 5B:
> ..."A free license cannot require that the user notices the author prior
> to..."

Did you mean to suggest s/notices/notify/?

> 5C:
> "A free license cannot require that the user takes any explicit action to
> express agreements to its terms - even trivial actions such as clicking on
> OK buttons."
> Add clarification:
> (The license can specify that exercising the rights granted by the license,
> absent alternative permissions, will be interpreted as acceptance of the
> license.)

A nitpick: does "rights granted by the license" include grants of rights that
users have anyway?  For example, if a license includes an explicit "right to
use", is "use of this software constitutes acceptance" acceptable?  That's
a silly clause--users don't need to accept the license to use it, and
distributors--who do need to accept it--may never actually use it.  I'm
pretty sure we're seen it here, though.

Here's an odd one:

/usr/share/doc/libkrb53/copyright
  WARNING: Retrieving the OpenVision Kerberos Administration system
  source code, as described below, indicates your acceptance of the
  following terms.  If you do not agree to the following terms, do not
  retrieve the OpenVision Kerberos administration system.

(I don't see "retrieving" described anywhere, though--the word isn't
used anywhere else in the file.)

-- 
Glenn Maynard

Re: A radical approach to rewriting the DFSG

[Nathanael Nerode]

Henning Makholm wrote:

> I have been toying with the possibility of rewriting the DFSG such
> that it enumerates which things a free license *can* do, rather than
> just give examples of things it *cannot*.
Well, I like the approach a lot.

> I think that such a revision 
> could get the guidelines to be much closer to the *actual* practise of
> how we evaluate licenses than if we simply make local adjustments to
> the current DFSG. The downside is that the whole truth cannot be
> condensed into the "ten commandments" schema of the current DFSG.
> 
> My results so far are at
>
> 
> Comments will be appreciated - both about the general angle of attack,
> and about my specific draft. I have probably forgotten about a detail
> here and there.

Some nitpicks:

4C:
"A license text is a self-contained text that describes the authors' licence
grants. Short rationales such as the Preamble to the GNU General Public
License, version 2, are taken to be included in this concept. It is in
general a judgement call whether a legally irrelevant piece of text is
sufficiently related to the license grant to be piggy-backed onto the
license text in this way. "

I actually don't think the GPL Preamble is entirely legally irrelevant; it
would presumably color the legal interpretation of the GPL if a question of
interpretation came up.

"The license text itself may be excluded from the right to create derived
works.  (Several popular license texts explicitly forbids derivates of
 themselves. Debian strongly recommends that authors of license texts allow
them to be used by others for deriving license texts for their own works.)"

Typo, should be "derivatives", not "derivates".  But it would be better to
rewrite the sentence.

Also, it should be made clear that this exception does not apply to license
texts shipped on their own, rather than as the licenses for something.

Also, it's not just license texts which get a special break; other legal
recitations, sich as warranty disclaimers, are also allowed to be
non-modifiable.

5B:
..."A free license cannot require that the user notices the author prior
to..."

5C:
"A free license cannot require that the user takes any explicit action to
express agreements to its terms - even trivial actions such as clicking on
OK buttons."
Add clarification:
(The license can specify that exercising the rights granted by the license,
absent alternative permissions, will be interpreted as acceptance of the
license.)

5O:
"A free license cannot require that the user agrees to accept a specific
legal venue in the case that the author later decides to sue him."

Clarifications here about the exact meaning of 'venue' vs. 'law', etc, so
that the usual confusions don't pop up?

--
And a non-nitpick.

I would be quite comfortable allowing patent "retaliation" restrictions, but
only if they were very carefully tailored.  Specifically, license rights
must terminate only if the work is alleged to constitute patent
infringement (no action based on unrelated causes), and they must terminate
only for the person who alleged that it did (no harming third parties).

Well, these were just some thoughts.  Have fun with them.

-- 
There are none so blind as those who will not see.

Re: A radical approach to rewriting the DFSG

[Raul Miller]

On Sun, May 30, 2004 at 04:59:08PM +0100, Henning Makholm wrote:
> Scripsit Francesco Poli <[EMAIL PROTECTED]>
> > Just a question: does this mean that you also grandfather GPL#8?
> 
> Um, no. That is a good reason not to have a grandfather clause,
> actually. Removed.

You might want to add a general statement about optional clauses which
require release-time steps from the "author", which would cause problems
if invoked, but which haven't been invoked.

Right now, the handling for such things seems to be common sense, but
with a general trend away from solving specific problems and towards
philosophical purity, I can imagine a time in the future where "common
sense" no longer suffices.

-- 
Raul

Re: A radical approach to rewriting the DFSG

[Henning Makholm]

Scripsit Francesco Poli <[EMAIL PROTECTED]>

> * the title: why `stuff'?

Mostly to emphasize the draftness of the text. Not intended to be
permanent.

> Should these guidelines become the new DFSG, I think they will be named
> Debian Free Software Guidelines version 2.0

Agreed.

> * question: "Such a restriction is exactly as silly as it sounds.
> However, some otherwise free programs come with licenses that specify
> that the program must not be sold alone but only as part of an aggregate
> software distribution."
> Do you regard those programs as free? Is there any consensus on d-l
> about this awkward restriction?

Yes, this is a fairly solid consensus. It is more or less forced by
the wording of the current DFSG #1, which only requires the right to
distribute and sell "as a component of an aggregate software
distribution containing programs from several different sources".

Se, for example,
   http://lists.debian.org/debian-legal/2003/11/threads.html#00013
   http://lists.debian.org/debian-legal/2003/07/msg00294.html
   http://lists.debian.org/debian-legal/2002/09/msg00135.html
   http://lists.debian.org/debian-legal/2002/02/msg00066.html
   http://lists.debian.org/debian-legal/1999/06/msg00051.html
   http://lists.debian.org/debian-legal/1999/04/msg00080.html

I don't think there is much argument that this exception *exists*
today. It is not difficult to find people who would like to see it go
away, but at the moment my aim is to capture exactly the effects of
the current DFSG in its usual interpretation.

A secondary goal is to make the warts conspicuous enough that it is
easy to get rid of them later, which is why I wrote this in a specific
exception rather than burying it in the wording clause 3E.

> * Specific exception for 3-clause BSD licenses: "Debian strongly
> encourages authors to use more appropriate tools than copyright licenses
> if they feel they need more protection than the usual laws against
> misleading advertising." which tools? Trademarks? Any other? I think you
> should suggest at least one...

I agree. But it was getting late, and I didn't care to look up
Branden's denouncement and find the proper legal spellwords.
Suggestions for better wording of the comment would be appreciated.

> Just a question: does this mean that you also grandfather GPL#8?

Um, no. That is a good reason not to have a grandfather clause,
actually. Removed.

> [2] read as: I would prefer if d-l revised the three famous licenses to
> be sure they are acceptable on the basis of the other guidelines

Well, we don't really have enough power over the three famous licenses
to impose revisions on them...


Thanks for the other comments; applied.

-- 
Henning Makholm  "Den nyttige hjemmedatamat er og forbliver en myte.
Generelt kan der ikke peges på databehandlingsopgaver af
  en sådan størrelsesorden og af en karaktér, som berettiger
  forestillingerne om den nye hjemme- og husholdningsteknologi."

Re: A radical approach to rewriting the DFSG

[Josh Triplett]

Francesco Poli wrote:
> * question: "Such a restriction is exactly as silly as it sounds.
> However, some otherwise free programs come with licenses that specify
> that the program must not be sold alone but only as part of an aggregate
> software distribution."
> Do you regard those programs as free? Is there any consensus on d-l
> about this awkward restriction?

I believe the general consensus is that since the requirement is so
trivially satisfiable, it is considered free.  As long as there is no
restriction on how much additional software must be included, the
requirement could be satisfied by either:

* the rest of the Debian archive, or
* the Debian packaging scripts for that package, or
* a one byte file containing "w", which would be a valid sh script to
run the "w" command.

In addition, the program used to satisfy the requirement does not need
to be in the same package; it could be available alongside the program
on the same site.

- Josh Triplett

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On 30 May 2004 06:28:12 +0100 Henning Makholm wrote:

> I have been toying with the possibility of rewriting the DFSG such
> that it enumerates which things a free license *can* do, rather than
> just give examples of things it *cannot*.

It sounds interesting: it may work better...

> I think that such a revision
> could get the guidelines to be much closer to the *actual* practise of
> how we evaluate licenses than if we simply make local adjustments to
> the current DFSG. The downside is that the whole truth cannot be
> condensed into the "ten commandments" schema of the current DFSG.
> 
> My results so far are at
>
> 
> Comments will be appreciated - both about the general angle of attack,
> and about my specific draft. I have probably forgotten about a detail
> here and there.

First comments:

* the title: why `stuff'? I'm more comfortable with free _software_
guidelines, perhaps with a clear statement that we interpret the term
`software' as every piece of information that can be treated by a
computer system (that is programs, documentation, data...)[1]
Should these guidelines become the new DFSG, I think they will be named
Debian Free Software Guidelines version 2.0

* "Here, accompanied with the source must be understood to include the
situation where source is available for download from the same network
location and under the same conditions as the non-source form is
available under." I would generalize this:
s/available for download from the same network location/available from
the same place/

* typo: "respect to his to his own copyright" s/to his to his/to his/

* enhancement (maybe): "if the user knowingly copies the work in a way
not permitted by the license"
s/copies/copies or distributes/

* typo (I think): "license may require than" s/than/that/

* typo? "when a copy of the work are sold" s/are/is/ ???

* question: "Such a restriction is exactly as silly as it sounds.
However, some otherwise free programs come with licenses that specify
that the program must not be sold alone but only as part of an aggregate
software distribution."
Do you regard those programs as free? Is there any consensus on d-l
about this awkward restriction?

* Specific exception for 3-clause BSD licenses: "Debian strongly
encourages authors to use more appropriate tools than copyright licenses
if they feel they need more protection than the usual laws against
misleading advertising." which tools? Trademarks? Any other? I think you
should suggest at least one...

* Grandfather clause: mmmh! I already clarified MHO about
grandfathering, so I won't repeat myself...[2] Just a question: does
this mean that you also grandfather GPL#8?


Notes:

[1] of course the statement should be better phrased, but you know what
I mean and I'm in a hurry now... sorry  :p 

[2] read as: I would prefer if d-l revised the three famous licenses to
be sure they are acceptable on the basis of the other guidelines


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpo04G0LsydP.pgp
Description: PGP signature

A radical approach to rewriting the DFSG

[Henning Makholm]

I have been toying with the possibility of rewriting the DFSG such
that it enumerates which things a free license *can* do, rather than
just give examples of things it *cannot*. I think that such a revision
could get the guidelines to be much closer to the *actual* practise of
how we evaluate licenses than if we simply make local adjustments to
the current DFSG. The downside is that the whole truth cannot be
condensed into the "ten commandments" schema of the current DFSG.

My results so far are at
   

Comments will be appreciated - both about the general angle of attack,
and about my specific draft. I have probably forgotten about a detail
here and there.

-- 
Henning Makholm   "Det nytter ikke at flygte
   der er henna overalt"