I am working on a product that I don't feel is completely ready but I have a set of users that are very interested in using it now as "alpha" testers. I would like to give them the product now for free as "alpha" testers, but I would like to later license the software.

Is this possible? Can anyone point me to any links/books/articles/etc?


EDIT: Due to the lack of my clarity and the reponses to the question I thought I should add this statement.

I haven't decided if I am going to close-source or open-source this project yet. The user base that wants to get their hands on it now has kind of surprised me and I was concerned about what my options are as far as being able to give it to them now as open-source and later change to closed-source, or even vice versa.

Thanks to everyone who has answered and commented. I appreciate it the insights.

  • Don't know about your problem in general, but this is a good book if you need any help with the actual licenses and understanding that part of the problem. Understanding Open Source and Free Software Licensing !enter image description here
    – Rook
    Commented Mar 6, 2011 at 19:20
  • 1
    Open or Closed source? Commented Mar 7, 2011 at 3:10
  • 7
    If you give someone a product you make for free, that doesn't mean that all copies or redistributions of that product must be free.
    – ProdigySim
    Commented Mar 7, 2011 at 3:21

5 Answers 5


If you own all the code, then you can re-release it under whatever license you want.

The problem comes if someone has contributed patches to the project. What usually happens is that they own that code, and they contributed it under the current software license. (You should have some sort of contributers agreement that covers this.) Therefore, to re-license it you will need their permission. Depending on how may contributers you have, this could be hard. For a reference for this, look at the OpenStreetMap license change and how long that is taking.

But IANAL, disclaimer etc.

And what people will make of your license change is another matter, as another answer comments on.

EDIT: I answered this as it relates to open source products. But re-reading the question I see it's not clear whether it's closed source or open.

If you are talking about 2 closed source licenses it's easy: If you own all the code, then you can re-release it under whatever license you want. Just make your alpha version commercial closed source license, all the usual terms (no copying etc.), just with a price of zero.

  • It's a fairly common strategy to have a commercial version with the latest features and updates, and have these migrate to a free open source version after a while. Alfresco and Magento do this, for instance. Commented Mar 6, 2011 at 18:30
  • The problem of course then, is also for him to prove(!) his code is used in the closed source application. Which will be harder for him to prove than for you to disprove.
    – Rook
    Commented Mar 6, 2011 at 19:18
  • @victor Yeah ... or have a basic version open and a closed commercial version with enterprise added-features. How these strategies work is another Q. The contributers agreements for such programs can be more complicated and may put open source authors off :-) @Rook Ok, I answered this question as if moving between open source licenses. If there was a issue with moving from a open license to closed one, you'd find the open source developer who suspects their work was stolen will have a lot of ppl & organisations on their side and you generally want to avoid the resulting flamewar.
    – James
    Commented Mar 7, 2011 at 0:12
  • 2
    What we do is have a contributor's agreement that contributors sign, and it assigns joint copyright (so both our corporation and the contributor own the code). In that way, we still have the ability to re-license, but they still have all rights that they had. This is the same way that SharpDevelop works. Commented Mar 7, 2011 at 1:21
  • @scott Yup, see sugarforge.org/content/community/participate/… for an example. They take all rights and give you a license to use your code. Speaking as a developer who works on a open source project tied to a business, I can understand why such things are necessary but I would still be thinking long and hard about whether I wanted to contribute to such projects :-)
    – James
    Commented Mar 7, 2011 at 7:40

This is a tricky question, which depends on how unique the software is, and whether you expect outside people to be able to make a lot of significant contributions.

If people only send you trivial changes to your software, then you (as the original author) would remain as the only person who would hold the copyright rights to the software, and, as such, you can close it down at any time you wish. However, realise that if you've released prior version of the software under a standard open-source licence, then anyone would be able to fork your software from such old copy, and thus, chances are, you might always have an open-source competitor to your proprietary software package. This is actually exactly what has happened to Tatu Ylonen, the original author of SSH, who has since been the founder and CTO of ssh.com, having not much to do with OpenBSD and OpenSSH, even though they distribute files with his copyright. (Although Tatu Ylonen's main publicly known regret is not related to copyright, but rather that he lost the marks "ssh" and "secure shell" into generic use, losing his trademarks.)

