(reply-to set to debian-vote)
Happy new year, world,
Here's another possible revision of the DFSG for your perusal and comment.
The differences between this and the DFSGv1 are probably reasonably
obvious: this is a fair bit stricter, and covers some areas which
really ought to be in the DFSG but hadn't been thought of at the time
(termination of license in particular). I think it's also a much better
platform for people trying to draft open source/DFSG-free licenses than
the DFSGv1, and serves as a better platform for explaining why some
things may be technically "free", but are better avoided where possible.
The more important differences are those between this and Ian's draft
DFSGv2. In particular:
* This is written more casually. They're left as guidelines,
not rules, and there are areas which are left up to
interpretation.
* Stuff has been rearranged to suit my way of looking at things.
* The section on patents is gone. I think Ian's rules are a
too agressive, but I don't have anything to replace them
with.
* The section on documentation is gone. There's a note at the
bottom about it, but I'm not really comfortable with saying
anything very much about it, beyond "program documentation
must be DFSG-free, and I'm not commenting on anything but
programs and related works". We probably ought to have some
DF-non-software-Gs, but I'm not really sure what they'd contain.
Perhaps Debian should give it up, and stick to distributing
software. Perhaps we should separate pure-documentation from
main. I dunno.
* The patch clause is back.
* The MPL and the QPL make it in as "example licenses".
AFAICT, the MPL isn't a DFSGv2-free license according to Ian's proposal --
the requirements that source *must* be distributed for 6 or 12 months
aren't allowed. They're left up to our judgement in the following proposal,
under the "require that a reasonable attempt be made to make the source
code of the work available" clause.
BTW, we don't comply with the MPL at the moment, according to my reading --
new Mozilla sources disappear before six months are up, when we upload a
new snapshot.
Anyway. On with the show:
---------------------------------------------------------------------------
DRAFT Debian Free Software Guidelines DRAFT
version 2
-------------
For a work to be considered DFSG-free, the copyright holder must
explicitly grant the permissions enumerated in the first section,
and may incorporate no other restrictions than those enumerated in the
second section.
Permissions
===========
1. Use
The license must allow anyone who has legally obtained the work to use
it in any way.
2. Source Code
Source code must be available.
3. Redistribution
Anyone must be able to give copies away, sell them, or not. The license
may not make any restrictions on who redistributes the work or how
that work is redistributed.
4. Derived Works
Derived works (both modified source code, and executables) must be
freely usable and redistributable under a license that satisfies these
guidelines.
5. Termination of License
The license must remain valid until voluntarily terminated by the
licensee.
Restrictions
============
1. 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).
2. Notices of Authorship
The license may require the copyright, license, and any associated
disclaimers be prominently displayed. The license may require such
notices to be displayed during execution of the work, or included in the
source code, the documentation, or advertising materials (deprecated)
related to the derived work.
3. Misrepresentation of Authors
The license may restrict the unauthorised use of the names of the
authors and copyright holders, or trademarks held by the authors or
copyright holders, to endorse or promote derived works. The license
may also restrict other forms of misrepresentation.
4. License of Derived Works
The license may make requirements about the kinds of license (or
the specific license) under which the work, or that part of the work
included in derived works, is covered, so long as it remains possible
to distribute derived works under these guidelines.
The license may require that derived works in their entirety be
distributed according to its requirements. This may extend to all the
source files required to produce the derived work, as well as any
code libraries used by the work, whether linked at compile time or
runtime. It may not extend to works which merely reside on the same
media as the derived work.
5. Availability of source code
The license may require that a reasonable attempt be made to make the
source code of the work available along with executable versions of
the software or any derived works.
6. Integrity of the Original Work
The license may use one of the following methods to ensure the integrity
of the original work:
a) Change log
Derived works may be required to summarise changes made from
the author's code. Such summaries may be required to be
included in:
a) the source code of the derived work.
b) documentation accompanying a derived work.
c) the derived work itself, and to be displayed
when the derived work is executed (for interactive
programs)
b) Versioning and Renaming
Derived works may be required to use a different version
number to official releases or a different name.
c) Concurrent installation of Official and Derived Works (deprecated)
Derived works may be required to be able to exist concurrently
with an official release of the work, for example by requiring
derived works to use different executable names to the
official release.
d) Original source (deprecated)
Distribution of derived works may be required to be accompanied
by an offer to distribute the original source code.
e) Patch clause (deprecated)
Source level modifications may be required to be distributed
as the original source, along with a list of differences.
Notes
=====
1. Non-binding Requests
The license may make any number of non-binding requests. These should
be clearly separated from the binding section of the license.
2. Weaker Restrictions
The license may make weaker restrictions than the above.
3. Application
These guidelines refer only to software products -- that is
machine-readable programs that instruct the computer how to perform
certain tasks, and items directly related to such programs, most
notably their source code, and documentation. These guidelines do not
refer to opinion pieces, documents from standards bodies, and similar
non-executable works.
4. Source Code
These guidelines use the term "source code" in the same way as does
the GNU General Public License version 2: the source code for a work
means the preferred form of the work for making modifications to it.
5. Example Licenses
As examples, we consider the following licenses DFSG-free:
a) the Artistic License
b) the BSD License
c) the GNU General Public License (GPL)
d) the GNU Library General Public License (LGPL)
e) the Mozilla Public License (MPL)
f) the Q Public License (QPL)
DRAFT DRAFT
---------------------------------------------------------------------------
BTW, to other people reading this -- please don't take this as the
thought out opinion of the Debian project. I'm not even sure it's *my*
thought out opinion yet.
I'd envisage a rationale document explaining what effect including
particular restrictions in your license might have: in particular which
things make the work GPL-incompatible, which things make distribution
painful, which things make reusing code in other projects difficult or
impossible, and so on.
(Are there any plans to reaffirm our "social contract" too, btw?)
Flame on.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``Like the ski resort of girls looking for husbands and husbands looking
for girls, the situation is not as symmetrical as it might seem.''
Attachment:
pgpCOZgdQ7qqQ.pgp
Description: PGP signature