pod/perlpolicy.pod

   1 =head1 NAME
   2
   3 perlpolicy - Various and sundry policies and commitments related to the perl core
   4
   5 =head1 DESCRIPTION
   6
   7 This document is the master document which records all written
   8 policies about how the Perl 5 Porters collectively develop and maintain
   9 the Perl core.
  10
  11
  12
  13 =head1 CONTRIBUTED MODULES
  14
  15
  16 =head2 A Social Contract about Artistic Control
  17
  18 What follows is a statement about artistic control, defined as the ability
  19 of authors of packages to guide the future of their code and maintain
  20 control over their work.  It is a recognition that authors should have
  21 control over their work, and that it is a responsibility of the rest of
  22 the Perl community to ensure that they retain this control.  It is an
  23 attempt to document the standards to which we, as Perl developers, intend
  24 to hold ourselves.  It is an attempt to write down rough guidelines about
  25 the respect we owe each other as Perl developers.
  26
  27 This statement is not a legal contract.  This statement is not a legal
  28 document in any way, shape, or form.  Perl is distributed under the GNU
  29 Public License and under the Artistic License; those are the precise legal
  30 terms.  This statement isn't about the law or licenses.  It's about
  31 community, mutual respect, trust, and good-faith cooperation.
  32
  33 We recognize that the Perl core, defined as the software distributed with
  34 the heart of Perl itself, is a joint project on the part of all of us.
  35 From time to time, a script, module, or set of modules (hereafter referred
  36 to simply as a "module") will prove so widely useful and/or so integral to
  37 the correct functioning of Perl itself that it should be distributed with
  38 Perl core.  This should never be done without the author's explicit
  39 consent, and a clear recognition on all parts that this means the module
  40 is being distributed under the same terms as Perl itself.  A module author
  41 should realize that inclusion of a module into the Perl core will
  42 necessarily mean some loss of control over it, since changes may
  43 occasionally have to be made on short notice or for consistency with the
  44 rest of Perl.
  45
  46 Once a module has been included in the Perl core, however, everyone
  47 involved in maintaining Perl should be aware that the module is still the
  48 property of the original author unless the original author explicitly
  49 gives up their ownership of it.  In particular:
  50
  51 =over
  52
  53 =item *
  54
  55 The version of the module in the core should still be considered the
  56 work of the original author.  All patches, bug reports, and so
  57 forth should be fed back to them.  Their development directions
  58 should be respected whenever possible.
  59
  60 =item *
  61
  62 Patches may be applied by the pumpkin holder without the explicit
  63 cooperation of the module author if and only if they are very minor,
  64 time-critical in some fashion (such as urgent security fixes), or if
  65 the module author cannot be reached.  Those patches must still be
  66 given back to the author when possible, and if the author decides on
  67 an alternate fix in their version, that fix should be strongly
  68 preferred unless there is a serious problem with it.  Any changes not
  69 endorsed by the author should be marked as such, and the contributor
  70 of the change acknowledged.
  71
  72 =item *
  73
  74 The version of the module distributed with Perl should, whenever
  75 possible, be the latest version of the module as distributed by the
  76 author (the latest non-beta version in the case of public Perl
  77 releases), although the pumpkin holder may hold off on upgrading the
  78 version of the module distributed with Perl to the latest version
  79 until the latest version has had sufficient testing.
  80
  81 =back
  82
  83 In other words, the author of a module should be considered to have final
  84 say on modifications to their module whenever possible (bearing in mind
  85 that it's expected that everyone involved will work together and arrive at
  86 reasonable compromises when there are disagreements).
  87
  88 As a last resort, however:
  89
  90
  91 If the author's vision of the future of their module is sufficiently
  92 different from the vision of the pumpkin holder and perl5-porters as a
  93 whole so as to cause serious problems for Perl, the pumpkin holder may
  94 choose to formally fork the version of the module in the core from the
  95 one maintained by the author.  This should not be done lightly and
  96 should B<always> if at all possible be done only after direct input
  97 from Larry.  If this is done, it must then be made explicit in the
  98 module as distributed with Perl core that it is a forked version and
  99 that while it is based on the original author's work, it is no longer
 100 maintained by them.  This must be noted in both the documentation and
 101 in the comments in the source of the module.
 102
 103 Again, this should be a last resort only.  Ideally, this should never
 104 happen, and every possible effort at cooperation and compromise should be
 105 made before doing this.  If it does prove necessary to fork a module for
 106 the overall health of Perl, proper credit must be given to the original
 107 author in perpetuity and the decision should be constantly re-evaluated to
 108 see if a remerging of the two branches is possible down the road.
 109
 110 In all dealings with contributed modules, everyone maintaining Perl should
 111 keep in mind that the code belongs to the original author, that they may
 112 not be on perl5-porters at any given time, and that a patch is not
 113 official unless it has been integrated into the author's copy of the
 114 module.  To aid with this, and with points #1, #2, and #3 above, contact
 115 information for the authors of all contributed modules should be kept with
 116 the Perl distribution.
 117
 118 Finally, the Perl community as a whole recognizes that respect for
 119 ownership of code, respect for artistic control, proper credit, and active
 120 effort to prevent unintentional code skew or communication gaps is vital
 121 to the health of the community and Perl itself.  Members of a community
 122 should not normally have to resort to rules and laws to deal with each
 123 other, and this document, although it contains rules so as to be clear, is
 124 about an attitude and general approach.  The first step in any dispute
 125 should be open communication, respect for opposing views, and an attempt
 126 at a compromise.  In nearly every circumstance nothing more will be
 127 necessary, and certainly no more drastic measure should be used until
 128 every avenue of communication and discussion has failed.
 129
 130 =head1 CREDITS
 131
 132 Social Contract about Contributed Modules originally by Russ Allbery E<lt>rra@stanford.eduE<gt> and the perl5-porters.
 133