GPL License - Source code for shell script?
 

Hi,

I had a question regarding legal aspect of GPL license. I tried skimming through the GPL guide but I am not sure if that answers my question and hence my question on this forum.

I am planning to write a bash shell script which does some functions (using various commands like copy, cd, dialog,etc) on my Debian etch system. Now under the GPL FAQ it says (as far as I understand) that I can sell this script commercially to other users but I am not sure if I need to distribute the source code also along with it?

Ideally, when I write this script, I would like to sell it (even if for a small amount) but at the same time I would like to protect my source code. How can I do this?

Thanks

The script code that you distribute is both the source code and the executable.

---------------------
Steve Stites

you need to provide access to the source code if its under the gpl

Thank you guys for your reply. Is that true under LGPL also?

Can you share with the page where it says that I need to distribute the source code? I have been looking for it but didn't quite actually get it.

Also, are there any other type of FOSS license which will allow me to protect my source code and will still enable me to sell it?

Thank you once again.

If you are writing shell scripts, how do you intend to protect the source code? The script is the program, so when you sell that on to someone, they can easily see the source code. If its GPLed then they are allowed to redistribute it and even release the source code.

Some of your questions maybe answered by reading the GPL FAQ.

What do you mean by "protect" your source code? If you don't want other people to see it, or if you want to prevent them from modifying or redistributing it, then that, by definition, is not open-source.

I beg to differ but it is not the case that you are thinking. One can protect the source code and it can still be called open-source or free software.

Hi thanks for your reply. Actually there are programs like wzshSDK and shc which allows you to create a sort of stripped down binary of your source code. The resulting file is exactly like a binary.

In any case, let's suppose I write a C program and create a binary out of it. So my question is whether there is any FOSS license which allows me to sell those binary but at the same time also give me the right to distribute the source code or not.

In what way? If you're saying you want to give someone a binay but deny then any access to the source, then that, by definition is not open-source. Or do you mean something different by "protect the source"? Perhaps you could clarify just what kind of "protections" you're looking for.

Yes, but that's just what broad Open Source means. There are numerous FOSS licenses (like GPL,FreeBSD,LGPL,MIT,etc) that you can choose to distribute with your program which you have developed using Open Source software.

I am also relatively new to this entire licensing thing so even I am learning.

Just to be explicit: am I correct in thinking that you do not want to let people see the source to your program?

If that's the case, then why do you want an open-source license? It just doesn't make sense. If you're not letting people see the source, then it's just not open-source. The entire point of an open-source license is to give other people the right to modify your code. Why would you want a license that's designed to do the opposite of what you're looking for?

The parts of the GPL that require you to give access to the source code are section 6 of GPL v3 (or section 3 of GPL v1 and v2).

The main difference between the GPL and LGPL is not your source, but third party programs that make use of your source. Any new programs that use your GPLed source must themselves be GPL. Some call this the GPL "virus." LGPL on the other hand says that "derivatives", or modified versions, must be LGPL, but anyone can write a separate program that only makes reference (i.e. calls) the LGPLed source without being forced to use an open source license.

GPL does give you copyright protection so that others cannot distribute modified versions and claim that they are the original thing. They can distribute their modified versions, but must give credit to the original and must state that it is modified. But that doesn't sound like the type of protection you are looking for.

Read the license though, it's really not that hard to read.

salcedo, you are awesome! Your explanation has been close to what I was looking for. Actually I do understand GPL but when I read LGPL I get confuse. I will try to read LGPL again based on your comments in this post.

I'm not sure you understand what open source means. Read the 2nd point of the OSI's definition of open source . If you don't provide the source code, then you software is not open source. Hence the word open.

Such a funny question, I'd like to know how you're NOT going to provide the source code to a shell script.

Well ok let's say based on what you mentioned, that my question really isn't about open source.

So now based on this assumption, is it ok for me not to provide the source code of the binary that I create on my Linux system?

I think now it should be easy for you to answer this.

Ok, forget shell script. What if I write a program in C and create a binary out of it and then I redistribute it. Do I still have to provide the source code?

Got it?

Use a BSD license. How do you think that Apple have managed to keep OSX proprietary when it is essentially FreeBSD?

Apple doesn't use the BSD license but a proprietary license for its own code, and OS/X is much more than FreeBSD.

If you want to distribute a binary without disclosing the source code, you have no choice but to use a non open-source compliant license, i.e. a proprietary one.

An open-source license is an open-source license, YOU MUST RELEASE THE SOURCE !

If you don't want to, then use a proprietary license.

Simple.

My apologies - in trying to be succinct I didn't explain myself properly. What I meant was that because freeBSD is distributed under a BSD license, which is a very open license, this has allowed Apple to make OS X, a freeBSD based OS, proprietary.

