Note that earning some cash and making your software proprietary and/or
hiding the source do NOT necesarily go hand in hand. In fact hiding the
source can very well hinder sales if you're a small shop because customers
like to know that if you disappear that can find someone else to do
maintainance on the software. For the last ten years my bills and
those of my employees have been paid by a software package we did in Perl.
Redhat Inc. has of course made millions form Anaaconda and other open
source software they've written.

For our main product, the source is available to all users so they can
inspect it, understand the system, and do customization or maintainance
if required. In fact, very few of them do any customization - they come
to us for that because we understand the system best and have done similar
customizations before. They like knowing that tey have FULL use of the
software they bought - not some encrpyted thing that will become useless
if an update is needed to work with one some new system or something.
We haven't had any problem with people copying our software and us losing
business from that. It just hasn't been a problem and probably wouldn't
be for you either.

While our source is available to all customers, our main product is not
actually free software because we don't give redistribution rights.
Customers can modify the software but can't LEGALLY resell it.
(Not that people on the internet pay much attention to copyright law.)
However, customers like the fact that our license says it will
be licensed under the GPL if we ever cease to support it for any reason.
Other software we sell is GPL. People COULD get similar software
elsewhere without paying for it, but they come to us with cash in
hand because they want our help selecting and installing the best
software for the job, they want our modifications, and they want us
to be available for questions after the sale.

If license issues are causing you in trouble and you're writing
Linux, FreeBSD, etc. software you might try selling it under the GPL
and see how that goes. The doesn't mean you can't sell it and make
good money.



My assumption isn't that shell scripts ARE simple, but that they SHOULD be. :)

I'm saying that if what you have in mind right now is "pretty long and
relatively complex", then it's going to be more complex by the time it's
ready for release, even more complex a year later after new additions
and features are added, and so SHOULD be written in a programming
language like Perl, Python, etc. rather than in a user interface
language like bash. C might be appropriate, but if the shell was
your first instinct than Perl is probably an appropriate "one step up".

You know what I always use to think about the same point. Will releasing the source will hurt sales or not.

Under what license did you guys released your software in? Or did you come up with your own customized license for the software?

Hmm... I might try that. But then why didn't you guys released it under GPL in the first place (this is not to tease/question anybody but I am just trying to understand.)


Ok this might be deemed for a separate thread, but can I do all those things in Perl or C which I can do in Shell script? Basically the main contents of my shell script will primarily consist of sys-admin commands and lot of dialog boxes and some perl commands.


Once again thank you for your detailed explanation. Really Really appreciate it.

Some of our stuff is GPL. Our non-free software is a customized license.
We might go GPL for everything soon. Ten years ago, when we first released
our one big money maker software, we knew it was going to earn hundreds of
thousands of dollars because it was a unique new solution to a problem
facing many businesses. We also knew that one company in particular
would likely be wanting to copy from it, a company that was much bigger
than us, with much better marketing, so we thought it best to maintain
as much control as possible to avoid having the "competitor" end up
making all of the money from our unique new ideas. As mentioned before,
our license does provide that everything becomes GPL if we dissapear.


Generally the shell is the quickest, easiest, and least powerful option
for simple programs. As programs get more complex, the lack of power
and flexibility of the shell makes it no longer quick and easy.
Anything that the shell can do can absolutely be done in C. This must
be true because all that the shell does is call C programs - the real
work is always done in C. Perl too can do just about anything - in
ten years the only thing I can think of that I've come across that
couldn't be done in Perl is a kernel module, such as a device driver.
Certain things that require really heavy duty bit banging such as
low level graphics work or things that have to be SUPER fast aren't
the best jobs for Perl. C is better if you have to do more than about
a few thousand "things" per second. Even for these jobs, though, you
can use C libraries from Perl, so Perl can do advanced graphics work
and such - you just wouldn't write the library in Perl.

So in short - the shell for simple things that take less than an hour to write,
Perl or another scripting language for more complex stuff, and C for kernel modules
and programs that do something thousands of times per second.

This has so far been one of the best forum discussion experience for me.

As promised I have summarized the entire discussion (to a great extent) on this blog. In fact I am not anywhere near a blogger as you can guess that this is my only 2nd blog. My first blog was just a trail blog.

Here is the link for the blog:
http://evolvingminds.wordpress.com/2...sues-gpl-lgpl/

Make sure you leave a constructive comment or any suggestion if you have one.