| 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 * The version of the module in the core should still be considered the |
| 54 | work of the original author. All patches, bug reports, and so forth |
| 55 | should be fed back to them. Their development directions should be |
| 56 | respected whenever possible. |
| 57 | |
| 58 | =item * |
| 59 | |
| 60 | Patches may be applied by the pumpkin holder without the explicit |
| 61 | cooperation of the module author if and only if they are very minor, |
| 62 | time-critical in some fashion (such as urgent security fixes), or if |
| 63 | the module author cannot be reached. Those patches must still be |
| 64 | given back to the author when possible, and if the author decides on |
| 65 | an alternate fix in their version, that fix should be strongly |
| 66 | preferred unless there is a serious problem with it. Any changes not |
| 67 | endorsed by the author should be marked as such, and the contributor |
| 68 | of the change acknowledged. |
| 69 | |
| 70 | =item * |
| 71 | |
| 72 | The version of the module distributed with Perl should, whenever |
| 73 | possible, be the latest version of the module as distributed by the |
| 74 | author (the latest non-beta version in the case of public Perl |
| 75 | releases), although the pumpkin holder may hold off on upgrading the |
| 76 | version of the module distributed with Perl to the latest version |
| 77 | until the latest version has had sufficient testing. |
| 78 | |
| 79 | =back |
| 80 | |
| 81 | In other words, the author of a module should be considered to have final |
| 82 | say on modifications to their module whenever possible (bearing in mind |
| 83 | that it's expected that everyone involved will work together and arrive at |
| 84 | reasonable compromises when there are disagreements). |
| 85 | |
| 86 | As a last resort, however: |
| 87 | |
| 88 | |
| 89 | If the author's vision of the future of their module is sufficiently |
| 90 | different from the vision of the pumpkin holder and perl5-porters as a |
| 91 | whole so as to cause serious problems for Perl, the pumpkin holder may |
| 92 | choose to formally fork the version of the module in the core from the |
| 93 | one maintained by the author. This should not be done lightly and |
| 94 | should *always* if at all possible be done only after direct input |
| 95 | from Larry. If this is done, it must then be made explicit in the |
| 96 | module as distributed with Perl core that it is a forked version and |
| 97 | that while it is based on the original author's work, it is no longer |
| 98 | maintained by them. This must be noted in both the documentation and |
| 99 | in the comments in the source of the module. |
| 100 | |
| 101 | Again, this should be a last resort only. Ideally, this should never |
| 102 | happen, and every possible effort at cooperation and compromise should be |
| 103 | made before doing this. If it does prove necessary to fork a module for |
| 104 | the overall health of Perl, proper credit must be given to the original |
| 105 | author in perpetuity and the decision should be constantly re-evaluated to |
| 106 | see if a remerging of the two branches is possible down the road. |
| 107 | |
| 108 | In all dealings with contributed modules, everyone maintaining Perl should |
| 109 | keep in mind that the code belongs to the original author, that they may |
| 110 | not be on perl5-porters at any given time, and that a patch is not |
| 111 | official unless it has been integrated into the author's copy of the |
| 112 | module. To aid with this, and with points #1, #2, and #3 above, contact |
| 113 | information for the authors of all contributed modules should be kept with |
| 114 | the Perl distribution. |
| 115 | |
| 116 | Finally, the Perl community as a whole recognizes that respect for |
| 117 | ownership of code, respect for artistic control, proper credit, and active |
| 118 | effort to prevent unintentional code skew or communication gaps is vital |
| 119 | to the health of the community and Perl itself. Members of a community |
| 120 | should not normally have to resort to rules and laws to deal with each |
| 121 | other, and this document, although it contains rules so as to be clear, is |
| 122 | about an attitude and general approach. The first step in any dispute |
| 123 | should be open communication, respect for opposing views, and an attempt |
| 124 | at a compromise. In nearly every circumstance nothing more will be |
| 125 | necessary, and certainly no more drastic measure should be used until |
| 126 | every avenue of communication and discussion has failed. |
| 127 | |
| 128 | =head1 CREDITS |
| 129 | |
| 130 | Social Contract about Contributed Modules originall by Russ Allbery E<lt>rra@stanford.eduE<gt> and the perl5-porters. |
| 131 | |