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!

Sorry, I should have checked the licensing.

Yes, if you include something licensed under Perl's Artistic License in your code, but don't try to provide any external interface to it, then you are in the clear. This is true even if it is dual licensed with the GPL.

There are, as well, other ways to satisfy the Artistic License while still providing a public interface to some of the wrapped facilities. You can read the license terms for full details.

You can sell a GPL product. You just have to make the source available for cost or less (ie price of P&P and handling, etc).

Thats hardly too demanding and if you are selling to beginners won't hit your sales too badly while at the same time you get the benefits of more experienced users downloading it and using it themselves and possibly giving feedback.

Bare in mind there is plenty of second-rate delphi, visual basic and even perl commerical software available. Are you sure you want to add to that?

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.

Even Professional Editions can be a bit restrictive.

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.