Commit | Line | Data |
---|---|---|
48cb5b3a | 1 | =head1 NAME |
3c78fafa | 2 | |
48cb5b3a JV |
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 | |
6ee623d5 GS |
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. | |
aaa2bbb1 | 35 | From time to time, a script, module, or set of modules (hereafter referred |
6ee623d5 GS |
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 | ||
48cb5b3a JV |
51 | =over |
52 | ||
53 | =item * The version of the module in the core should still be considered the | |
6ee623d5 GS |
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 | ||
48cb5b3a JV |
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 | |
6ee623d5 GS |
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 | ||
48cb5b3a JV |
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 | |
c4f5d98d | 94 | should B<always> if at all possible be done only after direct input |
48cb5b3a JV |
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. | |
6ee623d5 GS |
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. | |
3c78fafa | 127 | |
48cb5b3a JV |
128 | =head1 CREDITS |
129 | ||
76caf4b8 | 130 | Social Contract about Contributed Modules originally by Russ Allbery E<lt>rra@stanford.eduE<gt> and the perl5-porters. |
3c78fafa | 131 |