I think I understand where you're coming from here.
If you don't provide your source code then of course
your software isn't open source. You can create and
sell proprietary (closed) software as long as you don't
distribute any part of of any GPL software as part of
your software and your software is not derived from
any GPL software.

Now the question is if you use "dialog" and other programs
from within your shell script, does that make your software
a direvative work of "dialog" and therefore require that it
be released under the GPL? Probably not. As long as you
distribute only the shell script and not any of the GPL
software on which it depends you're probably OK. That depends,
though. If you wrote a "browser" which did nothing but launch
Firefox with the Firefox logo changed to your logo and other
"commercializations" added a court might decide that Firefox was
such a pervasive part of your software that yours was a
derivative work. Generally, though, if your software just USES
some standard command like "cd" you're probably OK.

The easy way to be safe? Just skip trying to scramble the code
in the first place. Really, you probably don't have anything that
really needs to be "protected". If you were developing anything
complex you wouldn't be doing it as a shell script in the first
place, probably. If you are developing some complex and unique
software as a shell script that's probably your first mistake -
see Perl, C or some other programing language. If it's something
really simple, not too complex for the sell to be the appropriate
language, than it's probably too simple for you to worry about
someone stealing your secret source.

No, you don't. As a general rule, just because you use free/open-source software to write a program does not mean your program has to be open-source. As long as you don't copy anybody else's code into your program, it belongs to you and you can license it however you like. So if you write your code in GNU Emacs and compile it with GCC, you can still give out just the binary and charge a licensing fee. You'll just have to come up with a proprietary license that captures the restrictions you want to place on the program's use.

Thank you AdaHacker and raymor!

Your comments have really helped me to understand things better. I really appreciate your efforts and other people's effort too for contributing.

raymor you understood my question exactly the way I wanted to. The part where you mentioned "As long as you distribute only the shell script and not any of the GPL software on which it depends you're probably OK. " sometimes can get tricky which you kind of eluded too. So for example, what I understood based on your explanation is that suppose I call a function from a GPL/LGPL license library in my C program, I should be ok, right? Also does this also means that when anybody uses:
<#include <some-lib-header-file> in their C program their program cannot be considered as derivate of that function/library/header file?

Also right now I haven't started anything and that's why I was doing some background check before I embark on this journey. You are right, for a complex project I can use something more sophisticated like C/C++ etc. But at the same time even if we assume that programs based on shell scripts are simple, still there is time cost associated in developing a pretty long and a relatively complex script and that could potentially be a good opportunity to earn some cash, ehh? May be. :)


Thank you once again very much.

It depends. With the LGPL, this is generally correct, as it is designed to let the library be used by non-free software.

With the GPL, this is not so clear. The problem is that linking libraries and executables necessarily involves an intermingling of the code on some level. The question is whether that makes one a derivative work of the other. As far as I know, there is not universal agreement on this. Many people interpret the GPL as meaning that it is OK if your program links to the library dynamically, but not statically. Others (I believe Richard Stallman falls in this camp) read the GPL as forbidding any linking by non-free software. If you want to be safe, then the best course of action is to avoid GPL-licensed libraries and stick to ones that are under the LGPL, a more permissive BSD/MIT-style license, or a proprietary license.

Hmm interesting...AdaHAcker thanks for your insight. When you say "non-free software" does this definition also includes for example, a C program that I write on my GNU/Linux Debian system?

Well...that depends on what license you use for your program. "Non-free software" just means software that isn't released under a "free software" license like the GNU GPL. In your case, the answer would probably be yes, since you don't seem to want to release the source your hypothetical program.

Again, as far as licensing goes, the simple fact that you're writing your program on a system running Debian is irrelevant. What matters is what libraries your code links to and if you use any source that was written by someone else.

Yesterday I was reviewing the entire discussion on this thread and was trying to create a summary and I got stuck with the following two questions:

1. Suppose my work is considered as derived because I heavily used a GPL licensed library (statically linked) in my C program, does that mean that I automatically have to choose the GPL license for my C program?

2. Suppose if I statically link a LGPL licensed library to my C program, will my C program can still be considered as a proprietary program and can I still distribute it without releasing the source code? Or can I only do this if and only if dynamically link the LGPL libraries to my C program?

As a appreciation of all your efforts I am willing to write a blog entry which will summarize all the discussion here once I get some idea on the above two questions.

Yes. Even if you use a small number of GPL'd lines. That is the controversial GPL viral effect.
Your code can then remain proprietary if you choose to. You won't be required to release its source. You are still required to release any change you possibly made to the LGPL library.

If you want take a look at:
http://creativecommons.org/

They have a summarized version of many open-source licenses that are 'human readable' as opposed to 'lawyer readable' for example here is the one for GPLv2:
http://creativecommons.org/licenses/GPL/2.0/

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.