So, what if people do send you significant changes to your software, which would be covered under copyright, and which you'd want to integrate into your source tree? You could set up one of those legal agreements, whereby contributors would assign their copyright to you, thus, legally, you'll still be the only "author" of the software. I come from the FreeBSD/OpenBSD camp, and in our view, copyright assignment is generally considered bad taste. FSF is pretty infamous for their copyright assignment on most of their software; NetBSD has it as an option to their members (which allowed The NetBSD Foundation to remove two clauses from their licence in all files where none of the individuals claimed an individual copyright to); many commercial companies have all sorts of contributor agreements that do all kinds of assignment. Where does Linus Torvalds stand? Linus also dislikes the contributor agreements, and, as you may guess, Lunux kernel doesn't have any, apart from GPLv2 itself.

So, what if you do accept copyrighted changes into your tree, without copyright assignment? This is where your original choice of licence comes into play. If you choose GPL, and thus the contributors will licence their own code to you under GPL, too, then you're pretty much stuck with GPL, and will always have to release the source code to any subsequent commercial product (but so will all of your competitors). If you choose a BSD/ISC/OpenBSD licence, then you could close the source to add extra pay features at any time you wish, without having to release any of the source changes (but you're also giving the same right to your competitors).

Of course, if years down the line you decide that, in retrospect, you would have wished for your software to be under a different licence, you could always try contacting all of your past contributors to re-license their changes under your new licence. This is a very painful and long project -- what if someone cannot be contacted? Mozilla and VLC did such relicensing in the past; they've certainly must have enjoyed the benefits of their new licence, but I highly doubt they've enjoyed the years-long process.

Anyhow, regardless whether you choose to go GPL or BSD, having an open-source version of your software would always have a great deal of benefits, proven by many successful commercial companies that revolve around writing and releasing open-source software.


Your question is a bit unclear. The license doesn't typically control whether you give something away at no cost or not. The license has to do with things like ownership of the code, distribution, warranty and fitness for use, etc...

Are you intending to give them source code? If so, are you intending for them to be able to release their own products with it? Then you need a source code license.

If you are just giving them the binary, and don't want to charge for it, then you can just come up with a bare-bones license that covers your butt in terms of warranty and liability. State your copyright, say that it's only distributable as you specify.

Each version of the product you release is governed by it's own license, and if you are the sole developer, you can choose whatever license you want at any time, and change it at any time.

  • I appreciate your response. I suppose the lack of clarity is part of the question in a sense. I guess I was asking to see what kind of options I have if I wanted to let them have it with source now, and later decide to close it down (after the alpha period) or even vice versa.
    – Adam
    Commented Mar 7, 2011 at 15:08
  • Just don't include any license. They will then have on right to modify or redistribute. Commented Sep 23, 2011 at 13:25

Well, personally I think it's a good thing that you're thinking about licensing at this stage.

From a consumer standpoint, I don't think you should change licenses once you choose one. That's not to say you can't (Movable Type is one notable example), but you run the risk of driving your userbase away (Movable Type is one notable example).


Yes you can provide them with a limited time version that will stop running at a certain point in time.

You can always release new version with an extended expiration if needed.

Until you are ready with the final version.

  • That's not really a solution to the license issue (ie, the legal license under which the software is released to the general public), though. Commented Mar 6, 2011 at 18:50
  • I did't understand that in the question. He asked if he could charge for the software afterwards. That's how I translated the question.
    – user2567
    Commented Mar 6, 2011 at 18:55
  • 2
    I think your understanding of the question is fine. A way of solving a "license" problem with early releases is to timebomb it. Nothing wrong with this, and it stops the old versions from being used (and support demanded) off into the future. You can have all the nice legal stuff as well, but a PRACTICAL way of making the point that "this is early and won't last forever" is a good thing to have as well. Commented Mar 7, 2011 at 3:09
  • 1
    +1 But you obviously need to make the users aware of this limitation - they don't want to run the app one day just to be notified that it is now dead. Commented Mar 7, 2011 at 4:19
  • @KirkBroadhurst it might not be dead, just unsupported, so you would have to maintain any changes/bug fixes yourself. But yes, being clear about this is important.
    – icc97
    Commented Aug 22, 2018 at 7:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.