Move the new "perl policy" document into pod/

1 files changed, 131 insertions, 0 deletions

diff --git a/pod/perlpolicy.pod b/pod/perlpolicy.pod
new file mode 100644
index 0000000000..fbb6bc5819
--- /dev/null
+++ b/pod/perlpolicy.pod
@@ -0,0 +1,131 @@
+=head1 NAME
+
+perlpolicy - Various and sundry policies and commitments related to the perl core
+
+=head1 DESCRIPTION
+
+This document is the master document which records all written
+policies about how the Perl 5 Porters collectively develop and maintain
+the Perl core.
+
+
+
+=head1 CONTRIBUTED MODULES
+
+
+=head2 A Social Contract about Artistic Control
+
+What follows is a statement about artistic control, defined as the ability
+of authors of packages to guide the future of their code and maintain
+control over their work.  It is a recognition that authors should have
+control over their work, and that it is a responsibility of the rest of
+the Perl community to ensure that they retain this control.  It is an
+attempt to document the standards to which we, as Perl developers, intend
+to hold ourselves.  It is an attempt to write down rough guidelines about
+the respect we owe each other as Perl developers.
+
+This statement is not a legal contract.  This statement is not a legal
+document in any way, shape, or form.  Perl is distributed under the GNU
+Public License and under the Artistic License; those are the precise legal
+terms.  This statement isn't about the law or licenses.  It's about
+community, mutual respect, trust, and good-faith cooperation.
+
+We recognize that the Perl core, defined as the software distributed with
+the heart of Perl itself, is a joint project on the part of all of us.
+From time to time, a script, module, or set of modules (hereafter referred
+to simply as a "module") will prove so widely useful and/or so integral to
+the correct functioning of Perl itself that it should be distributed with
+Perl core.  This should never be done without the author's explicit
+consent, and a clear recognition on all parts that this means the module
+is being distributed under the same terms as Perl itself.  A module author
+should realize that inclusion of a module into the Perl core will
+necessarily mean some loss of control over it, since changes may
+occasionally have to be made on short notice or for consistency with the
+rest of Perl.
+
+Once a module has been included in the Perl core, however, everyone
+involved in maintaining Perl should be aware that the module is still the
+property of the original author unless the original author explicitly
+gives up their ownership of it.  In particular:
+
+=over
+
+=item *  The version of the module in the core should still be considered the
+    work of the original author.  All patches, bug reports, and so forth
+    should be fed back to them.  Their development directions should be
+    respected whenever possible.
+
+=item *
+
+Patches may be applied by the pumpkin holder without the explicit
+cooperation of the module author if and only if they are very minor,
+time-critical in some fashion (such as urgent security fixes), or if
+the module author cannot be reached.  Those patches must still be
+given back to the author when possible, and if the author decides on
+an alternate fix in their version, that fix should be strongly
+preferred unless there is a serious problem with it.  Any changes not
+endorsed by the author should be marked as such, and the contributor
+of the change acknowledged.
+
+=item *
+
+The version of the module distributed with Perl should, whenever
+possible, be the latest version of the module as distributed by the
+author (the latest non-beta version in the case of public Perl
+releases), although the pumpkin holder may hold off on upgrading the
+version of the module distributed with Perl to the latest version
+until the latest version has had sufficient testing.
+
+=back
+
+In other words, the author of a module should be considered to have final
+say on modifications to their module whenever possible (bearing in mind
+that it's expected that everyone involved will work together and arrive at
+reasonable compromises when there are disagreements).
+
+As a last resort, however:
+
+
+If the author's vision of the future of their module is sufficiently
+different from the vision of the pumpkin holder and perl5-porters as a
+whole so as to cause serious problems for Perl, the pumpkin holder may
+choose to formally fork the version of the module in the core from the
+one maintained by the author.  This should not be done lightly and
+should *always* if at all possible be done only after direct input
+from Larry.  If this is done, it must then be made explicit in the
+module as distributed with Perl core that it is a forked version and
+that while it is based on the original author's work, it is no longer
+maintained by them.  This must be noted in both the documentation and
+in the comments in the source of the module.
+
+Again, this should be a last resort only.  Ideally, this should never
+happen, and every possible effort at cooperation and compromise should be
+made before doing this.  If it does prove necessary to fork a module for
+the overall health of Perl, proper credit must be given to the original
+author in perpetuity and the decision should be constantly re-evaluated to
+see if a remerging of the two branches is possible down the road.
+
+In all dealings with contributed modules, everyone maintaining Perl should
+keep in mind that the code belongs to the original author, that they may
+not be on perl5-porters at any given time, and that a patch is not
+official unless it has been integrated into the author's copy of the
+module.  To aid with this, and with points #1, #2, and #3 above, contact
+information for the authors of all contributed modules should be kept with
+the Perl distribution.
+
+Finally, the Perl community as a whole recognizes that respect for
+ownership of code, respect for artistic control, proper credit, and active
+effort to prevent unintentional code skew or communication gaps is vital
+to the health of the community and Perl itself.  Members of a community
+should not normally have to resort to rules and laws to deal with each
+other, and this document, although it contains rules so as to be clear, is
+about an attitude and general approach.  The first step in any dispute
+should be open communication, respect for opposing views, and an attempt
+at a compromise.  In nearly every circumstance nothing more will be
+necessary, and certainly no more drastic measure should be used until
+every avenue of communication and discussion has failed.
+
+=head1 CREDITS
+
+Social Contract about Contributed Modules originall by Russ Allbery E<lt>rra@stanford.eduE<gt> and the perl5-porters.
+