Hello!
I am wondering about developing commercial software with newLISP. I would basically wish for:
1) closed source (no need to disclose the source)
2) encrypted source code (since newLISP is interpreted)
3) one simple package (executable with GUI, easy to make)
Any suggestions and ways, how to do it, are very welcome!
Fanda
Last month i tried using 'link' to create an executable of a script that would run on a system without a newlisp installation. It didn't contain any of the original script, at least that I could see.
Of course, my problem was trying to create a Mac-PPC binary on a Mac-Intel machine. But the principle might apply...
The way newLISP is licensed, it does not permit linking or packaging closed source with newLISP together.
You would have to distribute your closed source in a separate package. Users would have to install a newLISP distribution and then your closed source package.
Lutz
Presumably an installer could do both jobs seamlessly, such that the user doesn't really have to notice...? When I install MacOS systems, there's a license agreement for GPL stuff included, and I'm not really aware of that...
Quote
The situation is very different when distributing a closed source application which wouldn't function without the GPLd component, from distributing an OS as a collection many different components.
Mac OS X is based on open source Darwin, only the Carbon/Cocoa components are closed source. In case of vital components like the GCC compiler and Safari, which is based on the KDE open source Konqeror browser, Apple has made special arrangements with the copyright holders of those components.
Anybody thinking of distributing a closed source newLISP software application. Should carefully study all the info and FAQs available at http://gnu.org which give practical answers to most questions about applicaton of the GPL when mixing with closed source software.
Lutz
Lutz, are you saying then, that it is against the license to distribute a closed source commercial app with newlisp?
Jeremy
You cannot distribute newLISP and your closed source application
See also here: http://www.gnu.org/licenses/gpl-faq.html
Lutz
Quote from: "Lutz"
See also here: http://www.gnu.org/licenses/gpl-faq.html
Lutz
As far as I can understand non-tech English, GPL explicitly disallows not only together distribution, but even distribution a closed source application
Lutz, is this what you are intended?
A general purpose programming language is not the same as a plugin which typically has a specialized, vertical purpose and functionality.
It is more like an OS extension. E.g. Linux is GPLed but you can run proprietary closed source programs on it, just not distribute them together. This is the reason that Debian based Linux, like UBUNTU, do not ship closed source software together with their distributions.
For newLISP as a scripting language, I pretty much follow Larry Wall's comments regarding the usage of the GPL for the Perl scripting language:
"For those of you that choose to use the GNU General Public License, my interpretation of the GNU General Public License is that no Perl script falls under the terms of the GPL unless you explicitly put said script under the terms of the GPL yourself." see: http://dev.perl.org/licenses/
Lutz
I also needed some time to understand this in the past.
Anyway I always had the wish to get newLISP.dll under LGPL, to be able to distribute it with a commercial package.
(Avoiding a potential DLL-hell, because of potential incompatibilitys between versions.)
(So now you have to carefully do version/binary checking before using the installed DLL)
So wishes remains in live. ;-)
(Like cracking the current 43 Mio € jackpot of the german lottery)
Quote from: "Lutz"
This question is discussed in GPL FAQ too. The application written in newLISP is not doomed to be GPLed. But the application written in C and using newLISP as a scripting language (consider a word processor or speadsheet using newLISP instead of Application BASIC) is. And this is sad.
Quote from: "Lutz"
This is wrong. You can distribute proprietary programs with Linux, and many vendors do. It is called
Worse than, if two software components makes a single program together, and one of them is free, you are forbid not only to ship them together, but also to ship a closed component alone, if it is designed to work with free component (here and above "free" means "GPLed").
Anybody planning distribution of closed source software forming a program together with the newLISP should assume strict interpretation of the GPL at first, then consult a intellectual property (IP-) lawyer specialized in software, and consult me if modifications are desired.
Lutz
Hi Lutz,
Am I correct in thinking that as you hold copyright for newlisp you could license a non-GPL version (for some consideration if desired) to Fanda for use as he describes if you chose to?
as in
"I would like to release a program I wrote under the GNU GPL, but I would like to use the same code in non-free programs.
To release a non-free program is always ethically tainted, but legally there is no obstacle to your doing this. If you are the copyright holder for the code, you can release it under various different non-exclusive licenses at various times" at http://www.gnu.org/licenses/gpl-faq.html#ReleaseUnderGPLAndNF
Regards
Nigel
Interesting question!
A LGPL-licence for the DLL or a personel non-GPL version license would get definatly my interest.
;-)
Yes, multiple licenses are possible in principle. Some open source projects follow this strategy. In the case of newLISP, additional conditions are always defined on a case by case basis.
Lutz
sorry to bump!
Has somebody released a LGPL newLisp application?
I mean, got to an agreement with Lutz... right now I think I could use newLisp for a little game, the newlisp footprint and speed the reason, but I'm not sure because my other option is lua with a more freely license that permits embedding (with lees semantic *power* of course but similar footprint and speed), I don't want to spend time implementing something in newLisp if at the end the result is that my game is GPLed.
I must understand the GPL license of newlisp as a possible way to commercial licenses with the author, and that is Ok, but maybe a LGPL license for small or personal projects (even close sourced) would be handy.
Any comments about this?
You could write a bash script to wget a copy of newlisp off the server and compile it as a shared library as part of the install process of your application, although you would need to notify and get the user's permission to do so. This is how the proprietary nvidia linux kernel driver works (or, at least, used to work.)
You can then write your program using the shared library to access the interpreter.
You might also look at lua. I believe lua is more permissive as an embedded scripting engine, and it is no less powerful than newlisp.
Has any more thought went into this? I have enjoyed toying with newLisp, but cannot consider it a language for me to use because of the licensing restrictions. If I spend time developing something, I would want the freedom to do with it as I wish, without all kinds of hoops to jump through.
Jeremy
I guess no change in the licensing, any commercial software is still prohibited by the licensing of NewLISP?
Jeremy
Where does it say that commercial software is prohibited ??
Quote from: "newdep"
I think he means closed-source more than he means "commercial" software.
Sorry. Yes, closed source is what I mean.
I've been thinking about this recently. Since newLISP is under the GPL, I assume Lutz only expects businesses to use it server-side, or as an internal general purpose scripting language. There's very little chance we would ever see newLISP as part of a commercial client application.
I'm not a devoted fan of any particular software license. Each one has its own pulses and minuses. In this case it seems newLISP could become more prolific if the license was more permissive. I would hope that would, in-turn, mean more people giving feedback.
I think newLISP could be a pretty good competitor for a small but fast embedded scripting language. Lua is arguably the most widely used for that task, and I would be curious to see how newLISP performance compares (a good topic for someone's blog post?).
I doubt Lutz would ever market newLISP as an embedded scripting language, which is fine. But the current license pretty much completely removes that as a possibility, along with many others.
It just seems like newLISP could really benefit from a more permissive license.
Im just wondering why there is such a fuzz about the license all the time..
If someone could please tell me.. Then I know whats going on because somehow i dont see the issue..
Is it because people can't compile the newlisp scripts? (its readable)
Or is it because of the newlisp binary itself?
Or is it that people dont understand how to "provide" the code to the requester?
(because you dont have to put your code on every milk bottle outthere you know ;-)
Or is this the issue?
You would have to distribute your closed source in a separate package. Users would have to install a newLISP distribution and then your closed source package.
Quote
Or is this the issue?
Yes, especially user of the DLL-flavour would benefit of a LGPL-license for the DLL.
Now you have to make a seperate install and load the DLL from there.
In response to some of the comments in the very hijacked
With newLISP under the GPL, it is very unlikely businesses would use newLISP in client software (because it would require releasing their source code). Two specific uses-cases I have in mind are:
(1) Distributing client programs that use newLISP as an embedded scripting language
The only way to use GPL software with a closed-source program is to execute it completely separately. Apple's use of gcc with their Xcode IDE is a good example of this. Interfacing with newLISP via IPC pipes might work, but would just be a kludge because a business doesn't want to release source code.
(2) Distributing client programs written entirely in newLISP
Quote from: "Lutz"
You would have to distribute your closed source in a separate package. Users would have to install a newLISP distribution and then your closed source package.
That workaround might work, but is again just a kludge.
It is very possible for businesses to use newLISP for other purposes (because it doesn't require releasing source code). Here are two examples of that:
(3) Using newLISP for internal processes and programs
I'm sure many in these forums have and do use newLISP at work for batch processes, log parsing, automation, quick throw-away scripts, etc. newLISP is helping people be more efficient, which saves the business money.
(4) Server side code for web applications
There is a tremendous amount of GPL licensed software being used in web-sites today. Youtube's use of ffmpeg for video processing is one example. Businesses are making tons (tonnes?) of money off it all.
In cases 3 and 4, businesses can even change/improve the code, and never have to contribute those changes back to the community.
Lutz has put an enormous amount of time and effort into newLISP. I am incredibly grateful for that. He holds the copyright for almost all of the code, so of course he gets to decide whatever license he wants to use. I say 'almost all' because I'm lucky to have my name on a bit of code I contributed. That code is available under the very permissive zlib license.
I don't see anything inherently good or bad about license choices. You use the one that meets your intent. I've released a non-trivial program with almost 30k lines of code under GPL myself. I did it because I never want anyone to utilize its code without contributing back to the community. If businesses don't use my program because of the license, I'm ok with that.
It's all up to Lutz of course. If he says "newLISP is under GPL, it's for my own reasons, this won't change," I'd be ok with that. I just see added opportunity if a different license allowed for use-cases 1 and 2. The LGPL seems like an excellent choice, because no source code has to be released
The GPL license prevents the use of newLISP as an embedded script- or glue-language inside projects that can't or don't want to license their code under GPL (commercial projects).
Even exploring if it is usable as an embedded language does not make sense for commercial projects - or even projects that publish their code under the BSD or MIT license.
I am not saying that this a problem for the development of newLISP - just that it limits its use case.
Cheers,
Bjoern
I'd just like to cast my vote for the LGPL (or if possible, an even more liberal license).
The real question is, is Lutz willing to grant exceptions to the license (for a fee)? Richard Stallman told me that was possible. If you want to sell a closed application, the author of the code has the right to license his code to you under any terms he wants. So the GPL applies in general, but it doesn't prevent dual licensing. So the key is, what is Lutz willing to do. If you have an application that took you a lot of effort to write, and a small number of users, it might make sense to keep that degree of control. But if you are selling the software, it makes sense to pay the other contributors to your software, in this case, Lutz. I assume Lutz would judge this on a case by case basis. Lutz is for keen on freedom for everyone, so you'd need to make a good case and specify reasonable terms in the alternate license.
For a language to become popular, it needs as few impediments as possible. The GPL is one such impediment.
My interest in this topic is purely academic - but I'm curious - what do the other scripting languages do for licensing - Perl, Python, Ruby, Lua, etc? If different from newLISP, what does newLISP's licence deliver that the others miss out on?
Quote from: "cormullion"
All except for Perl appear to be liberal licenses that don't require publishing your source:
http://www.lua.org/license.html
http://www.python.org/psf/license/
http://www.ruby-lang.org/en/LICENSE.txt
http://dev.perl.org/licenses/
Lutz has said that he specifically "interprets" the GPL as Larry Wall does:
Quote
Furthermore, any object code linked with perl does not automatically fall under the terms of the GPL, provided such object code only adds definitions of subroutines and variables, and does not otherwise impair the resulting interpreter from executing any standard Perl script. I consider linking in C subroutines in this manner to be the moral equivalent of defining subroutines in the Perl language itself. You may sell such an object file as proprietary provided that you provide or offer to provide the Perl source, as specified by the GNU General Public License. (This is merely an alternate way of specifying input to the program.) You may also sell a binary produced by the dumping of a running Perl script that belongs to you, provided that you provide or offer to provide the Perl source as specified by the GPL. (The fact that a Perl interpreter and your code are in the same binary file is, in this case, a form of mere aggregation.)
This is my interpretation of the GPL. If you still have concerns or difficulties understanding my intent, feel free to contact me. Of course, the Artistic License spells all this out for your protection, so you may prefer to use that.
I'm not sure I understand what he's referring to by "Perl source" there. Is he referring to the source of the Perl interpreter or to the Perl scripts you wrote? If it's referring to the source of the interpreter, then it seems like you should be able to commercially use and embed the newLISP interpreter with your code and
It'd be great if someone could clear this point up. Am I interpreting it correctly?
I would assume, because Larry Wall spoke of "mere aggregation", that he means the source of Perl, not your own source.
If this is Lutz position as well, then that opens up a lot of doors; to wit, distribute your binary application but include the GPL license for newLISP with the offer to provide the source for newLISP (but not necessarily your applications source)
Is this right Lutz?
I would say no.
What I was told from Lutz, I can not deliver/install newLISP (the DLL) with a commercial application installer.
I had to provide the seperate newLISP installer and had to search/find the newLISP.dll via the enviroment-variable on the system.
So I have 2 installer and have to explain that the seperate newLISP-install is needed for the commercial application to run.
A real embedding with a LGPL-licensed DLL would allow each appliction to install and use its own version.
No danger that a later installed generic newLISP would break an older code.
I have long considered this argument, as the creator of commercial software, which used newLISP. In the previous case, we had a search engine and it did not require us to share the source code or distribute anything to a client, it was all server-side.
This worked, but we were considering the idea of distributing a version for internal use at client sites. As a long-time hater of the GPL (it is more restrictive than you think), I almost moved from newLISP to another language. In the end, I chose to stay with newLISP because the company didn't require client distribution.
Now, I am in another position, equally frustrating.
I am developing a two-version network security platform. The first is open source and can be downloaded, modified, whatever. It's free and open.
The second version (and how I make money off the product), is a custom hardware-based network security product which *includes* the open source version, with some special tweaks for the hardware. I am running OpenBSD on the hardware (free, non-restrictive license) and it boots into newLISP directly, then starts to load my software.
I believe (and my lawyer believes) I am not violating the GPL because:
1. The customer is buying the hardware, with the software pre-installed.
2. It comes with newLISP (GPL) pre-compiled, but all license information remains intact and the sources are unmodified.
3. My own source code is being interpreted by a non-modified version of newLISP and is not compiled, as a binary, with newLISP (i.e. sources are separated).
4. The product is a solution, like a Laptop with Linux pre-installed, and I am not charging for the GPL software.
I am hoping Lutz agrees this is not a violation of his license or of the GPL. I'd prefer if newLISP had a less restrictive license, but that likely will never happen.
Hope this helps those out there who -- like me -- are pulling their hair out about how to continue to develop in newLISP, support newLISP and make money off their efforts. :)
Hmm. When a licence starts to restrict the honest efforts of users to use and promote a software package, you have to ask (again) what are the outweighing benefits to the author that makes it worth the risk. Is newLISP sometimes in danger of licensing itself out of consideration - what's the justification for that? (I'm just curious...)
I sent Lutz an email asking for comment and here's his response:
Quote from: "Lutz"
read up on related questions.
Regarding linking the newLISP script and newLISP executable or
shipping it together, it is pretty much like HPW stated it in the
thread: you have to ship and install your closed source script and
newLISP separately, because newLISP is not LGPL.
I am not participating in GPL related threads, because they tend to be
endless. Most questions can be cleared up reading the GPL FAQs.
Cheers
Lutz
From: http://www.gnu.org/licenses/gpl-faq.html#GPLAndNonfreeOnSameMachine
Quote
Yes.