October 6, 2005
(Perhaps Obvious) Thoughts On Being an Individual Software Developer
Part I - Choosing a License
Disclaimer: I am not a lawyer, these are my thoughts as a software developer.
For me, there are three basic licenses I consider when I'm releasing a piece
of software.
1. A Proprietary License
This often seems like a safe first step--keep the source code to yourself,
let people use binaries, etc. I'm not aware of any "standard" closed-source
licenses one can use (are there any?). So it seems a lot of people end up
copying other peoples (expensively crufted) legal text, which may or may
not be that good, and raises copyright questions for the license itself.
At any rate, releasing software with a proprietary license has benefits,
especially since you can completely monopolize the software, giving you
potentially more opportunities. You can always open source it later, too.
The drawbacks to keeping source private are obvious, though. You can't get
people to work for you for free! (See Part II, below)
2. General Public License (GPL)
When I want to open source my software, and also want to ensure that any derived
versions of my software remain open source, I'll usually choose to use the GPL.
Contrary to what many people seem to mistakenly believe, by releasing your software
GPL licensed, you do not give up any ownership or other rights. While you grant
other people limited permission to your code, you still have rights including
the right to license your code under other (potentially lucrative) licenses as
well.
Licensing the software under other licenses does get more complicated once
other peoples contributions find their way into your codebase, though.
If you intend to license your GPL software under other licenses, you will
want to control who can contribute to the codebase (See Part II, coming
soon), and work out agreements with them.
3. BSD-like license
Using a BSD-like license on code makes it available for everybody to use,
with very little restriction on what they can do with it or how (usually
the main stipulation is how credit is attributed). It's really not too far
from making the code public domain.
The upshot of a BSD-like license is that you (and everybody else) can do
just about anything you want with the software. When other people contribute
code, they're giving you that permission as well.
The downside of a BSD-like license is that someone else can take your software,
and go make it (via big modification, or slight modification and promotion)
into something huge-- and all you will be entitled to is a small credit. Now,
the reality is that this could happen if the software was GPL licensed as well,
but at least then you'd get access to the modified source code.
Conclusions
Ultimately whatever license you choose someone can always go and (rewriting
if necessary) make something big out of your software, so (I keep telling
myself to) worry more about the upsides and less about the down.
Proprietary licenses are really good for software where you feel you (or your
close associates) will be working on the software a LOT, and want to maintain
complete monopolistic ownership and control. This is very attractive
to many people (myself included) for a lot of projects. It is completely
respectable in my opinion, as long as you feel it is justified.
If however, you feel like a project would benefit greatly from having other
people contribute, and the project has potential to be bigger than you've
made it already, using the GPL can be a good choice.
I find BSD-like licenses to be good for licensing of libraries (or any
other software that you generally want to be used as widely as possible),
since people can link (and optionally compile) them with their projects,
and not worry about the terms. Take zlib, which is used everywhere, or
jnetlib, which isn't used as much but I'll mention for selfish reasons.
Coming soon: Part II (or: how to get other people to work on your open
source project)
4 Comments
...and the front:
...and 
As a followup to the last post, here is a picture of the new Jesusonic model in development.
It's considerably smaller than the CrusFX 1000, and has plenty of room to shrink even more
for the production model. This is the secular alternative to the CrusFX, and has other
advantages. This one measures about 21" wide, 9" deep, and 3.25" high. I am pretty confident
that will be able to be more like 8" deep and 2.5" high soon.
On a personal note, it's very satisfying going through an interative design process, learning as
I go, and realizing "hey, the next model I can make it even smaller."
I think this model is going to get stained, as well. yum. The screen and keyboard will be recessed
into the top of it, the knobs will be along the front of the top (and they will be protected if
I get my way), the CF slot will be on the right side, all the power and audio i/o will be on
the back, and the right side will have the footboard and expression pedal ports.
Soon I will be building the custom boards for this model. I set up a new little desk just for
soldering and testing. fun.
I still need to find a nice compact backlit keyboard. help.
