Details

    • Type: Question
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:

      Description

      Is it permissible to use Perl's C API to develop "XS" bindings at Apache?

        Activity

        Hide
        creamyg Marvin Humphrey added a comment -

        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.

        Show
        creamyg Marvin Humphrey added a comment - 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.
        Hide
        rubys Sam Ruby added a comment -

        +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.

        Show
        rubys Sam Ruby added a comment - +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.
        Hide
        robertburrelldonkin Robert Burrell Donkin added a comment -

        +1

        Any other opinions before I write up?

        Robert

        Show
        robertburrelldonkin Robert Burrell Donkin added a comment - +1 Any other opinions before I write up? Robert
        Hide
        bayard Henri Yandell added a comment -

        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).
        Show
        bayard Henri Yandell added a comment - 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 ).
        Hide
        creamyg Marvin Humphrey added a comment -

        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).
        Show
        creamyg Marvin Humphrey added a comment - 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 ).
        Hide
        bayard Henri Yandell added a comment -

        +1.

        Show
        bayard Henri Yandell added a comment - +1.
        Hide
        bayard Henri Yandell added a comment -

        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.

        Show
        bayard Henri Yandell added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            creamyg Marvin Humphrey
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development