(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 <email@example.com> <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.''
Description: PGP signature