Thanks for these comments Richard, I'm familiar with the general arguments made in favor of different licensing schemes, and to be honest, I get lost in the rhetoric. :) You can surely find URLs that explain why you should or shouldn't do almost anything, take for example the following on why you shouldn't use the LGPL:
http://www.gnu.org/licenses/why-not-lgpl.html That's not to dismiss the value of such discussion, it's certainly educational and interesting, but .... there are lots of places to carry out such general discussions and they go round and round and that's not so much what I'm looking for here. I would like to get into specific use cases and then generalize from those to draw conclusions about what license might be "appropriate" for NSP ... rather than starting with generalities that may or may not apply to this specific case. NSP is not Linux, it's not Perl...it's NSP...and I'd like to have a discussion that is focused on it and the kind of application that it is rather than making comparisons to Perl, Mozilla, etc. So, I described a scenario by which you could actually use NSP and preserve whatever license you like to use for your software. Your response to that is that you don't like that, but it's not clear why. So, a few questions. Note to anyone else with alternative license ideas, I'll ask you these questions as well. :) 1) Why doesn't that work for you? What exactly would you like to do? For example, do you want (time permitting, etc.) to modify parts of NSP and include in your system? Or do you simply want to use it "as is"? 2) Do you distribute or make available your source code? 3) What license do you use for your software (and in what form do you distribute it if not source code)? 4) How much does your software cost? (you can be vague, but it seems important to know if we are talking about $15 for freeware versus charging $5,000/year under some licensing arrangement) Our answers are as follows: 1) fairly happy with what we do now, but want to do things in such a way that doesn't significantly impede the use of NSP 2) yes 3) GPL 4) $0 (USD) :) Thanks, Ted On 5/17/07, Richard Jelinek <[EMAIL PROTECTED]> wrote: > > Greetings Ted, > > On Wed, May 16, 2007 at 10:50:59AM -0500, Ted Pedersen wrote: > [...] > > Now, some folks balk at the third condition above, and there can be > > good reason for that, especially if one is working at a company or > > organization that doesn't release source code or doesn't use the GPL > > in general. > [...] > > But, if you simply want to use NSP within a program or > > package that does not actually modify NSP, you can do > > that by keeping an appropriate distance from NSP. > [...] > > Now, given all this, how can "NSP" be kept at an appropriate distance, > > so that the program that uses it does not need to itself follow the > > GPL? There seem to me to be two ways of doing that... > > etc. etc. > > And all this fuzz would not be necessary if the NSP was licensed under > a license that'd be apropriate. > > I should find my email to you some years ago, where I suggest the LGPL > which has been made especially for *libraries* to avoid all this > hacking and bending. > > I should also point you to this > (http://lwn.net/2001/features/LarryWall/) 6-year old Interview with > Larry Wall where he explains (among some other interesting > information) the reasons for the dual Licensing of Perl and the > reasons for the Artistic License. > > > Also, we are especially interested in the opinions of people who have > > felt constrained by the GPL in some way, and might have changed their > > plans for using NSP because of the GPL. If that's the case, we'd > > really like to hear from you. > > So hear hear. > > I personally do not feel constrained by the GPL of NSP. Because as is, > that this makes it a no go for e.g. PetaMem and maybe other > companies. I am very unhappy if basically equivalent work is done > twice because of my allergy against wasting ressources. This is the > case of NSP and PMSE: > > PMSE is the PetaMem Scripting Environment. It is a framework used for > IR of large text corpora. A subset of its functionality intersects > with the NSP functionality. > > There are some nice things in NSP we would like to have in PMSE, but > hadn't the time to implement them yet. OTOH there is much work that'd > have to be done in NSP before an integration could occur: NSP is at > the moment quite naive in its multilingual support and the quality of > the perl code is not always sufficient. But still I believe there is > potential for synergy. After all I must have been lurking on this list > for years. ;-) > > -- > Kind regards, > > Dipl.-Inf. Richard Jelinek > > - The PetaMem Group - Prague/Nuremberg - www.petamem.com - > -= 18924571 Mind Units =- -- Ted Pedersen http://www.d.umn.edu/~tpederse
