Background
Suppose I am working on a piece of open sourced software. Suppose I am unsure whether or not I want to sell it in future versions.
My question:
Would using a permissive license make it easier for me to sell my product in later versions?
"I am not a lawyer" but this is generally a good idea. Apache is actually very good for this.
From experience (including legal discussions) such as license allows you to push out an open source version, and then develop a much more capable closed version based on the same code.
Using an appropriate CLA also ensures that all community contributions can be used in the same way.
Of course, as the original author you can do what you want with your code at all times.
If you create your software and you release it under a permissive license first, you can offer that product under a commercial licence later, but you will have a hard time making money because the "free version" will compete with the "paying" version.
I have done this before. I started with a product under the LGPL. This is better than the Apache Software License, because people could use my software in a commercial context, but all improvements added to my software had to be released as LGPL too. This allowed me to improve my software. This obligation to contribute back doesn't exist with the Apache license.
Then I changed the license to the AGPL (after an IP review and after all core contributors signed a CLA). I also started offering the software under a commercial license. The license change dates from 2009 and still the old version of my product is one of our main competitors.
Read How can large open source projects be monetized? and How to avoid being forked into oblivion by a more powerful contributor? for more info. You should also read Eat Me; it reads like a fun story, but the reality behind it is harsh.
Both permissive and copyleft licences can work great, but they give rise to slightly different scenarios. Let's assume you have written an open source project OS, and a commercial fork COM.
In the permissive scenario, others are allowed to do more with your work, and you are allowed to do more with your contributors work.
In this scenario others can take your project OS, make a closed source fork and sell them for profit. You won't be able to get patches back.
At the same time, instead of forking your project and releasing their fork as closed source, or under an incompatible license, they could contribute to your project, and you are allowed to take the contributions others make to OS, and merge them in to your closed source fork COM, and sell it for profit.
In the copyleft scenario people can make a fork of OS, and this will be by definition copyleft as well. Your project OS can freely merge patches back from those forks. However your project COM can't make use of those.
To mitigate this in part, some organisations have a contributor license agreement (CLA), in which contributors assign their copyright to patches they submit to the project owner. Those projects often only accept contributions if their authors have signed the CLA. This way, you can still make use of patches contributed to OS in COM.
Patches contributed to a fork of OS are still off-limits for COM.
In the end in a permissive project it is more likely you can take other people's work and put it in your closed source commercial offerings, but it's also possible people run away with your work and start a competing fork.
In a copyleft project people can't run away with your work and make a closed source offering, but you are less likely you can take other people's work and merge it to your closed source offering.
In both scenarios you can make commercial closed source software with an open source base, but there are different risks and opportunities.
