A Question of Licenses
Which open-source license should I use for my software?
Okay, I'll admit it, I wrote this question myself because I've been asked it so many times I wanted to see it answered in print. As an attorney for open-source companies and projects, I am often requested to select a license (or to bless my client's selection) from among the OSI-approved, open-source licenses. (All the licenses described here are listed on the OSI web site at www.opensource.org).
The question puts the cart before the horse. What drives the license selection process is the client's business strategy, and not the other way around.
Do you intend to make money from licensing the software or from providing ancillary services like installation and training? There's nothing illegal about using a proprietary software license if that's what your business model dictates. Of course, as an advocate of open source, I'd try to convince you that there are many advantages to nonproprietary business models—but the client is the one to make the final decision.
What degree of freedom are you willing to grant to your licensees to modify your software? There are open-source licenses (e.g., BSD-type) that impose virtually no restrictions on licensees; they can modify the licensed software and create proprietary versions without restriction. There are other open-source licenses (e.g., GPL-type, more typically known as “free software” licenses) that require the licensee's modifications to be licensed back under that same license; this “inheritance” characteristic is an advantage if you want your licensees to have to reciprocate if they benefit from your contribution to the community. There are still other open-source licenses (e.g., MPL-type) that impose an intermediate level of freedom; modifications to individual files containing licensed code must be licensed back, but new files that merely work with the licensed code need not be.
Are you willing to grant warranties that the software will be “merchantable” or “fit for a particular purpose”? If your software is royalty-free, you probably can't afford a warranty. On the other hand, you may want to charge for your open-source software and use the profits to provide a warranty and other forms of service.
Is your software so well known that the main asset you need to protect is your trademark rather than your code? An excellent example of this is Apache. Their license allows you to do almost anything you want with the Apache code, but you'll have to change the name. If you have a trademark to protect, make sure your license contains appropriate terms relating to that.
Have you considered the possibility of dual licensing? The owner of a copyright in a software program always has the option to use multiple licenses. For example, you may want to license your software under the GPL and simultaneously provide a proprietary version for those of your customers who are afraid of the GPL's inheritance features; that unreasonable fear can be treated as a revenue opportunity.
Have you considered using different licenses for different parts of your software? Client software might be distributed under an MPL-like license, but server software might be distributed under a proprietary license. That way, you could make money from the bigger customers that will pay to license your server software and simultaneously build a large customer base with free client software.
Are you trying to protect the code itself or the standards that are implemented using that software? A license like SISSL allows anyone to develop modifications of licensed software as long as the licensee complies with all requirements set out by a standards body; a licensee who elects not to comply with the specification must publish a royalty-free reference implementation of the modifications so that the standard cannot be abducted by another company.
If there are patents that relate to your software, you will have to consider licensing your patents along with your code. You may also want to retaliate against any licensee who takes your free software and then turns around and sues you for patent infringement. Various licenses on the OSI-approved license list take different approaches to this problem. Some include a strong retaliation clause, others a weaker version that may be less threatening to customers with a large patent portfolio.
This is not an exhaustive list of considerations. You and your attorney should understand your business situation thoroughly before you decide on a license. Even after you answer these questions, you will still need to decide whether to invest in the attorney resources to create your own license or to have your attorney modify an existing license to meet your needs. If you choose to create your own license, your attorney will be able to tailor your license to your unique business requirements. On the other hand, modifications to an existing license may be sufficient. Consult an attorney familiar with your business to advise you.
Remember that your business objectives guide the choice of license. Anyone who ignores your business needs and whose first words to you are “use this license” is the wrong horse to push your cart.
Legal advice must be provided in the course of an attorney-client relationship specifically with reference to all the facts of a particular situation and to the law in your jurisdiction. Even though an attorney wrote this article, the information in this article must not be relied upon as a substitute for obtaining specific legal advice from a licensed attorney.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Roll your own dynamic dns
3 hours 21 min ago
- Please correct the URL for Salt Stack's web site
6 hours 33 min ago
- Android is Linux -- why no better inter-operation
8 hours 48 min ago
- Connecting Android device to desktop Linux via USB
9 hours 17 min ago
- Find new cell phone and tablet pc
10 hours 15 min ago
11 hours 44 min ago
- Automatically updating Guest Additions
12 hours 52 min ago
- I like your topic on android
13 hours 39 min ago
- This is the easiest tutorial
20 hours 14 min ago
- Ahh, the Koolaid.
1 day 1 hour ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?