Using embedded PERL with commercial applications?

Discussion in 'Perl Misc' started by Patrick Finnegan, Nov 24, 2004.

  1. We just had a discussion in the Office about the use of embedded Perl
    with commercial applications. Three of the server applications used
    in the corporate environment, WebSphere, Control SA and Cisco
    Networks, use Tcl or a Tcl derivative as the embedded scripting
    interface. Is there a licensing limitation on the use of embedded
    PERL with commercial applications?
    Patrick Finnegan, Nov 24, 2004
    #1
    1. Advertising

  2. [F'up to comp.lang.perl.misc]

    Also sprach Patrick Finnegan:
    > We just had a discussion in the Office about the use of embedded Perl
    > with commercial applications. Three of the server applications used
    > in the corporate environment, WebSphere, Control SA and Cisco
    > Networks, use Tcl or a Tcl derivative as the embedded scripting
    > interface. Is there a licensing limitation on the use of embedded
    > PERL with commercial applications?


    The Perl license includes both the GPL (which would be a problem here)
    and the Artistic license. You can pick the one you like better which in
    your case will be the Artistic license. It states (paragraph 8):

    8. Aggregation of this Package with a commercial distribution is
    always permitted provided that the use of this Package is embedded;
    that is, when no overt attempt is made to make this Package's
    interfaces visible to the end user of the commercial distribution.
    Such use shall not be construed as a distribution of this Package.

    Although I am not entirely sure what interfaces (I assume it's the
    interface to the source-code) would be in this case, I read it as a
    permission to embed it into commercial applications with little or no
    limitations. But then, only lawyers understand those licenses.

    As a practical note: AFAIR it has never happened that the
    copyright-holder of perl (which would be Larry himself) has ever sued
    anyone for infringements of this license. Perl is known to be very
    friendly to commercial use. But if you want to be absolutely sure, send
    a mail to Larry Wall and ask.

    Tassilo
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
    Tassilo v. Parseval, Nov 24, 2004
    #2
    1. Advertising

  3. Tassilo v. Parseval wrote:
    > The Perl license includes both the GPL (which would be a problem here)
    > and the Artistic license. You can pick the one you like better which in
    > your case will be the Artistic license. It states (paragraph 8):
    >
    > 8. Aggregation of this Package with a commercial distribution is
    > always permitted provided that the use of this Package is embedded;
    > that is, when no overt attempt is made to make this Package's
    > interfaces visible to the end user of the commercial distribution.
    > Such use shall not be construed as a distribution of this Package.


    To me that says "You can implement your functionality using Perl, and
    embed Perl to ensure that that functionality operates, but you can't
    expose Perl scripting without falling under the restrictions due to
    the AL."

    By contrast, Tcl's license is "As long as you don't claim you wrote
    Tcl or sue us, embed away in any way that suits you." Much easier to
    get past the suits. :^)

    Donal.
    Donal K. Fellows, Nov 24, 2004
    #3
  4. Also sprach Donal K. Fellows:

    > Tassilo v. Parseval wrote:
    >> The Perl license includes both the GPL (which would be a problem here)
    >> and the Artistic license. You can pick the one you like better which in
    >> your case will be the Artistic license. It states (paragraph 8):
    >>
    >> 8. Aggregation of this Package with a commercial distribution is
    >> always permitted provided that the use of this Package is embedded;
    >> that is, when no overt attempt is made to make this Package's
    >> interfaces visible to the end user of the commercial distribution.
    >> Such use shall not be construed as a distribution of this Package.

    >
    > To me that says "You can implement your functionality using Perl, and
    > embed Perl to ensure that that functionality operates, but you can't
    > expose Perl scripting without falling under the restrictions due to
    > the AL."


    I don't think so. Here's how the license defines package:

    "Package" refers to the collection of files distributed by the
    Copyright Holder, and derivatives of that collection of files
    created through textual modification.

    When providing Perl scripting abilities, you are _not_ providing an
    interface to the collections of files the package consists of.

    The Artistic license mostly deals with how you modify the software and
    how that affects distribution. This does not apply when you embed a Perl
    interpreter.

    Tassilo
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
    Tassilo v. Parseval, Nov 24, 2004
    #4
  5. In article <>,
    Patrick Finnegan <> wrote:
    >We just had a discussion in the Office about the use of embedded Perl
    >with commercial applications. Three of the server applications used
    >in the corporate environment, WebSphere, Control SA and Cisco
    >Networks, use Tcl or a Tcl derivative as the embedded scripting
    >interface. Is there a licensing limitation on the use of embedded
    >PERL with commercial applications?


    I'll answer a different question, leaving yours about licensing
    to others: Perl is *technically* more difficult to embed, and
    even more so in the past. Also, Tcl's event constructs and
    reduced syntax are handy for the supervisory applications Oracle,
    IBM, et al., require.

    I like your LDAP contributions, by the way.
    Cameron Laird, Nov 24, 2004
    #5
  6. Tassilo v. Parseval wrote:
    > I don't think so.

    [...]

    Maybe, but this sort of confusion is what makes people reach for the
    legal advice. Which I think was my original point... ;^)

    Donal.
    Donal K. Fellows, Nov 24, 2004
    #6
  7. Also sprach Donal K. Fellows:

    > Tassilo v. Parseval wrote:
    >> I don't think so.

    > [...]
    >
    > Maybe, but this sort of confusion is what makes people reach for the
    > legal advice. Which I think was my original point... ;^)


    And my original point was to ask the copyright holder when in doubt. No
    legal advice required. What he says is authorative.

    Tassilo
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
    Tassilo v. Parseval, Nov 24, 2004
    #7
  8. Patrick Finnegan

    Patrick Guest

    "Cameron Laird" <> wrote in message
    news:...
    > In article <>,
    > Patrick Finnegan <> wrote:
    >>We just had a discussion in the Office about the use of embedded Perl
    >>with commercial applications. Three of the server applications used
    >>in the corporate environment, WebSphere, Control SA and Cisco
    >>Networks, use Tcl or a Tcl derivative as the embedded scripting
    >>interface. Is there a licensing limitation on the use of embedded
    >>PERL with commercial applications?

    >
    > I'll answer a different question, leaving yours about licensing
    > to others: Perl is *technically* more difficult to embed, and
    > even more so in the past. Also, Tcl's event constructs and
    > reduced syntax are handy for the supervisory applications Oracle,
    > IBM, et al., require.
    >
    > I like your LDAP contributions, by the way.


    Thanks for the complement.

    The scripts are not particularly sophisticated but fully worked simple
    examples are useful for beginners like most of the admins on our site who
    work primarily in a Windows environment and have zeroish scripting
    experience.

    I checked out the Perl licensing issue with a contact at IBM. Perl is owned
    by Larry Wall who deals with applications by Vendors to use embedded Perl in
    commercial applications on a case by case basis. There is no guarantee that
    future Perl distros will be "free" and there may be limits on the ability of
    Vendors to write proprietary custom extensions for Perl and package those
    extensions as part of a commercial application. These types of restrictions
    don't seem to apply to other scripting languages such as Tcl and Python.

    The IBM rep also acknowledged that since Java is owned by Sun there is no
    guarantee that Java will never be a proprietary language.
    Patrick, Nov 25, 2004
    #8
  9. > I checked out the Perl licensing issue with a contact at IBM. Perl is owned
    > by Larry Wall who deals with applications by Vendors to use embedded Perl in
    > commercial applications on a case by case basis. There is no guarantee that
    > future Perl distros will be "free" and there may be limits on the ability of
    > Vendors to write proprietary custom extensions for Perl and package those
    > extensions as part of a commercial application. These types of restrictions
    > don't seem to apply to other scripting languages such as Tcl and Python.
    >
    > The IBM rep also acknowledged that since Java is owned by Sun there is no
    > guarantee that Java will never be a proprietary language.


    On second thoughts I think Python is maintained by Guido van Rossum.
    Patrick Finnegan, Nov 25, 2004
    #9
  10. On 2004-11-25, Patrick Finnegan <> wrote:
    >> I checked out the Perl licensing issue with a contact at IBM. Perl is owned
    >> by Larry Wall who deals with applications by Vendors to use embedded Perl in
    >> commercial applications on a case by case basis. There is no guarantee that
    >> future Perl distros will be "free" and there may be limits on the ability of
    >> Vendors to write proprietary custom extensions for Perl and package those
    >> extensions as part of a commercial application.


    Is it me, or does this sound like fairly complete nonsense?

    Just checking...

    dha

    --
    David H. Adler - <> - http://www.panix.com/~dha/
    Apparently the left hand doesn't know what a right hand IS.
    - zenham in #perl
    David H. Adler, Nov 25, 2004
    #10
  11. David H. Adler <> wrote:
    > On 2004-11-25, Patrick Finnegan <> wrote:
    >>> I checked out the Perl licensing issue with a contact at IBM. Perl is owned
    >>> by Larry Wall who deals with applications by Vendors to use embedded Perl in
    >>> commercial applications on a case by case basis. There is no guarantee that
    >>> future Perl distros will be "free" and there may be limits on the ability of
    >>> Vendors to write proprietary custom extensions for Perl and package those
    >>> extensions as part of a commercial application.

    >
    > Is it me, or does this sound like fairly complete nonsense?
    >
    > Just checking...



    I just figured that Patrick had been fed a steady diet of FUD
    by someone who has some alternative to sell to him.


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Nov 25, 2004
    #11
  12. In article <>,
    Patrick Finnegan <> wrote:
    Cameron Laird, Nov 25, 2004
    #12
  13. Patrick Finnegan

    Spam Guest

    Why could not someone embed a lex/yacc based perl interpreter or compiler
    in an application?

    Perl syntax is not rocket science.
    Spam, Nov 26, 2004
    #13
  14. [ Followups set ]


    Spam <> wrote:

    > Why could not someone embed a lex/yacc based perl interpreter or compiler
    > in an application?



    Because parsing Perl is not truly LALR(1).


    > Perl syntax is not rocket science.



    *Parsing* Perl syntax _is_ rocket science.

    Are you familiar with perl's internals?

    Try this in a perl source directory and peek at the code around the hits:

    grep -i intuit *.h *.c

    The lexer and parser do a whole lot of guessing to disambiguate things.


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Nov 26, 2004
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    24
    Views:
    1,543
  2. Carl J. Van Arsdall

    Is anyone using Python for embedded applications?

    Carl J. Van Arsdall, Dec 12, 2006, in forum: Python
    Replies:
    2
    Views:
    276
    Paul Rubin
    Dec 13, 2006
  3. Hendrik van Rooyen
    Replies:
    2
    Views:
    284
    Hendrik van Rooyen
    Dec 13, 2006
  4. tbb!/fbr!

    First Commercial Perl Program

    tbb!/fbr!, Mar 10, 2012, in forum: C Programming
    Replies:
    1
    Views:
    350
    tbb!/fbr!
    Mar 10, 2012
  5. PerlFAQ Server
    Replies:
    0
    Views:
    166
    PerlFAQ Server
    Apr 23, 2011
Loading...

Share This Page