You may find the following helpful:

• This thread
• The relevant FAQ.
• Answers to additional questions.
• Part of the CPAN FAQ
• Recent discussion on the Perl5 Porters Mailing List

You should also make certain your utility does something really useful, e.g. that it's actually worth paying for. The Perl community has high standards for their free software and higher ones for that which they pay for. You might consider giving the software away and charging for the support, customization, and/or training instead.

--f

P.S. You may have certain restrictions to worry about with Delphi. Read your LICENSE.TXT file very carefully before deploying or selling an application. This is especially true of various editions (and compilers, for that matter). For example, your redistribution rights are rather limited with Academic Editions. Even Professional Editions can be a bit restrictive. When in doubt, consider contacting the vendor directly.

In particular at the GPL FAQ I suggest the item for when the interpreter is GPLed. In there they address directly what should be a separate question, namely the case of libraries in an interpreted language. And their answer is that if you wish to use LWP, your program must be GPLed.

Note, however, that the advice given by the FSF is given by people interested in the most restrictive interpretation possible. OTOH that is advice determined by legal counsel, and were the GPL to go to court then that legal counsel's interpretation of their own license would have substantial weight in determining the interpretation of the license. IANAL, and I am not giving legal advice, but I personally would think twice before thinking that the FSF's interpretation would not therefore hold up in court.

I also note that the GPL has never been tested in court. This is both good and bad. It is bad because there are no rulings to clarify the possible legal readings. It is good because it means that every time the FSF has challenged a corporation on the GPL, the corporation had their legal eagles read the license, and the lawyers told the company to blink.

