Using embedded PERL with commercial applications?

[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?

 

[Tassilo v. Parseval]

[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

 

[Donal K. Fellows]

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.

 

[Tassilo v. Parseval]

Also sprach Donal K. Fellows:

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

 

[Cameron Laird]

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.

 

[Donal K. Fellows]

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.

 

[Tassilo v. Parseval]

Also sprach Donal K. Fellows:

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

 

[Patrick]

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 Finnegan]

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.

 

[David H. Adler]

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

Just checking...

dha

 

[Tad McClellan]

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.

 

[Cameron Laird]

Patrick Finnegan <[email protected]> wrote:

 

[Guest]

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

Perl syntax is not rocket science.

 

[Tad McClellan]

[ Followups set ]

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.