Draft new DFSG - r1.4
Ian Jackson
remains largely unchanged.
Important changes include: a new rationale section at the end; a new
purpose section at the beginning; a new set of allowed restrictions
for various non-software works (mainly some kinds of documentation).
FYI, I append below the new text a diff between the previous posted
version (CVS revision 1.2) and this one.
PACKAGE MAINTAINERS: please check your licences to see if there are
harmless restrictions in your packages that need to be added to
section 3.
EVERYONE: please read through the new section 4 on special kinds of
works which allow extra restrictions.
EVERYONE WHO DIDN'T READ IT BEFORE: please read it ! You'll miss out
on your chance to participate, otherwise.
I don't want this to take as long as the Constitution. In particular,
I plan to formally propose a resolution by the end of the year, before
the end of my term as leader.
DRAFT
$Id: dfsg2.text,v 1.4 1998/11/27 02:47:09 ian Exp $
Debian Free Software Guidelines
version 2
DRAFT
0. Purpose
(a) This document describes what the Debian Project considers free
software. Only free software is part of Debian, as described in
Debian's Social Contract. The term `DFSG-free' will be used to mean
`free software according to the Debian Free Software Guidelines'.
(b) The purpose of the Debian Free Software Guidelines is to ensure
that software which is part of Debian can be freely used, distributed,
and maintained, so that copyright problems and other legal
restrictions play as little a part as possible in the technical
development of Debian and the software packages which make it up.
(c) The DFSG are written not just to ensure that the Debian Project
can do with the software the things that we, our users, and our
distributors, want or need to do. They are also intended to ensure
that any third party free software developer can, given a piece of
software from Debian, do all the things that they might reasonably
expect to do with it in order to use and further develop free
software.
1. Licence
DFSG-free works are either in the public domain, or come with a
copyright licence, and with any necessary patent licences.
2. Permissions
(a) For a work to be DFSG-free, anyone must be permitted to use it.
(b) The source code must be available.
(c) Anyone must be permitted to distribute it in whole or part, in its
original form or in modified forms, both as source code and/or as
executables, on its own or together with other works.
(d) Anyone must be permitted to reverse-engineer it.
(e) These activities must be permitted regardless of from whom the
work was obtained, and must be permitted without having to refer to
or notify anyone else.
(f) There must be no restrictions on these activities other than kinds
of restrictions explicitly allowed by these guidelines; any other
restriction means that the work is not DFSG-free.
(g) The licence(s) must not allow the copyright or patent holder(s) to
terminate the licence(s).
3. Exemptions
(a) Requirement to distribute source code
The licence may require source code for the work to be distributed
whenever the executable is distributed, provided that:
i. When distribution is made by public anonymous download, the
licence restriction is satisfied if the source code is made available
on the same site as the executable, at all times when the executable
is available.
ii. The licence allows the distributor of executables to offer to
distribute the source code instead of actually distributing it. The
licence
(1) may require the offer to be in writing;
(2) may require that the offer remain valid for some specified
period of time (not more than 3 years);
(3) may require the offer to be open to all third parties.
(b) Requirement for onward distribution to use particular licence
The licence may make requirements about the kinds of licence (or other
contract or similar document) under which people distribute the
work (or its modified versions), so long as it is still possible to
distribute the work under according to these guidelines.
(c) Requirements for placing notices
The licence may require notices to be placed in the source code,
documentation, and/or to cause the work to display notices at
appropriate points during its execution (in the case of a work which
can be executed) or content (in the case of a work which can be
displayed and/or printed).
It must be possible to write such notices so that they are truthful,
not offensive, and not unreasonably long for the context in which they
are required, without the implied requirement to do so imposing any
restrictions which are not compatible with these guidelines.
(d) Requirements made to apply to whole work
The licence may make its requirements (falling under the other
exceptions) apply to the whole work when the original work is
combined with a second work to make a new whole work and the
resulting whole work (or part of it) is distributed.
(The licence may not make any requirements about other works or data
that are distributed as separate works but are merely distributed on
the same disk, tape, network site, or whatever.)
(e) Restrictions on misrepresentation
The licence may restrict the use (without permission) of the names of
the authors and copyright holders to endorse or promote products
derived from the work.
The licence may also restrict other kinds of misrepresentation.
(f) Limitation of liability
It may be a condition of the licence that the authors and copyright
holders are not held legally responsible for errors and omissions in
the work (in so far as permitted by applicable law).
(g) Non-binding requests
The licence or other documentation may make other requests of users
and redistributors, provided that these requests are not legally
binding, and that there is no suggestion that failing to honour the
request is unethical or immoral.
(h) Different name or version number for certain version
The licence may require the work to be distributed under a different
name or with a different version number under some circumstances
defined in the licence, provided that this doesn't interfere with
using the modified version as a replacement for the original.
(i) Advertising restriction (deprecated)
The licence may require advertising materials which mention features
or use of the work to contain a short notice specified by the
software.
This exception is only available if the restriction was imposed no
later than the 1st of January 1999, and if no modified version of the
work has been published since then by anyone who could remove the
restriction.
This exception is likely to be removed in a future version of these
guidelines. For rationale, see Appendix C.
4. Documentation and other non-software works
Certain kinds of documentation or other non-software works may have
further restrictions.
(a) None of the exceptions listed in this section apply to a work
which is documentation for software. Documentation for software is
documentation to which a conscientious programmer would wish to make
corresponding changes when they modify the software.
(b) A document which states an opinion, as an opinion, need not be
modifiable.
(c) The licence for a document which specifies a standard of some kind
(for example a Standards Track RFC) need not be modifiable, provided
that the licence still permits the creation and distribution of
modified versions, for at least the purposes of developing new
standards, according to the procedures for the standards process in
question.
(d) An artwork which is expressive and not functional need not be
modifiable.
(e) When we say that a work need not be modifiable, we mean that
restrictions may be placed on:
i. the creation and/or distribution of modified versions;
ii. the distribution of parts of the work, rather than the whole;
iii. distribution of the source code, if this is different from the
form of the work usually distributed (and, we also mean that the
source code need not be available); and
iv. reverse-engineering.
5. Restrictions due to law
(a) If in a particular jurisdiction any of the activities mentioned in
section 1 are restricted by law, then the work is not DFSG-free in
that jurisdiction. However, legal restrictions which would apply to
any work which has the same general nature as the work in question do
not prevent a work from being DFSG-free.
(b) A work is still DFSG-free in other jurisdictions, provided that
those who control (directly or indirectly) the work and the conditions
under which it is distributed, do not have the power to lift the
restrictions other than by changing the nature of the work, and
express a desire that the legal restrictions be lifted.
(c) In the case of restrictions due to patents, the work can in any
case not be DFSG-free if any of those who control the work and the
conditions under which it is distributed are software patent
aggressors.
6. Glossary
In these guidelines:
(a) Source code has the meaning given for it in the GNU General Public
Licence, version 2.
(b) Executables means a derived version of the work which is not the
source code.
(c) A software patent aggressor is a person or organisation who
enforces patents against software patent nonaggressor(s), with respect
to infringement by software, or profits from such enforcement.
APPENDICES AND RATIONALE
A. Why is a change from DFSG1 necessary ?
The current DFSG (version 1) have a number of problems.
Its most serious problem is that they are far too vague. Very often a
new copyright licence is brought up on one of the Debian mailing
lists, and a long discussion ensues. These discussions usually hinge
on trying to guess the meaning of the text of the DFSG.
Unfortunately, the DFSG1 are not sufficiently clear, precise or
self-consistent for this to work well.
Another problem with DFSG1 is that they state that certain
restrictions make software not DFSG-free, rather than listing the
permitted restrictions. The effect of this is that when a novel but
unhelpful licence is compared with the DFSG1, it is often found to
meet the letter of the guidelines despite the fact that its licence
has unreasonable restrictions for free software.
The combination of these two effects mean that Debian developers are
tempted towards `creative' interpretations of the DFSG - for example,
involving the `no discrimination against fields of endeavour' clause.
This can only lead to flamewars, an appearance of arbitrariness, and
the unwise inclusion or exclusion of software.
Finally, the free software community is now encountering a number of
individuals and organisations who would like to give away as little
freedom as possible. The DFSG1 were not written to withstand hostile
interpretation. In the current climate it is necessary to have
guidelines whose interpretation is clear, and which cannot easily be
bent or subverted.
B. Why are `modifications as patch only' licenses not allowed ?
(DFSG1 paragraph 4 `Integrity of The Author's Source Code' allows a
licence to require that modifications be distributed only as original
sources plus patches. The DFSG2 do not allow this. Here is why.)
The following examples are things you should be legally able to do
with free software, even if you're not the original author:
* Run an anon-CVS service for your working tree.
* Use a shared CVS server for your internal development.
* Fork the software and competely reorganise the sources even though
the original author hates you for it.
* Take over maintenance after the original author has died, been
bought, lost access to the 'net or whatever, and completely reorganise
the source tree.
* Copy parts of the software into another program (unfortunately we
don't have complete ability to do this anyway, at the moment).
* Repackage the original source package into a different distribution
format (eg, better archive utility, better compression program,
whatever).
None of these things can be done if the licence takes full advantage
of the DFSG1 patch clause.
It might be possible to write a wording for an exception, to allow a
requirement that distribution of modified versions be accompanied by
distribution of the original source code. Such an exception wouldn't
initially greatly impede the activities I mention above, but would
make distribution of the source on CD (for example) excessively bulky
after a while. Imagine if for every program you'd taken some code
from you had to supply a complete source archive of that program; with
increasing code reuse the amount of source being distributed would
quickly become unreasonable.
Also, any such exception would have to be written very carefully so
that (eg) CVS servers are still allowed.
All in all, it is better not to have the exception at all.
C. Why the limitations on the advertising clause exception (3.i) ?
Richard Stallman has written an excellent article about this subject,
The BSD License Problem, <URL:http://www.fsf.org/philosophy/bsd.html>.
In summary, the so-called `obnoxious BSD advertising clause', while
fine for the distribution of a single package, makes advertising a
program or operating system which may have thousands of contributors a
real problem (if the clause is enforced).
New free software should not contain this clause. In deference to the
body of existing software with this clause, and also out of practical
motives, software with this clause in a `legacy' licence is
permitted.
The clause is less of a problem in old software than in new software,
because in the past there were only a handful of copyright holders
whose names appear on such licences and which are therefore required
to appear in advertising.
D. Future exceptions
It is expected that the Debian developers may choose to add additional
kinds of permitted restriction to the list in section 3. This is
likely to happen if software with such a restriction is encountered,
or a free software author approaches the project about the matter, but
in any case only if the restriction would not obstruct the use,
development and distribution of free software.
Index: dfsg2.text
===================================================================
RCS file: /usr/src/CVS/chiark-misc/dfsg2.text,v
retrieving revision 1.2
retrieving revision 1.4
diff -u -r1.2 -r1.4
--- dfsg2.text 1998/11/23 14:58:14 1.2
+++ dfsg2.text 1998/11/27 02:47:09 1.4
@@ -1,14 +1,30 @@
- DRAFT
- $Id: dfsg2.text,v 1.2 1998/11/23 14:58:14 ian Exp $
- Debian Free Software Guidelines
+ DRAFT
+ $Id: dfsg2.text,v 1.4 1998/11/27 02:47:09 ian Exp $
+ Debian Free Software Guidelines
version 2
- DRAFT
+ DRAFT
-This document describes what the Debian Project considers free
+0. Purpose
+
+(a) This document describes what the Debian Project considers free
software. Only free software is part of Debian, as described in
Debian's Social Contract. The term `DFSG-free' will be used to mean
`free software according to the Debian Free Software Guidelines'.
+(b) The purpose of the Debian Free Software Guidelines is to ensure
+that software which is part of Debian can be freely used, distributed,
+and maintained, so that copyright problems and other legal
+restrictions play as little a part as possible in the technical
+development of Debian and the software packages which make it up.
+
+(c) The DFSG are written not just to ensure that the Debian Project
+can do with the software the things that we, our users, and our
+distributors, want or need to do. They are also intended to ensure
+that any third party free software developer can, given a piece of
+software from Debian, do all the things that they might reasonably
+expect to do with it in order to use and further develop free
+software.
+
1. Licence
DFSG-free works are either in the public domain, or come with a
@@ -20,9 +36,9 @@
(b) The source code must be available.
-(c) Anyone must be permitted to distribute it in its original form and
-in modified forms, both as source code and as executables, on its own
-or together with other works.
+(c) Anyone must be permitted to distribute it in whole or part, in its
+original form or in modified forms, both as source code and/or as
+executables, on its own or together with other works.
(d) Anyone must be permitted to reverse-engineer it.
@@ -52,9 +68,9 @@
ii. The licence allows the distributor of executables to offer to
distribute the source code instead of actually distributing it. The
licence
- (1) may require the offer to be in writing
- (2) may specify some minimum length of validity of the offer (not
- more than 3 years)
+ (1) may require the offer to be in writing;
+ (2) may require that the offer remain valid for some specified
+ period of time (not more than 3 years);
(3) may require the offer to be open to all third parties.
(b) Requirement for onward distribution to use particular licence
@@ -85,7 +101,7 @@
resulting whole work (or part of it) is distributed.
(The licence may not make any requirements about other works or data
-that are distributed as separate works but is merely distributed on
+that are distributed as separate works but are merely distributed on
the same disk, tape, network site, or whatever.)
(e) Restrictions on misrepresentation
@@ -109,12 +125,12 @@
binding, and that there is no suggestion that failing to honour the
request is unethical or immoral.
-(h) Changed name or version number for modified version
+(h) Different name or version number for certain version
-The licence may require modified versions to be distributed under a
-different name or with a different version number, provided that this
-doesn't interfere with using the modified version as a replacement for
-the original.
+The licence may require the work to be distributed under a different
+name or with a different version number under some circumstances
+defined in the licence, provided that this doesn't interfere with
+using the modified version as a replacement for the original.
(i) Advertising restriction (deprecated)
@@ -128,25 +144,64 @@
restriction.
This exception is likely to be removed in a future version of these
-guidelines.
+guidelines. For rationale, see Appendix C.
+
+4. Documentation and other non-software works
+
+Certain kinds of documentation or other non-software works may have
+further restrictions.
+
+(a) None of the exceptions listed in this section apply to a work
+which is documentation for software. Documentation for software is
+documentation to which a conscientious programmer would wish to make
+corresponding changes when they modify the software.
+
+(b) A document which states an opinion, as an opinion, need not be
+modifiable.
+
+(c) The licence for a document which specifies a standard of some kind
+(for example a Standards Track RFC) need not be modifiable, provided
+that the licence still permits the creation and distribution of
+modified versions, for at least the purposes of developing new
+standards, according to the procedures for the standards process in
+question.
+
+(d) An artwork which is expressive and not functional need not be
+modifiable.
-4. Restrictions due to law
+(e) When we say that a work need not be modifiable, we mean that
+restrictions may be placed on:
-(a) If in a particular jurisdiction the distribution, modification or
-use of a work is restricted by law, then the work is not
-DFSG-free in that jurisdiction.
+ i. the creation and/or distribution of modified versions;
-(b) It is still DFSG-free in other jurisdictions, provided that those
-who control (directly or indirectly) the work and the conditions under
-which it is distributed, do not have the power to lift the
+ ii. the distribution of parts of the work, rather than the whole;
+
+ iii. distribution of the source code, if this is different from the
+form of the work usually distributed (and, we also mean that the
+source code need not be available); and
+
+ iv. reverse-engineering.
+
+5. Restrictions due to law
+
+(a) If in a particular jurisdiction any of the activities mentioned in
+section 1 are restricted by law, then the work is not DFSG-free in
+that jurisdiction. However, legal restrictions which would apply to
+any work which has the same general nature as the work in question do
+not prevent a work from being DFSG-free.
+
+(b) A work is still DFSG-free in other jurisdictions, provided that
+those who control (directly or indirectly) the work and the conditions
+under which it is distributed, do not have the power to lift the
restrictions other than by changing the nature of the work, and
express a desire that the legal restrictions be lifted.
-(c) In the case of restrictions due to patents, a work can in any case
-not be DFSG-free if those who control the work and the conditions
-under which it is distributed are software patent aggressors.
+(c) In the case of restrictions due to patents, the work can in any
+case not be DFSG-free if any of those who control the work and the
+conditions under which it is distributed are software patent
+aggressors.
-5. Glossary
+6. Glossary
In these guidelines:
@@ -159,3 +214,110 @@
(c) A software patent aggressor is a person or organisation who
enforces patents against software patent nonaggressor(s), with respect
to infringement by software, or profits from such enforcement.
+
+APPENDICES AND RATIONALE
+
+A. Why is a change from DFSG1 necessary ?
+
+The current DFSG (version 1) have a number of problems.
+
+Its most serious problem is that they are far too vague. Very often a
+new copyright licence is brought up on one of the Debian mailing
+lists, and a long discussion ensues. These discussions usually hinge
+on trying to guess the meaning of the text of the DFSG.
+Unfortunately, the DFSG1 are not sufficiently clear, precise or
+self-consistent for this to work well.
+
+Another problem with DFSG1 is that they state that certain
+restrictions make software not DFSG-free, rather than listing the
+permitted restrictions. The effect of this is that when a novel but
+unhelpful licence is compared with the DFSG1, it is often found to
+meet the letter of the guidelines despite the fact that its licence
+has unreasonable restrictions for free software.
+
+The combination of these two effects mean that Debian developers are
+tempted towards `creative' interpretations of the DFSG - for example,
+involving the `no discrimination against fields of endeavour' clause.
+This can only lead to flamewars, an appearance of arbitrariness, and
+the unwise inclusion or exclusion of software.
+
+Finally, the free software community is now encountering a number of
+individuals and organisations who would like to give away as little
+freedom as possible. The DFSG1 were not written to withstand hostile
+interpretation. In the current climate it is necessary to have
+guidelines whose interpretation is clear, and which cannot easily be
+bent or subverted.
+
+B. Why are `modifications as patch only' licenses not allowed ?
+
+(DFSG1 paragraph 4 `Integrity of The Author's Source Code' allows a
+licence to require that modifications be distributed only as original
+sources plus patches. The DFSG2 do not allow this. Here is why.)
+
+The following examples are things you should be legally able to do
+with free software, even if you're not the original author:
+
+* Run an anon-CVS service for your working tree.
+
+* Use a shared CVS server for your internal development.
+
+* Fork the software and competely reorganise the sources even though
+the original author hates you for it.
+
+* Take over maintenance after the original author has died, been
+bought, lost access to the 'net or whatever, and completely reorganise
+the source tree.
+
+* Copy parts of the software into another program (unfortunately we
+don't have complete ability to do this anyway, at the moment).
+
+* Repackage the original source package into a different distribution
+format (eg, better archive utility, better compression program,
+whatever).
+
+None of these things can be done if the licence takes full advantage
+of the DFSG1 patch clause.
+
+It might be possible to write a wording for an exception, to allow a
+requirement that distribution of modified versions be accompanied by
+distribution of the original source code. Such an exception wouldn't
+initially greatly impede the activities I mention above, but would
+make distribution of the source on CD (for example) excessively bulky
+after a while. Imagine if for every program you'd taken some code
+from you had to supply a complete source archive of that program; with
+increasing code reuse the amount of source being distributed would
+quickly become unreasonable.
+
+Also, any such exception would have to be written very carefully so
+that (eg) CVS servers are still allowed.
+
+All in all, it is better not to have the exception at all.
+
+C. Why the limitations on the advertising clause exception (3.i) ?
+
+Richard Stallman has written an excellent article about this subject,
+The BSD License Problem, <URL:http://www.fsf.org/philosophy/bsd.html>.
+
+In summary, the so-called `obnoxious BSD advertising clause', while
+fine for the distribution of a single package, makes advertising a
+program or operating system which may have thousands of contributors a
+real problem (if the clause is enforced).
+
+New free software should not contain this clause. In deference to the
+body of existing software with this clause, and also out of practical
+motives, software with this clause in a `legacy' licence is
+permitted.
+
+The clause is less of a problem in old software than in new software,
+because in the past there were only a handful of copyright holders
+whose names appear on such licences and which are therefore required
+to appear in advertising.
+
+D. Future exceptions
+
+It is expected that the Debian developers may choose to add additional
+kinds of permitted restriction to the list in section 3. This is
+likely to happen if software with such a restriction is encountered,
+or a free software author approaches the project about the matter, but
+in any case only if the restriction would not obstruct the use,
+development and distribution of free software.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jason Gunthorpe
On Fri, 27 Nov 1998, Ian Jackson wrote:
> i. When distribution is made by public anonymous download, the
> licence restriction is satisfied if the source code is made available
> on the same site as the executable, at all times when the executable
> is available.
We don't actually assure that. We have binary-only mirrors, binary-only
CD's and we have binaries in the archive that do not have source for their
exact versions.
Allowing the license to insist that the source be avaible at the same site
is probably not very workable..
> 4. Documentation and other non-software works
> (a) None of the exceptions listed in this section apply to a work
> which is documentation for software. Documentation for software is
> documentation to which a conscientious programmer would wish to make
> corresponding changes when they modify the software.
Perhaps clarify this, this refers to (I presume?) man pages for programs,
info pages for programs, etc but does it cover something like the gimp
tutorial (which arguably is an opinion about how to properly use the
gimp)
I don't see an allowance for a derived document of a different name..
IE you might say 'Yes you can change RFC1111 but you must not call it
RFC1111 anymore'
Jason
Raul Miller
I'm stalled here.
[1] What does it mean to disallow reverse engineering on a statement
of opinion? On a work of art? A standards document? It seems to me
that if reverse engineering is a concept applies to the work then the
original should have been modifiable.
[2] What is a standard? Can someone simly declare a work to be
a standard, or is there some further criteria?
--
Raul
Chris Waters
> B. Why are `modifications as patch only' licenses not allowed ?
As others have mentioned, I think this is an EXTREMELY bad time to
forbid patch-only licenses. And, no disrespect for anyone intended,
but I have a lot more respect and trust for the opinions of RMS than I
do for *anyone* in the Debian organization, including myself! If RMS is
willing to declare the QPL a free license, that's good enough for me.
> The following examples are things you should be legally able to do
> with free software, even if you're not the original author:
There is nothing I'm aware of that you cannot do with a patch-only
license; you just can't necessarily do it in a convenient manner.
> * Run an anon-CVS service for your working tree.
Sure you can! You just have to keep the patches as separate files under
CVS control. Awkward, and it somewhat limits the usefulness of CVS, but
it doesn't actually limit what you can do with the code.
> * Use a shared CVS server for your internal development.
Again, yes you can. Same reasoning.
> * Fork the software and competely reorganise the sources even though
> the original author hates you for it.
Again, while it's not convenient, you can certainly do whatever you like
with your working copy, as long as you *distribute* it in the form of
patches against the original code.
> * Take over maintenance after the original author has died, been
> bought, lost access to the 'net or whatever, and completely reorganise
> the source tree.
Again, this would be inconvenient and difficult, but quite possible.
Same reasoning as the last point.
> * Copy parts of the software into another program (unfortunately we
> don't have complete ability to do this anyway, at the moment).
This would be extremely difficult, but still possible. You could make a
patch that deletes everything but one line from the original, and adds
the new code from your new project around that, if you really wanted.
> * Repackage the original source package into a different distribution
> format (eg, better archive utility, better compression program,
> whatever).
I don't see how this relates to patch-only licensing at all. Patch-only
doesn't say anything about how the original source tree is packaged. It
just says that it must be delivered in an unmodified form, and patches
must be separate and clearly marked. If I pack up the original source
tree with cpio rather than tar, the source tree itself is not modified.
I think that the freedom to deliver the source as a cpio archive, or
even a zipinfo or lharc file, is an important one, and it might be worth
looking at some way to guarantee that freedom. But that's an entirely
separate issue from the issue of patch-only licenses.
> It might be possible to write a wording for an exception, to allow a
> requirement that distribution of modified versions be accompanied by
> distribution of the original source code. Such an exception wouldn't
> initially greatly impede the activities I mention above, but would
> make distribution of the source on CD (for example) excessively bulky
> after a while.
This brings up a whole 'nuther question: are we going to reject
packages that are large and bulky and not very useful to most people,
just because they're large and bulky and not very useful to most people?
There's already going to be a limiting factor here, in that if something
is really difficult to package for Debian, probably nobody will *want*
to package it for Debian, and it won't be an issue. But if someone is
willing to volunteer the time and effort to do so, do we really want to
reject it, and if so, where, exactly, do we draw the line?
> Imagine if for every program you'd taken some code
> from you had to supply a complete source archive of that program; with
> increasing code reuse the amount of source being distributed would
> quickly become unreasonable.
Isn't the decision over whether it's unreasonable something a developer
should be free to decide for herself?
As I said, the large-and-bulky issue is something we should discuss
separately. Maybe we want to have a policy that such things are
required to have a priority of 'extra'. Maybe even we want to make all
patch-only licensed code have a priority of 'extra'. That sounds like a
reasonable approach to me. But the idea of rejecting free code just
because it's difficult to use strikes me as a bad one.
--
Chris Waters xt...@dsp.net | I have a truly elegant proof of the
or cwa...@systems.DHL.COM | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Raul Miller
> As others have mentioned, I think this is an EXTREMELY bad time to
> forbid patch-only licenses. And, no disrespect for anyone intended,
> but I have a lot more respect and trust for the opinions of RMS than I
> do for *anyone* in the Debian organization, including myself! If RMS
> is willing to declare the QPL a free license, that's good enough for
> me.
Then again, the QPL 0.90 draft is roughly equivalent to the BSD license,
though it does say some strange things about patch requirements to
achieve this end. [For example: take each file and strip out everything
but the required copyright. Make patches. Distribute under required
license. Toss the original sources and patch an empty directory.]
Since the patch requirement here lets you do anything with the
functional parts of the source I think it would even be usable
under the proposed new DFSG.
Too bad the license doesn't apply to anything.
--
Raul
Richard Braakman
> There is nothing I'm aware of that you cannot do with a patch-only
> license; you just can't necessarily do it in a convenient manner.
I think this is not the right test to apply.
By the same token, you can do all of these things with a binary-only
package; it's just very difficult. (Disassemble it first and keep
the disassembled code in CVS, etc.)
Now, suppose I want to take parts from three different patches-only
programs to use in my own project. What do I patch and to where?
Richard Braakman
Tony Finch
>
>PACKAGE MAINTAINERS: please check your licences to see if there are
>harmless restrictions in your packages that need to be added to
>section 3.
>
>
>The licence may require advertising materials which mention features
>or use of the work to contain a short notice specified by the
>software.
>
>This exception is only available if the restriction was imposed no
>later than the 1st of January 1999, and if no modified version of the
>work has been published since then by anyone who could remove the
>restriction.
I think the major application that this will affect is Apache -- the
Apache Group has control of the licence. I don't know if anyone has
brought this up with them...
Tony.
--
dxoigmn**f.a.n.finch
d...@dotat.at
fa...@demon.net
Ilya L Ovchinnikov
of DFSG which treat it as non-free is not good thing.
--
Ilya Ovchinnikov -------------------------------------
Internet Service and Information
Providing Center of Pushchino
e-mail: il...@psn.ru Research Center of RAS
phone: +7(0967)73-90-03 Pushchino, Moscow region, Russia.
============================================================
r...@greenend.org.uk
>0. Purpose
[...]
I think the purpose section should emphasize that it must be possible
to sell Debian for profit, as well as at no cost.
>2. Permissions
[...]
>(d) Anyone must be permitted to reverse-engineer it.
I think there should be a definition here (or below).
[...]
>3. Exemptions
[...]
>(b) Requirement for onward distribution to use particular licence
>
>The licence may make requirements about the kinds of licence (or other
>contract or similar document) under which people distribute the
>work (or its modified versions), so long as it is still possible to
>distribute the work under according to these guidelines.
I think there's some words missing; I can't make sense of `under
according to'.
[...]
>4. Documentation and other non-software works
[...]
>(e) When we say that a work need not be modifiable, we mean that
>restrictions may be placed on:
[...]
> iii. distribution of the source code, if this is different from the
>form of the work usually distributed (and, we also mean that the
>source code need not be available); and
[...]
It seems odd to include the remark about not requiring source to be
available as a parenthetical note in a definition clause. Surely it
belongs in a separate clause of its own?
[...]
>5. Restrictions due to law
>
>(a) If in a particular jurisdiction any of the activities mentioned in
>section 1 are restricted by law, then the work is not DFSG-free in
>that jurisdiction. However, legal restrictions which would apply to
>any work which has the same general nature as the work in question do
>not prevent a work from being DFSG-free.
I think that should say section 2, not section 1.
[...]
>6. Glossary
>
>In these guidelines:
>
>(a) Source code has the meaning given for it in the GNU General Public
>Licence, version 2.
I think this should be spelled out.
[...]
>APPENDICES AND RATIONALE
[...]
>B. Why are `modifications as patch only' licenses not allowed ?
I mentioned this document last night:
http://tech.appl-opt.physik.uni-essen.de/LinuX/kde/food/linux_is_obsolete.html
There are a number of comments on the difficulty of trying to develop
enhancements to Minix, which only allow distribution of patches - not
complete modified sources. IIRC most are towards the end of the file.
>Imagine if for every program you'd taken some code from you had to
>supply a complete source archive of that program; with increasing
>code reuse the amount of source being distributed would quickly
>become unreasonable.
Perhaps we should find the size of the diff between GNU Emacs and
XEmacs to illustrate this point.
ttfn/rjk
Richard Braakman
> I say again: TeX _IS_ definetly free software and IMHO any version
> of DFSG which treat it as non-free is not good thing.
/usr/doc/tetex-base/copyright only gives this as a license:
--------------
Copyright for tetex-base, tetex-extra and tetex-doc:
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
On Debian GNU/Linux systems, the complete text of the GNU General Public
License may be found in /usr/doc/copyright/GPL
--------------
If this is incorrect, can anyone post the complete license here for
our consideration?
Richard Braakman
Federico Di Gregorio
I don't have TeX license at hand at now, but it works as follows:
i. you can distribute the modified sources only as original WEB
sources plus WEB patches (i.e., "change files").
ii. you can distribute a binary obtained from the modified sources
(modified = orig.source+changefiles) and still call it TeX only if
the initex program runned on the trip.tex file produces the same
results of the original TeX. Else you have to name it another way
(e.g., pdftex).
Note that I consider TeX one of the major pieces of free software
(along with gcc, emacs and such) and ANY license that puts TeX out
of main is, IMHO, a BAD BAD BAD (did I say BAD?) license.
My 2$,
Federico
--
____
Federico Di Gregorio | / mailto:f...@debian.org
Debian developer! | / -1 http://pcamb6.irfmn.mnegri.it/~fog
*-=$< ;-P TeX Winzard? |/ http://www.debian.org
Marcelo E. Magallon
> (b) The source code must be available.
- (b) The source code must be available.
+ (b) The complete source code must be available.
As an (extreme) example, you can download diffpack's source code from a
server in Netherlands, but there's one file missing, and you can't do zip
without that file -- ok, it would be possible to guess the contents of the
file, but the license forbids that; my point is, it could be argued that
diffpack *is* Open Source because you *can* download the source. (I'm not
saying diffpack's license is DFSG-free by any strecht of the imagination --
it poses a number of restrictions enforced by the mentioned mechanism)
> (g) The licence(s) must not allow the copyright or patent holder(s) to
> terminate the licence(s).
Does this mean that the author can't change the license from v1.0 to v2.0
(v1.0 free, v2.0 not)? Or does this mean that the author can't say "version
1.0 is no longer free?" (I guess the question is what does "terminate" mean?
I looked it in the dictionary, but I still don't understand what "terminate"
means in a legal context)
> (a) Source code has the meaning given for it in the GNU General Public
> Licence, version 2.
The source code for a work means the preferred form of the work for making
modifications to it. For an executable work, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the executable.
IMO, there are two things defined here, "source code" and "complete source
code" (but I concur, in the context of the GPL, "source code" means
"complete source code")
> * Fork the software and competely reorganise the sources even though
> the original author hates you for it.
I can't help recalling some recent thread on -policy everytime I read
this... <g>
Marcelo
Johnie Ingram
"Tony" == Tony Finch <d...@dotat.at> writes:
Tony> I think the major application that this will affect is Apache
Tony> -- the Apache Group has control of the licence.
It also affects ispell, the larger Apache modules, and everything with
ssleay support (mutt-i etc.), if we assume this was carefully worded
not to apply to University of California, Berkeley based software.
But personally I find this exception-within-an-exception distasful.
We're going to say the Apache 1.3.3 is free and 1.3.4 is not, even
though both have the EXACT same license Apache has had for years? And
the next release of pmake will be considered non-free? And if down
the road UCB helps maintain sendmail, bind, or xfree86, those will
suddenly be non-free too?
The advertising clause, though distasteful, affects very few people
and doesn't make the software less free to use. It makes it less free
to mention by name in your corporate press releases, which until now
no one has claimed is an essential feature of free software (or Open
Source).
Perhaps I'm biased here, since I maintain Apache and a number of
packages related to it. But I'm also a Debian CD vendor, so this
supposedly "hurts" me -- and I still say such software should stay in
main.
This issue aside, the new DFSG seems more suited to be a Policy manual
chapter than to be the guiding statement of principles for the
Project, especially given its complexity, legalistic tone (a glossary
is needed?) and two-faced nature.
--------------------- PGP E4 70 6E 59 80 6A F5 78 63 32 BC FB 7A 08 53 4C
__ _ Debian GNU Johnie Ingram <joh...@netgod.net> mm mm
/ /(_)_ __ _ ___ __ "netgod" irc.debian.org mm mm
/ / | | '_ \| | | \ \/ / m m m
/ /__| | | | | |_| |> < Yes, I'm Linus, and I am your God. mm mm
\____/_|_| |_|\__,_/_/\_\ -- Linus, keynote address, Expo 98 GO BLUE
Wichert Akkerman
> ii. you can distribute a binary obtained from the modified sources
> (modified = orig.source+changefiles) and still call it TeX only if
> the initex program runned on the trip.tex file produces the same
> results of the original TeX. Else you have to name it another way
> (e.g., pdftex).
So you are still allowed to released modified versions of TeX, even
without using patches or .aux files; you only have to call if something
else.
Wichert
--
==============================================================================
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: wakk...@cs.leidenuniv.nl
WWW: http://www.wi.leidenuniv.nl/~wichert/
Federico Di Gregorio
> Previously Federico Di Gregorio wrote:
> > ii. you can distribute a binary obtained from the modified sources
> > (modified = orig.source+changefiles) and still call it TeX only if
> > the initex program runned on the trip.tex file produces the same
> > results of the original TeX. Else you have to name it another way
> > (e.g., pdftex).
>
> So you are still allowed to released modified versions of TeX, even
> without using patches or .aux files; you only have to call if something
-> else.
+> else?
I don't know. I don't remember exactly if the patch clause applies
only if you want to call it TeX or always. IMHO the second one.
Ciao,
Federico
--
____
Federico Di Gregorio | / mailto:f...@debian.org
Debian developer! | / -1 http://pcamb6.irfmn.mnegri.it/~fog
*-=$< ;-P TeX Winzard? |/ http://www.debian.org
Wichert Akkerman
> Since the patch requirement here lets you do anything with the
> functional parts of the source I think it would even be usable
> under the proposed new DFSG.
Or at least you can create a new source from the patches and release
that with a different, DSFG*-free license.
Wichert.
Kristof...@ens-lyon.fr
I have read the DFSG2 draft. It makes me sad because I remember the
original discussion in 1993 where the goal clearly was to be as free as
possible, while remaining in the spirit of the GPL, but with the primary
goal that there should be no restriction on the redistribution/sale/etc. of
the Debian packages and [then upcoming] CD-ROM.
I believe we should stick with this ideal: *any* license that does not
prevent any form of distribution of the Official Debian */* CD-ROM should
be allowed.
Federico [on TeX's Copyright]:
> I don't know. I don't remember exactly if the patch clause applies only
> if you want to call it TeX or always. IMHO the second one.
No: Knuth does not permit *any* modifications of the file. Let me quote
the the header of the tex.web file (given that it is a very mild violation
of the clause and serves to clarify this matter I hope Don will forgive me
:):
% This program is copyright (C) 1982 by D. E. Knuth; all rights are reserved.
% Copying of this file is authorized only if (1) you are D. E. Knuth, or if
% (2) you make absolutely no changes to your copy. (The WEB system provides
% for alterations via an auxiliary file; the master file should stay intact.)
% See Appendix H of the WEB manual for hints on how to install this program.
% And see Appendix A of the TRIP manual for details about how to validate it.
TeX includes its own patch file format which is used by all distributions
of TeX, including teTeX/texk used by Debian.
I'd be sad if TeX had to go out of main.
Best regards,
Kristoffer
--
Kristoffer Høgsbro Rose, phd, prof.associé <http://www.ens-lyon.fr/~krisrose>
addr: LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone: +33(0)4 7272 8642, fax +33(0)4 7272 8080 <Kristof...@ENS-Lyon.FR>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0 <krisrose@{debian,tug}.org>
Oliver Elphick
[... a legalistic version of new guidelines ...]
I don't agree with Ian's new restrictions on the DFSG and I don't
like turning it into a legal document.
I would like to propose instead the following text, which is the
existing DFSG, verbatim, with a short new preamble and some
exceptions at the end.
==========================================================================
Debian Free Software Guidelines
===============================
These are the guidelines which packages must satisfy in order to
be included in Debian's main distribution. This is not a legal
text; packages must comply with the spirit of these guidelines,
not just the letter.
1. Free Redistribution
The license of a Debian component may not restrict any party from
selling or giving away the software as a component of an aggregate
software distribution containing programs from several different
sources. The license may not require a royalty or other fee for such
sale.
2. Source Code
The program must include source code, and must allow distribution in
source code as well as compiled form.
3. Derived Works
The license must allow modifications and derived works, and must allow
them to be distributed under the same terms as the license of the
original software.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in modified
form _only if the license allows the distribution of "patch files" with
the source code for the purpose of modifying the program at build time.
The license must explicitly permit distribution of software built from
modified source code. The license may require derived works to carry a
different name or version number from the original software. (This is a
compromise. The Debian group encourages all authors to not restrict any
files, source or binary, from being modified.)
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of
persons.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in
a specific field of endeavor. For example, it may not restrict the
program from being used in a business, or from being used for genetic
research.
7. Distribution of License
The rights attached to the program must apply to all to whom the
program is redistributed without the need for execution of an
additional license by those parties.
8. License Must Not Be Specific to Debian
The rights attached to the program must not depend on the program's
being part of a Debian system. If the program is extracted from Debian
and used or distributed without Debian but otherwise within the terms
of the program's license, all parties to whom the program is
redistributed should have the same rights as those that are granted in
conjunction with the Debian system.
9. License Must Not Contaminate Other Software
The license must not place restrictions on other software that is
distributed along with the licensed software. For example, the license
must not insist that all other programs distributed on the same medium
must be free software.
10. Example Licenses
The "GPL", "BSD", and "Artistic" licenses are examples of licenses that
we consider "free".
Special considerations
======================
Documentation
Documentation must be modifiable in the same way as software.
The licence of a Standard may prohibit alteration of the text. However,
it must allow the text to be copied and altered so long as the result
does not pretend to be the Standard it was copied from.
The licence of works of information or reference must allow them to
be altered.
Other works
Literary works or artistic images may be licensed under terms that
prohibit their being altered, so long as they may be freely
distributed.
National restrictions and patents
The existence in certain countries of legislation or patents that
restrict rights to use or distribute a package do not mean that
that package is not regarded as free, even if those restrictions
mean that it is not practicable to include the package in the main
Debian archive.
==========================================================================
--
Oliver Elphick Oliver....@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Thou, even thou, art LORD alone; thou hast made
heaven, the heaven of heavens, with all their host,
the earth, and all things that are therein, the seas,
and all that is therein, and thou preservest them all;
and the host of heaven worshippeth thee."
Nehemiah 9:6
Bob Hilliard
> 5. Restrictions due to law
>
> (a) If in a particular jurisdiction any of the activities mentioned in
> section 1 are restricted by law, then the work is not DFSG-free in
> that jurisdiction. However, legal restrictions which would apply to
> any work which has the same general nature as the work in question do
> not prevent a work from being DFSG-free.
>
> (b) A work is still DFSG-free in other jurisdictions, provided that
> those who control (directly or indirectly) the work and the conditions
> under which it is distributed, do not have the power to lift the
> restrictions other than by changing the nature of the work, and
> express a desire that the legal restrictions be lifted.
>
> (c) In the case of restrictions due to patents, the work can in any
> case not be DFSG-free if any of those who control the work and the
> conditions under which it is distributed are software patent
> aggressors.
The DFSG is, and should remain, solely about the copyright and
license provisions. If the license of a work is fully compliant with
the DFSG, the work is DFSG-free. The author, through his choice of
license, determines the DFSG-freeness of his work.
The laws of one or more countries may restrict where and how
Debian may distribute some works, but DFSG-freeness is not affected
by these laws.
If any of the packages now in the non-us section have DFSG
compliant licenses, they should be considered part of the main debian
distribution, even if some foolish laws restrict their use or
distribution.
Bob
--
_
|_) _ |_ Robert D. Hilliard <hill...@flinet.com>
|_) (_) |_) Palm City, FL USA PGP Key ID: A8E40EB9
Loic Prylli
Ian Jackson <i...@chiark.greenend.org.uk> writes:
> There are substantial changes here to the periphery, but the core
> remains largely unchanged.
Looks one of the important problem is the patch clause issue that I will discuss.
>
> B. Why are `modifications as patch only' licenses not allowed ?
>
IMHO it _is_ possible to have an intermediate clause, where the
copyright owner can enforce separating the original work from the
modifications without some of the inconvenients you mentioned.
> (DFSG1 paragraph 4 `Integrity of The Author's Source Code' allows a
> licence to require that modifications be distributed only as original
> sources plus patches. The DFSG2 do not allow this. Here is why.)
>
> The following examples are things you should be legally able to do
> with free software, even if you're not the original author:
>
> * Run an anon-CVS service for your working tree.
I agree this should be allowed, but CVS allows to clearly separate the
original source from the patch. We just need a rationale that any
patch restriction clause should still allow the source to be
distribute under any control-revision system, when these conditions
are respected:
- the original source is put under the control-revision system
- there is some documentation for how to retrieve the original source,
or to generate a set of modifications between any version and the
original source, from the control-revision system.
> * Use a shared CVS server for your internal development.
Agree that it should be allowed, eventually with the same restrictions
than above.
>
> * Fork the software and competely reorganise the sources even though
> the original author hates you for it.
This is sensitive point, it is nice to be able to reorganise
source. But as long as we are allowed to extend, maintain and reuse
freely the software without restrictions, I think it is free enough to
be included in Debian. The DFSG does not say what we think is the
"Right Licensing" for software licensing or what we recommend, it says
what IS ACCEPTABLE FOR SOFTWARE TO BE PUT INTO THE DEBIAN
DISTRIBUTION. I like the current DFSG that says the patch clause is
bad, but we accept it.
The CVS issue is one of maintainance, there are other requirements:
possibillity of evolution, distribution without restrictions
commercial,... (all the contents ofthe previous DFSG). They should be
enforced. There is one more level of freedom that you want to require
(I simplify, but I think this is the spirit):
- being able to take any portion of source code from any part of the
debian source code distribution, and having the right to copy-paste it
for reuse in any other software, providing it is GPL.
That would greatly simplify the life developper by not having to read
and understand licences, (I think that by counting the time that all
developers in the world have spend trying to follow the QT licensing
issue, we would obtain enough manpower to rewrite QT from scratch).
But we are not defining an UFSG: Universal Free Software Guidelines, to
evangelize free software. We are defining what is free enough to be in
the Debian distrib.
The question is, do you think Qt and the TeX system are "free enough"
to go in Debian Operating system.
>
> * Take over maintenance after the original author has died, been
> bought, lost access to the 'net or whatever, and completely reorganise
> the source tree.
Reasonable reorganisations of source code are still doable with a
modifications-are-provided-separately clause. Altough I do not know
any supercvs, super-patch or super-diff tools that allow to take into
account renaming and moving of files, or moving of parts of code, they
may exist, and the job to go from original to modified and back could
be done anyway by a few scripts that will represent the modifications.
If the modifications you want to do are too big to be done this way,
it is probably not maintainance of a software anymore, but reuse in
another project (which is a different level of freedom).
>
> * Copy parts of the software into another program (unfortunately we
> don't have complete ability to do this anyway, at the moment).
I already discussed it above, tough we can disapprove officially, I
think software with these kind of restrictions can still go in Debian
without harming its original aim.
>
> * Repackage the original source package into a different distribution
> format (eg, better archive utility, better compression program,
> whatever).
That falls into maintainance, so I agree this should be explicitely
allowed, as long as the contents of the archive are the same.
> None of these things can be done if the licence takes full advantage
> of the DFSG1 patch clause.
>
> It might be possible to write a wording for an exception, to allow a
> requirement that distribution of modified versions be accompanied by
> distribution of the original source code. Such an exception wouldn't
> initially greatly impede the activities I mention above, but would
> make distribution of the source on CD (for example) excessively bulky
> after a while. Imagine if for every program you'd taken some code
> from you had to supply a complete source archive of that program; with
> increasing code reuse the amount of source being distributed would
> quickly become unreasonable.
>
> Also, any such exception would have to be written very carefully so
> that (eg) CVS servers are still allowed.
>
> All in all, it is better not to have the exception at all.
I disagree here, tough we may want to modify or add a rational for
the patch clause; it is easier to progressively convince people to not
use that, rather than for Debian to present stricter rules than what it
requires for its aim, it aim being:
> (c) The DFSG are written not just to ensure that the Debian Project
> can do with the software the things that we, our users, and our
> distributors, want or need to do. They are also intended to ensure
> that any third party free software developer can, given a piece of
> software from Debian, do all the things that they might reasonably
> expect to do with it in order to use and further develop free
> software.
>
This definition contains the word reasonable which is highly
subjective. I find it reasonable to be forced to provide a way to go
from and back between my version and the original version of a piece
of software if the original author asked to. That provides the freedom
for third-parties to choose which of the modifications they want to
take.
Loic
Dirk Eddelbuettel
Oliver> I don't agree with Ian's new restrictions on the DFSG and I don't
Oliver> like turning it into a legal document.
Oliver>
Oliver> I would like to propose instead the following text, which is the
Oliver> existing DFSG, verbatim, with a short new preamble and some
Oliver> exceptions at the end.
Good approach. I like it.
--
Linux is not only free; it is, arguably, a better operating system, offering
a degree of stability and an ability to scale up that NT cannot match.
-- The Economist, Oct 3, 1998
Robert Edmonds
> All in all I think I much prefer this approach over rewriting the DFSG..
>
> For all the little flaws, the current DFSG is known, tested, and
> accepted.
> Minor changes to correct flaws and patch holes are fine, but a complete
> rewrite of a accepted standard? Is this /REALLY/ what we want to do?
>
> Zephaniah E, Hull.
<aol>me too!</aol> ;)
--
Robert S. Edmonds
+-------------------------------------------------------+
| Debian developer | http://www.debian.org |
| Freshmeat staff member | http://freshmeat.net |
| NetWinder developer | http://www.netwinder.org |
| s...@novare.net | http://www.stu.ddns.org |
+-------------------------------------------------------+
VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
James R. Van Zandt
Robert Edmonds <s...@novare.net> writes:
>On Sat, 28 Nov 1998, Zephaniah E, Hull wrote:
>
>> All in all I think I much prefer this approach over rewriting the DFSG..
>>
>> For all the little flaws, the current DFSG is known, tested, and
>> accepted. Minor changes to correct flaws and patch holes are fine,
>> but a complete rewrite of a accepted standard? Is this /REALLY/
>> what we want to do?
>>
>> Zephaniah E, Hull.
>
><aol>me too!</aol> ;)
I agree.
- Jim Van Zandt
Milan Zamazal
6. If you base research on SWI-Prolog and publish on this research,
you must include appropriate acknowledgements and references to
SWI-Prolog in your publication.
Anyway, I'm opposed to converting DFS guidelines into DFS law too.
It only makes licensing issues even more complicated. Let's await new
flamewars about interpretation of the law and about
adding/deleting/updating exceptions to it.
Sorry, but I'll vote NO for any such document.
Milan Zamazal
Antti-Juhani Kaijanaho
> If this is incorrect, can anyone post the complete license here for
> our consideration?
No, I don't think so. teTeX contains multitudes of packages, many
with differing licenses. It would take ages to dig out all of them to
here. In fact, we still find non-free files in tetex-base even though
non-free files were put into a separate package half a year ago.
Check the BTS, if you want to know the details.
TeX proper and its companions (Metafont etc) have an obscure license,
which I analyzed in an earlier message in the "Draft new DFSG" thread,
posted here yesterday evening.
The core LaTeX has a license saying, in effect, that modification is
allowed only if the result is renamed. Many LaTeX packages have a
similar license.
The framework of Web2C, which is used by teTeX, (ie. kpathsea and
friends) are covered by the GNU (L)GPL.
Antti-Juhani
--
%%% Antti-Juhani Kaijanaho % ga...@iki.fi % http://www.iki.fi/gaia/ %%%
About to generate a new signature, please wait...
Chris Waters
> Chris Waters wrote:
> > There is nothing I'm aware of that you cannot do with a patch-only
> > license; you just can't necessarily do it in a convenient manner.
> By the same token, you can do all of these things with a binary-only
> package; it's just very difficult. (Disassemble it first and keep
> the disassembled code in CVS, etc.)
Binary-only PACKAGE? Do you perhaps mean a binary-only LICENSE? (We're
discussing licensing here!) In the case of a binary-only license, no
you *CAN'T* do all that. If you could, it wouldn't be a binary-only
license.
If a package *COMES* as a binary, but the license allows disassembly,
and redistribution of the disassembled code (with modification, OC),
then I'd say it should pass DFSG (other things being equal) as soon as
someone does the disassembly and provides a source package (DFSG1 *does*
require source). I think that would be a stupid way to distribute a
package in the first place, I can't imagine anyone distributing only
binaries but allowing redistribution of the source, but if it *did*
happen, I don't see anything wrong with it, as long as the terms for
distribution of the disassembled source match the DFSG in other
respects.
Bottom line: I think that rejecting patch-only licenses at this point
is more likely to result in a fork of the Debian project than anything
else. I think that would be a Bad Thing.
--
Chris Waters xt...@dsp.net | I have a truly elegant proof of the
or cwa...@systems.DHL.COM | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Daniel Martin
> Ian Jackson <i...@chiark.greenend.org.uk> writes:
>
> > 5. Restrictions due to law
> >
> > (a) If in a particular jurisdiction any of the activities mentioned in
> > section 1 are restricted by law, then the work is not DFSG-free in
> > that jurisdiction. However, legal restrictions which would apply to
> > any work which has the same general nature as the work in question do
> > not prevent a work from being DFSG-free.
> >
> > (b) A work is still DFSG-free in other jurisdictions, provided that
> > those who control (directly or indirectly) the work and the conditions
> > under which it is distributed, do not have the power to lift the
> > restrictions other than by changing the nature of the work, and
> > express a desire that the legal restrictions be lifted.
> >
> > (c) In the case of restrictions due to patents, the work can in any
> > case not be DFSG-free if any of those who control the work and the
> > conditions under which it is distributed are software patent
> > aggressors.
>
>
> The DFSG is, and should remain, solely about the copyright and
> license provisions. If the license of a work is fully compliant with
> the DFSG, the work is DFSG-free. The author, through his choice of
> license, determines the DFSG-freeness of his work.
<SNIP>
YES!
The basic principle here is: "A piece of software cannot be blamed for
the idiot who authored it." With free software, defining clearly
"those who control the work" is deliberately difficult if not
impossible. We are concerned only that the bonds of intellectual
property law have been severed (or sufficiently weakened), not that
some particular group hold specific political views. Some might also
want to declare that any software company found to be spreading
unfounded FUD about opensource systems should not be allowed to make
free software as in 5c above. You can see where this could go.
To take an example I wrote about earlier today, (in the thread on
Ian's first draft) suppose some piece of software is released under
the GPL but does something that requires the payment of patent
royalties. Suppose further that this piece of software is released by
the patent holder, who is an agressor as defined in the DFSG draft.
Now, suppose some site in Sweden (or in some other country without
software patent protection) takes a copy of the software and makes it
available there. Is the software now DFSG free in Sweden? A "No"
creates a very odd problem - what if one line of code is added by the
Swedish sit to their version? Does not the simple act of
redistributing the software make the Swedish site the one who
"controls the work" as it exists on that site? (For example, that
site could choose to exercise editorial control about which versions
they'll distribute, picking only versions they consider sufficiently
stable)
> The laws of one or more countries may restrict where and how
> Debian may distribute some works, but DFSG-freeness is not affected
> by these laws.
>
> If any of the packages now in the non-us section have DFSG
> compliant licenses, they should be considered part of the main debian
> distribution, even if some foolish laws restrict their use or
> distribution.
Hmmm - I suppose; I'd still like to see official CDs without non-US
exist (although it's perfectly reasonable to expect that official CDs
with non-US included exist as well).
If we accept this view, then we _definitely_ need a preamble that
states that DFSG freeness is not the only criterion used to determine
if a certain package will end up in Debian or on any particular Debian
mirror.
Anselm Lingnau
> I don't remember exactly if the patch clause applies
> only if you want to call it TeX or always. IMHO the second one.
The patch clause applies to the tex.web file that Don Knuth distributes.
You are allowed to write a completely unrelated program from scratch and
distribute that as `TeX' as long as it passes the Trip test (a suite of
regression tests for TeX-like programs). This has been done several
times by different people.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Live now. There'll be plenty of time to be dead later. -- Anon.
jo...@dhh.gt.org
> This makes SWI Prolog non-free because of one its licensing clause:
> 6. If you base research on SWI-Prolog and publish on this research,
> you must include appropriate acknowledgements and references to
> SWI-Prolog in your publication.
IMHO that is a restriction on use and fails the present DFSG. It is also
so vague as to be impossible to comply with.
Shouldn't this thread be on debian-legal? I've cc'd it.
--
John Hasler
jo...@dhh.gt.org (John Hasler)
Dancing Horse Hill
Elmwood, WI
Jules Bean
> Milan Zamazal writes:
>
>> This makes SWI Prolog non-free because of one its licensing clause:
>
>> 6. If you base research on SWI-Prolog and publish on this research,
>> you must include appropriate acknowledgements and references to
>> SWI-Prolog in your publication.
>
> IMHO that is a restriction on use and fails the present DFSG. It is also
> so vague as to be impossible to comply with.
Interesting.
To the extent that your research is a 'derived' work of SWI-Prolog, this
restriction is perfectly admissible.
Also, it is clearly routine academic behaviour to do so. A piece of
research is worthless unless it explains how to replicate the results, and
part of this explanation will necessarily be 'appropriate acknowledgements
and references'.
So, in some sense this is a 'non-restriction'.
However, it could be construed to fail the current DFSG. Maybe we should
exempt this (it doesn't impinge on the freeness of the software, as a piece
of software).
Jules
P.S. Yes, it should be on -legal. I'm maintaining the CC to -devel to give
all those on -devel who haven't noticed -legal's existence yet a chance to
subscribe. I suggest we drop the -devel CC on the next response.
/----------------+-------------------------------+---------------------\
| Jelibean aka | ju...@jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | ju...@debian.org | Richmond, Surrey |
| Julian Bean | jm...@hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| Debian GNU/Linux - "Microsoft *does* have a year 2000 problem - |
| and we're it!" (paraphrased from IRC) |
\----------------------------------------------------------------------/
jo...@dhh.gt.org
> To the extent that your research is a 'derived' work of SWI-Prolog, this
> restriction is perfectly admissible.
To the extent that your research is not a 'derived' work of SWI-Prolog, it
isn't. I read this as saying that if I publish a paper on AI which
includes some prolog code that I tested using SWI-Prolog I must credit them
even though my publication does not contain one line of SWI-Prolog.
> Also, it is clearly routine academic behaviour to do so. A piece of
> research is worthless unless it explains how to replicate the results,
> and part of this explanation will necessarily be 'appropriate
> acknowledgements and references'.
Correct. So why demand that people do something they will do anyway?
> So, in some sense this is a 'non-restriction'.
It is a restriction on a field of endeavor.
> Maybe we should exempt this (it doesn't impinge on the freeness of the
> software, as a piece of software).
It places a requirement on those who "base research on SWI-Prolog and
publish on this research" that it does not place on others. I suspect that
the authors really meant that they want credit when portions of their work
are included in the publication. Why not try to convince them to clarify
the license? Pehaps they would be willing to change the demand to a
request, or to make it clear that they mean derived works.
I don't see this as an urgent problem that would justify removing that
package.
--
John Hasler
jo...@dhh.gt.org (John Hasler)
Dancing Horse Hill
Elmwood, WI
Kristof...@ens-lyon.fr
> It places a requirement on those who "base research on SWI-Prolog and
> publish on this research" that it does not place on others. I suspect
> that the authors really meant that they want credit when portions of
> their work are included in the publication. Why not try to convince them
> to clarify the license? Pehaps they would be willing to change the
> demand to a request, or to make it clear that they mean derived works.
IMHO a nice & respectful letter is in place to make SWI-Prolog clarify
their position. Just remember one thing: programmers in the academic
computing community have a *hard* time getting credit for their software.
So please let us (debian) be tolerant towards this kind of advertising
claims where the only real problem is the discrimination of other
academics!
Let's propose that they use something like
`Any published work that has used SWI-Prolog to obtain the published
results should include a clear notice that this was the case. Notice
that for distribution of derived works this is automatically the case
since the Copyright notices must be retained.'
Cheers,
Kristoffer [an SWI-Prolog user]
--
Kristoffer Høgsbro Rose, phd, prof.associé <http://www.ens-lyon.fr/~krisrose>
addr: LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone: +33(0)4 7272 8642, fax +33(0)4 7272 8080 <Kristof...@ENS-Lyon.FR>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0 <krisrose@{debian,tug}.org>
Milan Zamazal
JB> --On Mon, Nov 30, 1998 8:03 am -0600 jo...@dhh.gt.org wrote:
>> Milan Zamazal writes:
>>
>>> This makes SWI Prolog non-free because of one its licensing
>>> clause:
>>
>>> 6. If you base research on SWI-Prolog and publish on this
>>> research, you must include appropriate acknowledgements and
>>> references to SWI-Prolog in your publication.
>> IMHO that is a restriction on use and fails the present DFSG.
>> It is also so vague as to be impossible to comply with.
[...]
JB> Also, it is clearly routine academic behaviour to do so.
Yes.
JB> However, it could be construed to fail the current DFSG. Maybe
JB> we should exempt this (it doesn't impinge on the freeness of the
JB> software, as a piece of software).
When I was going to move SWI Prolog from non-free to main, I asked about
its license on debian-devel and the conclusion was it's DFSG free.
What I'd like to point is that with DFS law we will never cover all the
unusual cases, we will discuss law problems and will changing the law
over and over (probably by many voting procedures, which is the only
significant difference against current state). I simply don't think it
is a good idea to define free software by exact law, guidelines are more
better IMHO, since they express spirit rather than stating some border
defined by some arbitrary wording.
It isn't important to me whether the second paragraph of the point 14.d
of XYZ license is in full compliance with the point 1.2.3.4 of DFSL.
It's important to me, whether I have got freedom to use XYZ or not (yes,
maybe I'm too big idealist).
JB> P.S. Yes, it should be on -legal.
Yes, the SWI Prolog discussion belongs there, but please CC me, since
I'm not subscribed there (unfortunately I have no capacity to read *all*
the licensing flamewars).
Milan Zamazal
Milan Zamazal
KR> John writes:
>> Why not try to convince them to clarify the license?
KR> IMHO a nice & respectful letter is in place to make SWI-Prolog
KR> clarify their position.
KR> Let's propose that they use something like
KR> `Any published work that has used SWI-Prolog to obtain the
KR> published results should include a clear notice that this was
KR> the case. Notice that for distribution of derived works this is
KR> automatically the case since the Copyright notices must be
KR> retained.'
Thanks for suggestions, I'll contact the author and ask him to clarify
the license.
Raul Miller
> The basic principle here is: "A piece of software cannot be blamed for
> the idiot who authored it." With free software, defining clearly
> "those who control the work" is deliberately difficult if not
> impossible.
If this is truly the case then there's nothing to worry about from
that front. I don't think we should make this a requirement for free
software, though.
--
Raul
Ian Jackson
hard to interpret. Frankly, I'm flabbergasted.
We have spend endless hours here on -devel arguing about whether
such-and-such a stupid restriction counts as `discrimination against
fields of endeavour'. Surely noone can deny this ? This is one of
the problems I'm trying to solve.
Why is it that we have these arguments ?
Two reasons: firstly, the DFSG1 is written in vague and woolly terms,
not precise language. Note that the DFSG2 is not in legalese - it's
still in English, and I think you'll find that matching any particular
licence to the DFSG2 is a much easier task than with the DFSG1.
But, the main reason ? Because the DFSG1 is nothing more than a
single gigantic loophole attached to a few requirements !
Examples:
1. Some software licences require you to send a postcard to the author
(`postcardware'.)
2. On debian-legal we had a licence which said that the author wanted
you to have sex everytime you used their program ! Now, as it
happens, the licence just encourages, rather than making it a
requirement. But, let us suppose that it had made it a requirement.
I don't see how you can possibly argue that these licences don't meet
the DFSG1.
I saw someone on -legal claim that they might fall foul of the
`discrimination against fields of endeavour' clause. This is
obviously nonsense, but they were proposing it because that clause is
the only one which can remotely be interpreted to mean `and the
software mustn't have other annoying restrictions' !
If we're going to retain an informal DFSG and have arguments about it
we need at the very least to include an exception clause that gives us
discretion about new unreasonable conditions that come up. Something
like:
11. No Other Onerous Restrictions
The licence must not have other restrictions or conditions which
make the software hard to use, maintain or develop.
But, if we do that, what political position will we find ourselves in
when MegaFooCorp want us to ship their program and having included a
questionable clause in their licence ?
Answer: just the same one as we're currently in with KDE and QT. Even
though we act with the best intentions, everyone will assume that
we're trying to shift the goalposts, or make special rules.
I think it's very important that MegaFooCorp can decide in advance
what our conditions are, and then just have their lawyers draft a
licence to meet them. Then, we can say `yes, that's fine'.
Or, if the conditions are too onerous and they want to maintain more
restrictions, then at least this is clear from the start and there are
no hard feelings, or they can contact us to ask whether we would be
prepared to add a new exception for their obviously-reasonable but
not-yet-thought-of restriction.
Ian.
Ian Jackson
...
> When I was going to move SWI Prolog from non-free to main, I asked about
> its license on debian-devel and the conclusion was it's DFSG free.
I think that it might be reasonable to add an exception for such `must
credit' licences.
Would you like to mail me or post a suggestion or shall I write one ?
> What I'd like to point is that with DFS law we will never cover all the
> unusual cases, we will discuss law problems and will changing the law
> over and over (probably by many voting procedures, which is the only
> significant difference against current state). I simply don't think it
> is a good idea to define free software by exact law, guidelines are more
> better IMHO, since they express spirit rather than stating some border
> defined by some arbitrary wording.
We currently have guidelines expressed by spirit and spend ages
arguing about them, even to the point of having political fights about
them with other projects. This is not good !
When we're a project of 400 people, as prominent as we are, we must
act in a consistent, accountable and rational way.
Oscar Levi
> Several people have complained that the DFSG2 are too legalistic or
> hard to interpret. Frankly, I'm flabbergasted.
[deletia]
Hear hear.
While I'd really like to see this discussion end because I don't see
anything to argue about, I recognize that this is the mode for casual,
grass-roots organizations.
Simply stated: Ian writes sense.
David Welton
> Several people have complained that the DFSG2 are too legalistic or
> hard to interpret. Frankly, I'm flabbergasted.
> We have spend endless hours here on -devel arguing about whether
> such-and-such a stupid restriction counts as `discrimination against
> fields of endeavour'. Surely noone can deny this ? This is one of
> the problems I'm trying to solve.
We have already solved it by creating the -legal mailing list so that
people spending their countless hours arguing about stupid
restrictions don't clog up -devel, and the rest of us can get back to
producing a free, and great distribution;-))))
Ciao,
--
David Welton http://www.efn.org/~davidw
Debian GNU/Linux - www.debian.org
Joey Hess
> 2. On debian-legal we had a licence which said that the author wanted
> you to have sex everytime you used their program ! Now, as it
> happens, the licence just encourages, rather than making it a
> requirement. But, let us suppose that it had made it a requirement.
>
> I don't see how you can possibly argue that these licences don't meet
> the DFSG1.
>
> I saw someone on -legal claim that they might fall foul of the
> obviously nonsense
Why is it nonsense? Someone who is in a religious order and celibate is in a
field of endevour the license would discriminate against.
--
see shy jo
Joey Hess
> 1. Some software licences require you to send a postcard to the author
> (`postcardware'.)
We have _never_ considered such software free, if the sending of postcards
is mandatory. I challenge you to find one example of such a thing in main.
> I don't see how you can possibly argue that these licences don't meet
> the DFSG1.
Do you claim that we can't argue that a license that requires a $20
registration free doesn't meet the DFSG? It's the same thing.
Joey Hess
> We currently have guidelines expressed by spirit and spend ages
> arguing about them, even to the point of having political fights about
> them with other projects. This is not good !
I think you're wrong. I think a review of the list archives will show
license questions are resolved quickly.
The issues that arn't resolved quickly, like the KDE/QT thing are those that
involve interactions between different licences. We didn't realize the bad
interactions between KDE and QT for a long time - for nearly a year -
because it's the result of a complex interaction between the 2 licenses.
The fact is, licenses are legalese, and no DFSG of any sort is going to
help us cut through that. But we do understand the DFSG and exactly what it
stands for, and once we think we understand what a given license is saying,
there is no difficulty in applying the DFSG to it and getting an answer.
I don't see this endless wrangling over unclear wording in the DFSG you and
others are talking about. What I've seen, since the DFSG was released is
people saying "this license violates points 3 and 6 of the DFSG", and others
understanding exactly what they mean.
Joey Hess
> 1. Some software licences require you to send a postcard to the author
No one in debian, to my knowledge has ever argued that any license that
mandates a postcard be sent, is free.
> When we're a project of 400 people, as prominent as we are, we must
> act in a consistent, accountable and rational way.
And so you propose a guideline that in your own words, "gives us discretion
about new unreasonable conditions that come up."
How is us making arbitrary decisions about every new situation consitent?
James A. Treacy
> Several people have complained that the DFSG2 are too legalistic or
> hard to interpret. Frankly, I'm flabbergasted.
>
> We have spend endless hours here on -devel arguing about whether
> such-and-such a stupid restriction counts as `discrimination against
> fields of endeavour'. Surely noone can deny this ? This is one of
> the problems I'm trying to solve.
>
DFSG means. Most people aren't concerned with the details, though, and
either method below will satisfy their needs.
A preamble can be written which summarizes the document that follows.
It is important that it be clear that the more precise text that
follows is the actual license.
An alternative is to write an overview document that states the
main points of the license and contains links to the relevant section
of the actual license.
What is the distinction between these? Preambles are short and attached
to the formal document. The second would be separate and could be longer.
Jay Treacy
Avery Pennarun
> Ian is correct in asserting that we need a tighter definition of what
> DFSG means. Most people aren't concerned with the details, though, and
> either method below will satisfy their needs.
>
> A preamble can be written which summarizes the document that follows.
> It is important that it be clear that the more precise text that
> follows is the actual license.
>
> An alternative is to write an overview document that states the
> main points of the license and contains links to the relevant section
> of the actual license.
>
> What is the distinction between these? Preambles are short and attached
> to the formal document. The second would be separate and could be longer.
I can't speak for the rest of the world, but I don't trust rule documents
that "summarize" what they mean in short, and then expand on it for pages
afterward. If it takes you ten pages to _really_ say what you mean, then if
I only read the preamble, I'm going to misunderstand something.
And then we have the same problem over again.
I still don't agree with the long-winded DFSG2 style. I do, however, agree
that the "discrimination against fields of endeavour" clause in DFSG1 is
pretty hard to understand. But if that's the only real problem, does it
justify a complete rewrite?
I've been subscribed to debian-devel for a long time and I've seen lots of
license discussions, but other than people claiming the GPL discriminates
against fields of endeavour, there haven't been many _difficult_ licensing
decisions. (KDE kept coming up too, but that's because of popularity, not
lack of clarity in the DFSG...)
Have fun,
Avery
Avery Pennarun
> (d) stop having binary-only mirrors.
>
> Which do you think we should do ?
>
> Hint: only (d) is feasible in the short term. (b) might be feasible
> later. (a) and (c) are totally out of the question.
>
> I think we should do (d).
The binary-only mirrors are not run by Debian, as far as I know. Everyone
is free to run whatever kind of mirror they like. I mirror the wvdial,
netselect, and popularity-contest packages (albeit with source) at
www.worldvisions.ca and I don't expect Debian to start restricting me.
Whether the people who run such mirrors are violating the GPL is not
strictly our concern. I would bring up GPL section 3(c), but I'm not
subscribed to debian-legal.
Jason Gunthorpe
On Thu, 3 Dec 1998, Avery Pennarun wrote:
> On Thu, Dec 03, 1998 at 06:01:47PM +0000, Ian Jackson wrote:
>
> > (d) stop having binary-only mirrors.
> >
> > Which do you think we should do ?
> >
> > Hint: only (d) is feasible in the short term. (b) might be feasible
> > later. (a) and (c) are totally out of the question.
> >
> > I think we should do (d).
>
> The binary-only mirrors are not run by Debian, as far as I know. Everyone
> is free to run whatever kind of mirror they like. I mirror the wvdial,
> netselect, and popularity-contest packages (albeit with source) at
> www.worldvisions.ca and I don't expect Debian to start restricting me.
>
> Whether the people who run such mirrors are violating the GPL is not
> strictly our concern. I would bring up GPL section 3(c), but I'm not
> subscribed to debian-legal.
Indeed, there is a huge market in binary-only CD sales as well. I think
section 3(b) covers them, and AFAIK I thought it was OK to have a binary
only mirror as anyone accessing the mirror would have internet access and
thus access to a non-binary only mirror.
I don't know if section 3(b) can cover our mismatched version, but it
is estimated to double the size of the source archive if we need to
include every version
Jason
Craig Sanders
> Ian Jackson wrote:
> > 1. Some software licences require you to send a postcard to the
> > author (`postcardware'.)
>
> We have _never_ considered such software free, if the sending of
> postcards is mandatory. I challenge you to find one example of such a
> thing in main.
i'm glad someone pointed this out.
when licenses like this come up, the question we have always used to
decide if it is DFSG is "is it a request, or is it mandatory".
if the license only *requests* something (please send me a postcard, or
a six-pack of beers, or please donate to my favourite charity) then it
is DFSG free.
if the license *requires* that postcard or beer or sexual activity then it
is not DfSG free.
craig
--
craig sanders
Oscar Levi
> section 3(b) covers them, and AFAIK I thought it was OK to have a binary
> only mirror as anyone accessing the mirror would have internet access and
> thus access to a non-binary only mirror.
I asked RMS about several years ago. The reason it was worded this
way was to prohibit the unscrupulous behavoir of erecting barriers for
access to the source code. The indent is to make the source code as
easy to gather as the binaries.
While I would not suggesting that the letter of the GPL makes
binary-CDs or binary mirrors violations of the text, we may observe
that FSF distributes tapes of binaries of their software while
maintaining FTP sites for all sources.
The indent of the GPL should be clear: software freedom. Binary
mirrors do not prohibit this freedom.
Oscar Levi
> help us cut through that. But we do understand the DFSG and exactly what it
> stands for, and once we think we understand what a given license is saying,
> there is no difficulty in applying the DFSG to it and getting an answer.
I am seeing divergence in this line of discussion. This indicates to
me that it is not productive to continue in this way.
> I don't see this endless wrangling over unclear wording in the DFSG you and
> others are talking about. What I've seen, since the DFSG was released is
> people saying "this license violates points 3 and 6 of the DFSG", and others
> understanding exactly what they mean.
Thus, the first question is whether or not we believe the DFSG needs
to be changed.
Joey Hess
> Thus, the first question is whether or not we believe the DFSG needs
> to be changed.
Well I can agree with that!
Could we put this to a vote?
--
see shy jo
Oscar Levi
> Oscar Levi wrote:
> > Thus, the first question is whether or not we believe the DFSG needs
> > to be changed.
>
> Well I can agree with that!
>
> Could we put this to a vote?
Before this, I believe we need to discuss rules of order. It is my
belief that the IETF has spent many years working on projects where
the participants live remote from each other. I think that each
project has a chair and a mailing list. The work is conducted on an
agreed time schedule, reviewed by everyone, and ratified by the group
before being submitted to the whole organization. Anyone can join any
project by joining the mailing list.
While most of the work of Debian is conducted by individuals and
uploaded as packages, things like the DFSG that are fundamental to the
whole organization need to be reviewed by everyone who has an interest
in doing so.
Given this working model, and the apparent energy present on the
d-devel list about the DFSG, how do those following this discussion
feel about starting a meta discussion regarding groupe projects? This
is important because the IETF has build an organization around this
process. I think we need to look at the whole of their enchilada
before we attempt to reproduce their effort.
Joey Hess
> Before this, I believe we need to discuss rules of order.
I belive we have a constitution that probably lays out rules for this.
--
see shy jo
Oscar Levi
> Oscar Levi wrote:
> > Before this, I believe we need to discuss rules of order.
>
> I belive we have a constitution that probably lays out rules for this.
I see it.
My intuition tells me that either a) the mechanisms it outlines are
not in use or b) it does not describe the processes in great enough
detail to effect them.
Were either of these the case, there would be a list for project
announcements and a list called DFSG2.
James Troup
> I don't know if section 3(b) can cover our mismatched version, but
> it is estimated to double the size of the source archive if we need
> to include every version
With 7+ ports? I'd say that's a very conservative estimate.
--
James
Darren Benham
We have a kinda lenghthy process in the constitution... ;)
On 03-Dec-98 Joey Hess wrote:
> Oscar Levi wrote:
>> Thus, the first question is whether or not we believe the DFSG needs
>> to be changed.
>
> Well I can agree with that!
>
> Could we put this to a vote?
>
> --
> see shy jo
>
>
> --
> To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
>
>
>
=========================================================================
* http://benham.net/index.html <>< *
* -------------------- * -----BEGIN GEEK CODE BLOCK----- ---------------*
* Darren Benham * Version: 3.1 *
* <ge...@benham.net> * GCS d+(-) s:+ a29 C++$ UL++>++++ P+++$ L++>++++*
* * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS-- *
* Debian Developer * PE++ Y++ PGP++ t+ 5 X R+ !tv b++++ DI+++ D++ *
* <ge...@debian.org> * G++>G+++ e h+ r* y+ *
* -------------------- * ------END GEEK CODE BLOCK------ ---------------*
=========================================================================
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
iQCVAwUBNmc/5Lbps1lIfUYBAQF0tQP+NlPlcmvuxR4xzjd4+bEDHPvyRvcsU2CS
Qo262XR+jsiXTqzyEOIplEL3+4pQ38fdbXYaQpcqJjUUJF1Xdlp4Pa+3mEyiBsiv
jGANycQ4MeI3/943Dqz2iJQ8doS+EXO4xopb92V6IBENj5kv6b1DeGNoqluXKuMS
FFU4DQ5tUoc=
=EQ61
-----END PGP SIGNATURE-----
jo...@dhh.gt.org
> How is this significantly different than the advertising clause? One
> says "If you base your software on my software, you must credit me".
> The other says "If you use my software for publicized work, you must
> credit me."
The advertising clause applies only to distribution. The SWI clause
appears to apply to mere use.
--
John Hasler This posting is in the public domain.
jo...@dhh.gt.org Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
jo...@dhh.gt.org
> The advertising clause applies only to distribution. The SWI clause
> appears to apply to mere use.
> So the SWI clause is actually *more* restrictive! And as others have
> pointed out, the BSD advertising clause only applies if you explicitly
> mention the BSD derived software.
> My point was why is the SWI clause acceptable for free software (as Ian
> seemed to imply), and the BSDish clause not?
I think that Ian and I interpret the clause differently. He seems to read
it as applying only to distribution. I suspect that is the intent, but the
wording is so vague that it appears to me to apply to use as well.
> If anybody cares, my opinion is that both are acceptable.
What if I write a system utility in SWI Prolog? Someone might use it in
their research and not even know that they are using SWI Prolog.
--
John Hasler
jo...@dhh.gt.org (John Hasler)
Dancing Horse Hill
Elmwood, WI
Raul Miller
> If anybody cares, my opinion is that both are acceptable. License
> requirements that make it difficult or awkward to distribute or use
> software don't make it unfree.
Er.. license requirements that make software difficult to distribute can
indeed make it nonfree. For example, if the license says "you can only
distribute this software on Tuesday", we wouldn't be able to legally
distribute it without making structural changes -- and I don't think
many cdrom vendors would want to touch it.
License requirements which affect use in some fashion which is independent
of copying and distribution ("shrinkwrap licenses") are rather dubious,
and probably won't stand up in court. However, given that we've
usually tried to live within the restrictions imposed by the author
(both formal and informal restrictions), I think it's probably a good
idea to not distribute software if we think that people using it
freely would upset the author.
[Yeah, sometimes our not distributing software upsets the author,
but I do not see this as "terrorism", or even as a bad thing, as long
as our reasons are good. To me, good reasons to not distribute are:
author doesn't want it distributed, author won't let us distribute under
a license that we feel everyone can easily comply with, problems with
the software.]
--
Raul
Kristof...@ens-lyon.fr
> How is this significantly different than the advertising clause? One
> says "If you base your software on my software, you must credit me".
> The other says "If you use my software for publicized work, you must
> credit me."
IMHO (as expressed before) SWI-Prolog's condition is almost an instance of the
advertising clause with two variations:
1. it is only required for certain fields of endeavor (only academics are
required to reference :),
2. it is a restriction on the USE of the software since it applies even in
cases where no redistribution is in question.
This is an interesting combination that should be discussed...
Cheers,
Kristoffer
--
Kristoffer Høgsbro Rose, Ph.D., prof.associé <Kristof...@ENS-Lyon.FR>
Laboratoire de l'Informatique du Parallélisme équipe PLUME, bureau LR5-026
Ecole Normale Supérieure de Lyon; 46, Allée d'Italie; F-69364 Lyon 07 cedex
phone: +33(0)4 7272 8642; fax:...8080 <http://www.ens-lyon.fr/~krisrose>
Kristof...@ens-lyon.fr
> The advertising clause applies only to distribution. The SWI clause
> appears to apply to mere use.
Here is the clause in question:
6. If you base research on SWI-Prolog and publish on this research,
you must include appropriate acknowledgements and references to
SWI-Prolog in your publication.
Only when you publish academic results that *you* based on SWI-Prolog do
you have to acknowledge.
So...
> What if I write a system utility in SWI Prolog? Someone might use it in
> their research and not even know that they are using SWI Prolog.
My intepretation would be that this is perfectly legal: either the utility
was published about and then the acknowledgement is there. Or it wasn't
and all is well since the potential researcher did not base *her* research
on SWI-Prolog. Sic.
I say, let's keep it free: it is not a major nuisance (but a minor one, i
agree :)
Raul Miller
> Here is the clause in question:
>
> 6. If you base research on SWI-Prolog and publish on this research,
> you must include appropriate acknowledgements and references to
> SWI-Prolog in your publication.
>
> Only when you publish academic results that *you* based on SWI-Prolog do
> you have to acknowledge.
The problem here is that this is a "use" clause. A "shrinkwrap license".
The way copyright works, once you have a legal copy you can do what you
want with it. The copyright license grants the right to copy.
For example, you can't force someone to owe you money just because
they read a book of yours in a library. [Aside: we're programmers, and
we're used to dealing with imperatives and commands, and our instinctive
treatment of license documents seems to reflect that.]
But, that doesn't mean we shouldn't respect the license -- it does,
after all, reflect something of the author's wishes for the software.
So I think we should put this in non-free and that the maintainer should
contact the author for clarification on this issue.
--
Raul
Gregory Stark
Johnie Ingram <joh...@netgod.net> writes:
> "Tony" == Tony Finch <d...@dotat.at> writes:
>
> Tony> I think the major application that this will affect is Apache
> Tony> -- the Apache Group has control of the licence.
>
> It also affects ispell, the larger Apache modules, and everything with
> ssleay support (mutt-i etc.), if we assume this was carefully worded
> not to apply to University of California, Berkeley based software.
It would also exclude SSLeay, Kerberos, and AFS. Eric Young, Tim Hudson, and
the Swedish Kungliga Tekniska Högskolan are the usual suspects here.
> The advertising clause, though distasteful, affects very few people
> and doesn't make the software less free to use. It makes it less free
> to mention by name in your corporate press releases, which until now
> no one has claimed is an essential feature of free software (or Open
> Source).
In theory it would affect many people except that it's generally ignored with
impunity. Nobody has every to my knowledge been sued, or even threatened with
a suit based on it and some claim it isn't enforceable in the one jurisdiction
most companies care about. (Actually I think Berkeley did threaten AT&T/USL
since AT&T had, like everyone else, had completely ignored it even as they
threatened Berkeley over code taken from SysV.)
And it's certainly not just in corporate press releases that it's relevant.
The BSD clause and those based on it require mentions in _all_ advertising.
Adding even a single statement on advertising copy can be expensive -- adding
a laundry list of such clauses covering whatever software provides the
features mentioned in the ad would be impossible. This is a real danger,
various BSD distributions do ship with guides for commercial users listing the
various clauses needed depending on which features are mentioned in
advertisements.
It's somewhat irksome that the very meaninglessness of these clauses is used
to justify their continued use, on the grounds that no one seems to be
inconvenienced. I wonder if Microsoft released some useful little utility with
a similar clause, would people be happy about our distributors being forced to
advertise Microsoft if they want to describe the features of our distribution
effectively?
greg
Gregory Stark
For the record I think we have to do something like Ian's new DFSG. The key
aspect I find compelling about the new DFSG is the method of disallowing *all*
restrictions, and then exempting specific types of restrictions. In the long
term this method is actually far more robust than trying to list every type of
restriction we don't like.
A few miscellaneous related opinions and responses (I haven't been reading my
mail every day and so this is a kind of batch reply to lots of posts in this
thread):
Wooly language yay: I don't believe any attempt to make language more precise
by making it wordier has actually yielded fewer arguments over its meaning.
The existing DFSG is direct and explicit, it's quite well-written, I just
think the new methodology is better. Ideally I think we need a DFSG about the
length and precision of the old one but in the format of the new one where it
prohibits everything and then lists exceptions allowed.
Patch releases boo: I would never undertake to manage a software derivative
that I had to distribute via a patch, and if I wouldn't want to do it then I'm
not comfortable saying it's ok for me to require others to. I don't want to
prohibit Qt et al completely though, I'm beginning to think we need a class of
software we consider free enough to include in the distribution but not free
enough to consider "core" Debian software.
Mutable standards yay: The claim that mutable standards are anathema (is that
even proper grammar? :) is poppycock. An exception to allow requirements to
change the name on such changes is plenty of protection for standards and as
much protection as any copyright can really provide in any case.
Argument by assertion; Argument by repetition; Personal attacks; etc: BOO!
Please everyone just state your opinion, response to questions and arguments
with factual argumentative responses, don't just say "no you're stil wrong,
nyah nyah!"
--
Milan Zamazal
RM> and that the maintainer should contact the author for
RM> clarification on this issue.
I've already done it. I think it would be best to stop speculations
about SWI Prolog license until I receive some answer. Of course, this
doesn't mean we should stop discussing general implications pointed out
by this license, they are quite interesting.
>>>>> "KR" == Kristoffer Rose <Kristof...@ENS-Lyon.FR> writes:
KR> IMHO (as expressed before) SWI-Prolog's condition is almost an
KR> instance of the advertising clause with two variations:
KR> 1. it is only required for certain fields of endeavor (only
KR> academics are required to reference :),
No. Everyone who publishes is affected. It doesn't "discriminate"
e.g. AI researchers.
If it was considered as a discrimination of academics, I would say GPL
discriminates programmers (they are the only making derived works),
since they must write date and description of each their change.
KR> 2. it is a restriction on the USE of the software since it
KR> applies even in cases where no redistribution is in question.
This is a question. You can look on publication which was received
through the program as a derived work of some kind. It can be looked in
similar way as e.g. output of ray tracer or compiler.
You can use the program as you like. Only if you derive some output of
it and want to distribute it (publish), you must satisfy certain
conditions (to give credit).
I don't know whether this requirement has bad implications like the
advertisement clause has. (Are we talking about problems implicated by
the advertisement clause and not about advertisement clause as an evil,
aren't we?)
Milan Zamazal
Milan Zamazal
IJ> Milan Zamazal writes ("Re: Draft new DFSG - r1.4"): ...
>> When I was going to move SWI Prolog from non-free to main, I
>> asked about its license on debian-devel and the conclusion was
>> it's DFSG free.
IJ> I think that it might be reasonable to add an exception for such
IJ> `must credit' licences.
IJ> Would you like to mail me or post a suggestion or shall I write
IJ> one ?
Please try write it, you are better in wording.
IJ> When we're a project of 400 people, as prominent as we are, we
IJ> must act in a consistent, accountable and rational way.
[...]
IJ> But, if we do that, what political position will we find
IJ> ourselves in when MegaFooCorp want us to ship their program and
IJ> having included a questionable clause in their licence ?
I admit these (unlike some other) are valid reasons worth considering
DFSG2.