(For more on the enforcement techniques the FSF uses to get compliance, you can read Eben Moglen's description.)

This helps, but a followup...

You said "And their answer is that if you wish to use LWP, your program must be GPLed" In this example LWP is "same license as Perl".

If someone only uses Perl ArtLic modules, can they sell the software?

I know MSVC++ or Delphi would be OK, but I would like to use Perl (I have 6 Perl books). Do you know about Python? --Their FAQ says you can do just about anything with it...

I am NOT trying to steal anyone's IP, but want to learn a new language and get the experience of selling a product to a bunch of "beginner" users. (The Perl community would find it too simplistic) (prev person asked about this...)

thanks!

On the other hand, if it runs in a Windows environment M$ might help with your defense seeing as how they want to kill the whole open source movement.

Just wondering, you said

Even Professional Editions can be a bit restrictive.

What restrictions beyond the obvious were you talking about? The only limits that I know of are the obvious ones, you can only include with your products those items refered to as 'redistributables'. Beyond that, the .exe you create is yours to do with as you will. Note that I'm speaking from the perspective of the Professional Edition.

hsm

Well, my experience is mostly based on off-topic compilers, e.g. Borland's Delphi and Microsoft's products, but there is a tendency to give you interesting things to play with, but limit the redistribution of the run-time libraries that support those. These also tend to limit redistribution of any utilities provided with the product.¹

With Delphi's Professional Edition, for example, you are provided with redistributables for the Borland Database Engine (BDE),² but are not allowed to redistribute the SQL Link libraries that connect to most remote databases (save InterBase, for obvious reasons), even if you have the relevant SQL Links from other products. Both Paradox and dBASE (no longer Borland products) provided SQL Links for several remote databases. Thus, some developers thought they'd redistribute the SQL Link provided with the database product along with the programs they developed with the compiler. Such people were in violation of their licensing agreements.

Similarly, if you're using their MIDAS technology (in the form of TClientDataSet components) to enable data exchange between multiple computers (e.g. to a remote server), then you have additional restrictions:

Purchase of Delphi Enterprise edition, however, does not include deployment rights for this software. Customers who wish to deploy applications that use MIDAS must purchase a separate license for each server on which MIDAS is installed.
-- Delphi 5 DEPLOY.TXT, emphasis added.

While I've not heard of any legal actions taken against small violations, I'm told that these multi-server restrictions are taken very seriously. Also, with Microsoft's recent focus on corporate growth through aggressive license enforcement, I'd be very careful in this regard.

Other limitations prevent you from creating competing products. For example, the license for Paradox for Windows Runtime specifically forbade you from providing tools to features that'd been disabled in the Runtime version, e.g. interactive design tools and so forth. Similarly, Corel has provided Merant's Paradox ODBC driver with the last few versions of Paradox for Windows, however, if you read the enclosed information carefully, you'll note that said driver is only licensed for end-use and not for developer distribution. You must obtain a separate license for that and it's not cheap.

Similar restrictions can be found in Delphi's EULA³ as well. For example, you're not allowed to create a Delphi clone with Delphi.⁴ I've seen similar terminology in Microsoft's EULA's. For example, tilly recently pointed out some rather surprising terms in a Microsoft EULA that may affect our local community.

Even ActiveX controls aren't safe, for while they come with end-user license keys, they do not traditionally come with redistribution rights. Here's what Delphi's License Agreement has to say on the matter:

The Software might include source code, redistributable files, and/or other files provided by a third party vendor (Third Party Software). Since use of Third Party Software might be subject to license restrictions imposed by the third party vendor, you should refer to the on-line documentation (if any) provided with Third Party Software for any license restrictions imposed by the third party vendor. In any event, any license restrictions imposed by a third party vendor are in addition to, not in lieu of, the terms and conditions of the License Agreement.
--Delphi 5 LICENSE.TXT.

The bottom line is that you need to carefully review the licensing terms of all elements in your application, regardless of platform⁵ or source. If you use someone else's code and sell your solution, then you need to make sure you have permission to redistribute their work to others. In the Perl community, the GPL tends to gives us some freedom in that respect, however, different worlds handle this differently. And you need to be proactive in your quest for financial freedom. When in doubt, contact the publisher/author before you ship your product.

This is one reason why 99% of the code I release on an unsuspecting public is licensed with the following: Share and Enjoy. Yes, I have some code that isn't released freely, but I tend to keep that to myself.

Trivia: The biggest difference between Delphi's Professional and Enterprise Editions lies not in the additional components and tools, but in the allowed redistributions.

BTW, I'm not picking on Borland or Corel in this. I'm just more familiar with their EULA's than I am with Microsoft's. In my experience, both companies provide less restrictive license agreements than others do. You have to be especially careful with third-party components/add-in's. For example, one vendor of my acquaintance charges a royalty for each redistribution.

Face it: commercial software sucks and it's not a cheap business to be in. Many vendors find ways to "increase their revenue stream" and many of those are buried in those license agreements you tend to click through without reading. This is why we (those wanting to be professional programmers) must be especially vigilant regarding things like UCITA and other legislative actions currently in progress.

Again, this is something that the casual Perl developer doesn't have to worry too much about. We have a tradition of information and code sharing. If you like using other people's code, then I encourage you to share freely. Personally, I do not believe that technical information should be restricted, hidden, or otherwise unavailable for some ephemeral competitive edge. And, yes, I'm also against software patents for certain algorithms, especially those that could be created by anyone with minimal amount of skill. (Did somebody say Amazon's One-Click patent?)

Finally, I need to remind you all that I'm not a lawyer.⁶ If you're worried about it (and you should at least check into it), then I highly suggest you contact a qualified and competent attorney.

--f

¹ - Case in point: Delphi 5 comes with a grep utility. However, you are specifically constrained from redistributing it. (See DEPLOY.TXT for details.)

² - Strictly speaking, you're not allowed to redistribute the BDE without a corresponding application. This means creating a separate installation designed to solely update a client's BDE is a violation of license...unless you include a program with that. I've gotten around this by creating a small utility for checking your version and configuring the client PC (including support for command-line configuration for use during installation).

³ - I confess that I've not fully reviewed the latest agreements provided with Delphi 6 or Kylix; I suspect, though, little has changed.

⁴ - Which is slightly amusing (from a morbid sense of humor) given that one of the traditional selling points for Delphi (and Kylix) is that "It's written in itself."

⁵ - I wouldn't be at all surprised to learn of restrictions regarding certain elements of Windows itself, such as COMCTL32.DLL, WININET.DLL, .NET, and so on. As I've said before, Microsoft loves to find ways to make you pay.

⁶ - I was, in a prior life, a product manager for one of the products mentioned above, so I do have some inside information, however, that information is woefully out of date.