[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

DFSGv2 -- another approach



(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: pgptDxlhZKdiv.pgp
Description: PGP signature


Reply to: