Software Licensing Overview (Open Source and Closed Source)

This is a cross-post from Lockboxx!! Read dat shiiii

The world of Free Software licenses and Open Source Software licenses can be massive and confusing, compiled with the endless Proprietary Software licenses (regardless if Commercial or not), it can be hard to understand from a distance. I wanted to take a second to set aside some general high level categories with examples in each camp, to give people a general / quick idea of what a license might mean and which direction they want to head. I don't mean to water down the huge world of open source software licenses, but simplify peoples approach and understanding. It should also be noted that while I am a fan of law / ethics / philosophy in computer science, I am not a lawyer. I also found a really great site to help me make my choice.

Highly permissive software licenses:
These licenses generally provide free software with few constraints on derivative works:
Unlicense
WTFPL
MIT / BSD
Apache 2.0

Copy Left software licenses:
Most of these have some requirement of derivative works having the same software license agreement or similar qualities:
GPL
GNU GPL 2.0
GPLv3
Mozilla Public License 2.0

Highly restrictive / special conditions licenses:
These are typically representative of specific service agreements between two individual parties:
No License (same as Copyright)
EULAs (End User License Agreements)
Proprietary software licenses

What really started this conversation for me, was that publishing public code on Github didn't give other Github users the rights I thought it did. For example, code published on Github (based on Github EULA) without a license gives other Github users the right to view and fork the code, but beyond that the code is protected under Copyright, potentially scaring many developers away. I also feel like a big part of understanding software licensing is understanding the history of software licensing. At the end of the day the choice is yours and you should make the choice based on protecting and propelling the software you care about into the world.

How to continuously integrate, test and deploy

This post will walk through the steps of setting up a continuous integration server starting with a codebase from Github, automated by StackStorm.

Step 1: Deploy stackstorm on a server, following this guide.

• There are many ways to install/deploy stackstorm, I'll be using vagrant.
• I'm using my Windows based work computer to act as the server for this example, so vagrant is a great choice for getting things up and running.
• First things first, clone the project, cd to the vagrant folder within, and "vagrant up" to get started!

And we're off!

Whoops, looks like vagrant was updated since I cloned the project! Let's fix that...

Great success! It's installed!

This will install all StackStorm components along with the Mistral workflow engine on Ubuntu 14.04 virtual machine. The setup will download additional packages from the internet. While waiting, check out StackStorm 101 Video for quick intro. If setup is successful, you will see the following console output.

Step 2: Create a sensor to integrate with repository commits.

Step 3: Create a rule to merge all branches into the master branch.

Step 4: Create a rule to run all test cases, and if successful, deploy to production server.

Proto-Hack Challenge: August

Let's set up a Github account!

Drop a comment with your Github username so we can link up!


I'm Heshuge!