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

Copyright and License Guidelines



Hi all:

I have prepared the following patch to policy.pod. Please review and
submit comments as appropriate:

Index: policy.pod
===================================================================
--- policy.pod  (revision 69969)
+++ policy.pod  (working copy)
@@ -254,6 +254,89 @@

 =back

+=head1 Copyright and License Information
+
+One of Debian's core values is the notion of "free, as in freedom" -- indeed,
+the L<Debian Social Contract|http://debian.org/social_contract> speaks of
+Debian's mandate to remain 100% free and give back to the free software
+community.
+
+The Debian Perl Group B<strongly prefers> free software. In order to constitute
+free software, packages must:
+
+=over
+
+=item 1
+
+Be licensed under terms compatible with the L<Debian Free Software Guidelines|
+http://debian.org/social_contract#guidelines> (DFSG).
+
+=item 2
+
+Provide applicable year(s) of copyright, as well as information about the
+copyright holder(s), including: each legal entity's full name and contact
+information (e-mail or web site address).
+
+=back
+
+This information, collected for each and every file in a package, is provided
+to our users through a machine-parseable file called b<debian/copyright>, as
+defined in L<DEP5|http://dep.debian.net/deps/dep5/>.
+
+=head2 Team-Maintained Software
+
+Often, large software projects are maintained by numerous members of a team.
+Historically, Perl software has been developed quite informally, without
+anything resembling the L<Contributor License Agreement|
+http://en.wikipedia.org/wiki/Contributor_License_Agreement>s (CLA) seen
+frequently in large corporate-sponsored open source projects.
+
+Among other things, these agreements simplify copyright information by
+ensuring that all contributions are assigned to a single copyright holder,
+often the sponsoring organization.
+
+Because Perl modules do not have these agreements, copyright is held by
+each contributor on each piece of their own work by default, which raises
+some complex issues in an ever-changing legal landscape. Moreover, because
+teams tend to maintain multiple modules and software packages, keeping the
+information correct in each B<debian/copyright> file becomes a daunting
+task.
+
+=head3 Synchronizing copyright information
+
+In many cases, members should manually synchronize copyright information
+for major projects. It is recommended that this information be maintained
+as part of L<copyright.pod> in order to provide a single source of common
+contributor contact information.
+
+Unfortunately, despite the added workload, there is no other way we can
+guarantee that our users receive appropriate machine-readable copyright
+information along with the packages they install. In general, the practice
+of referring to copyright information in other packages is discouraged.
+
+=head3 Dependent packages
+
+Where a team maintains some packages that depend on a single "parent"
+package (for example, a project with a main package as well as plugins),
+it is possible to refer to information in the "parent" package.
+
+For example, the C<Catalyst> project provides utilities and plugins that
+depend on the B<libcatalyst-perl> package. Consider this copyright clause
+as provided in C<Catalyst::Devel>'s B<debian/copyright> file:
+
+  Files: *
+  Copyright: 2006-2009, various contributors to the Catalyst project
+  License: Artistic or GPL-1+
+  X-Comment: for a full list of copyright holders, please see copyright
+   information for the libcatalyst-perl package.
+
+In this case, it is permissible to refer to the B<libcatalyst-perl>
+package, since it must be available on the system in question. Note that
+this only applies to modules that have a strict dependency on the parent
+package. This means modules that I<Suggest> or I<Recommend> a module
+cannot consider that module to be a "parent", and thus must provide a
+duplicate copy of the copyright information.
+
 =head1 Debian Maintainers practice

 The Debian project has adopted the Debian Maintainers (DM) concept (cf.

Cheers,

Jonathan


Reply to: