Ok, thank you. Now I understand better. So a GPL program can be used in another commercial program which is sold for money without offering it's source code, but the GPL part should be licenced as GPL so it could be distributed freely.
Did I understand correctly? Octavian ----- Original Message ----- From: "William T. Holmes" <[EMAIL PROTECTED]> To: "Octavian Rasnita" <[EMAIL PROTECTED]>; "Ingo Schwarze" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Tuesday, July 15, 2008 2:28 PM Subject: RE: perl licence Hello, You can most certainly charge for your product. What you can't charge for is Perl itself. Whether or not you can redistribute someone else's build is another question. This is no different from Java. You can write a Java program and sell it but you can't resell Java. You may have to get permission to distribute Java with your program but you can certainly sell your own program. I have purchased several packages based on Perl and in each case they did not include Perl itself. They both specified Active State Perl as the preferred Perl distribution to use for the Windows environment. Even Linux can be redistributed under the GPL. However the you can charge for you code and you don't even have to make your source code available even under the GPL. Practically every single DSL/Cable Router is based on Linux. Every manufacture is required to provide access to the source code for the portions of Linux they use but none of them have to provide their own code. Bill -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Octavian Rasnita Sent: Tuesday, July 15, 2008 6:59 AM To: Ingo Schwarze Cc: [email protected] Subject: Re: perl licence Well, I don't think it is too complicated to create my own licence, because there are very few things to specify in it, but what I wanted to be sure is to be allowed to create commercial software with perl legally. But it is ok if the artistic licence allows that. GPL doesn't permit it because it doesn't allow distributing the software commercially to the clients without giving them permissions to distribute it to others. If we are talking about licences it means that the program should be distributed, because otherwise why should we care what we can do with it. I guess all the licences allow the owner of the program to use it. Octavian ----- Original Message ----- From: "Ingo Schwarze" <[EMAIL PROTECTED]> To: "Octavian Rasnita" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Tuesday, July 15, 2008 1:42 PM Subject: Re: perl licence > Hi Octavian, > > Octavian Rasnita wrote on Mon, Jul 14, 2008 at 08:25:51PM +0300: >> I don't think it is philosophical, because I need to be sure that >> I respect the licence, > > Yes, you must assure that indeed! > >> and maybe I don't understand it correctly, but as far as I know, >> the GPL licence say that I can use a GPL licenced software in my >> software only if I release my software as GPL. > > No, that's not true; for example, you are also allowed to use GPL > licensed software in your own software if you do NOT distribute > your own software at all. You are by no means required to release > your own GPL-based work to anybody. You need to be very careful in > rushing to conclusions from what you think the spirit of some license. > Typically, courts will pick at nits, too, it's not just me. > > The GPL is quite complicated (which is one of the various reasons > some people like it and others don't, but that's not relevant here). > Commercial licenses are usually very complicated, too. Do not rely > on what random people (like me) on the Internet tell you; Jan Dubois > is not random in the present context, but even he stated that you > should not rely on his words, either. > >> I don't know if the artistic licence is more liberal though... > > Than, please, READ IT, and if you rely on your reading for > commercial purposes, discuss it with a lawyer before acting on it. > >> What I want to do is to create a program in perl language, to offer >> the source code to the client, to allow him to modify and add features >> to the program, but to not allow him to give the original or modified >> source to anyone. > > If you want to distribute Perl source code without fee, i suspect > (and hope) that maybe, at least to some degree, you care about free > and open software. In that case, for making your work as useful as > possible for others (including your clients), consider the following: > > The following is not legal, but political advice. > > 1. Resist the temptation to craft your own license. > There are dozens of well-known and widely used > open-source licenses around. Probably, one of them > will fit your needs. Prefer well-known and widely > used licenses to rare and obscure ones. This will > make life easier both for you and for your clients. > Probably, they already know that license, they know > how to handle it, and are not forced to have their > lawyers evaluate yet another license. > Besides, when they use parts of various software to create > something new and redistribute it, the more licenses get > involved, the more hassle to deal with. > > 2. Consider using the license of the software you are > building upon (or a license granting even more rights). > So, if you write Perl code, carefully check whether you > can use the Artistic license (ISC would also be fine > because it is even slightly more liberal, but shun the GPL > when contributing to Perl). Following this advice, people > face no additional obstacles using your code, and in case > it is really good, maybe it might even get integrated in > the base distribution at some time in the future. > On the other hand, when you add restrictions to the base > license and your code is really good, you can be reasonably > sure that someone will sooner or later reimplement the > concept from scratch and release it under the base license. > At that point, people will trash your work. > > 3. Keep your license as short, concise and easy to understand > even for non-lawyers as possible while still making sure > it is legally enforcible. This applies both when choosing > from existing licenses and when drafting new ones (hopefully > not). Most users will not be lawyers. Nearly all people > changing the code will not be lawyers. If they can > understand the license, that's really an asset. > > 4. If you end up wanting to require something seemingly required > by nobody else, seriously reconsider whether it does indeed > make sense. The number of ways to render software basically > useless by requiring absurd things in the license is unlimited. > Most of these traps look innocuous on first sight. > There are reasons why some requirements are typically left out > of licenses; do not think that your favourite idea is not in any > wide-spread license just because nobody thought of it yet. > People do think of all kinds of weird stuff. Probably, there > is some license out there containing that condition, but the > license is not wide-spread for that very reason. > > Deciding license issues is delicate. Do take the time (and money, > if required) to make sure that what you are doing really makes > sense for you, for your clients and for the Perl community at large. > We don't need yet another ill-conceived, vaguely worded license > containing dubious, hard-to-comply-with, mousetrap restrictions. > > Yours, > Ingo _______________________________________________ ActivePerl mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs _______________________________________________ ActivePerl mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
