Clearly, developing scripts and modules in Perl at Apache is no problem.
However, it's not clear that it is permissible to develop bindings which link
compiled C code to create dynamically loaded XS modules.

To create such bindings, you need to incorporate three header files which are
distributed with the Perl 5 core – XSUB.h, perl.h, and EXTERN.h – which
provide access to Perl's extensive C API. We define Perl as a system
requirement, so there's no need to worry about distributing those files – we
assume that they'll be present on the target system. The question is whether
the binding specification, which will be a derivative work of those headers,
can be developed at Apache.

The files in question are licensed, with the rest of Perl 5, under
GPL-any/Artistic1, with exceptions:

http://dev.perl.org/licenses/

For those of you that choose to use the GNU General Public License, my
interpretation of the GNU General Public License is that no Perl script
falls under the terms of the GPL unless you explicitly put said script
under the terms of the GPL yourself.

Furthermore, any object code linked with perl does not automatically fall
under the terms of the GPL, provided such object code only adds
definitions of subroutines and variables, and does not otherwise impair
the resulting interpreter from executing any standard Perl script. I
consider linking in C subroutines in this manner to be the moral
equivalent of defining subroutines in the Perl language itself. You may
sell such an object file as proprietary provided that you provide or offer
to provide the Perl source, as specified by the GNU General Public
License. (This is merely an alternate way of specifying input to the
program.) You may also sell a binary produced by the dumping of a running
Perl script that belongs to you, provided that you provide or offer to
provide the Perl source as specified by the GPL. (The fact that a Perl
interpreter and your code are in the same binary file is, in this case, a
form of mere aggregation.)

This is my interpretation of the GPL. If you still have concerns or
difficulties understanding my intent, feel free to contact me. Of course,
the Artistic License spells all this out for your protection, so you may
prefer to use that.

Legally, I believe that so long as such bindings comply with the terms spelled
out in the exceptions, the GPL does not kick in and distribution under ASL is
permissible.

+1 to adding "XSUB.h, perl.h, and EXTERN.h" to http://www.apache.org/legal/resolved.html as being acceptable to included in Apache distributions.

+1

Any other opinions before I write up?

Robert

Proposed:

• Developing Perl bindings which link compiled C code to create dynamically loaded XS modules requires the distributing of XSUB.h, perl.h and EXTERN.h, all licensed under the Perl license (http://dev.perl.org/licenses/ - GPL-any/Artistic1, with exceptions). Can we do this?
• Yes, these files may be included in Apache distributions (link: LEGAL-79).

These files (XSUB.h, perl.h, EXTERN.h) do not need to be distributed – you just need to link against them and utilize macros and inline functions from them.

Alternate:

• Developing Perl bindings which link compiled C code to create dynamically loaded XS modules requires including the header files XSUB.h, perl.h and EXTERN.h, all licensed under the Perl license (http://dev.perl.org/licenses/ - GPL-any/Artistic1, with exceptions). Can we do this?
• Yes. (link: LEGAL-79).

+1.

Published on resolved.html. I changed it slightly as our new website look and feel doesn't work well for very long questions.

Can we include Perl licensed header files when creating dynamically loaded XS modules?

Yes (LEGAL-79). Developing Perl bindings which link compiled C code to create dynamically loaded XS modules requires including header files licensed under the Perl license (http://dev.perl.org/licenses/ - GPL-any/Artistic1, with exceptions). You may include these header files - XSUB.h, perl.h and EXTERN.h.