I am going to be releasing something I recently created, and wanted to have the most flexibility.
All I really want is attribution, but I also want the flexibility to change it later if I want - not that I will, but would rather have the option than not having it.
Which should I chose?
Also, do I have to do anything like submit it to a db or anything? Or just include (in the source code) that it is being released under whichever license?
Thanks.
MIT is most liberal, so everybody can do what-ever-they-want with your code. GPL for most companies is evil and they will not use your code unless it brings unique GREAT (...) functionality.
Licene: You need only to include your licene in your software package and in headers of your source code files.
MIT license = do whatever you want, just leave attribution. It should be ok to change the license later, since it says:
Permission is hereby granted, free of charge, [...] the rights to [...] sublicense, and/or sell copies of the Software [...] The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
The GPL instead is a persistent and propagative license: AFAIK when a piece of software is published under the GPL license, it can be redistributed and modified only under its terms; it also states that any "derivative work" must be redistributed under the terms of the GPL license or not distributed at all. To say it short, everything that GPL touches becomes GPL (or GPL-compatible); because of this, it is said to be a "viral" license.
Edit
Notice that, as @Martin Beckett said, if you are the author of the whole thing, you have the right that derives from your copyright on your own work to change the license for newer versions of the software.
LICENSE or README file or something like that; it's also probably a good idea to insert a reference to it at the beginning of each source file.
You can change the license later, or even license the code to different people under different condition - but that wouldn't affect code you have already released under it's license.
For example imagine if a new owner of eg. MySQL wished to change the licence - they cannot stop all the millions of people who were relying on code that had already been released continuing to work with their version. But they could tighten (or loosen) future releases of work they own.
The major difficulty comes if you accept patches from somebody else - unless you can persuade them to assign those changes to you, then you can only use those under the terms of the original license.
IANAL. Anything you've wrote is automatically copyright by you (assuming it's not a subject for some contract, employment, etc.). License is a permission you give to others to use your copyrighted work. You are free to choose any license and it doesn't change the fact of your copyright, therefore you can publish your work later under a different license or allow the recipient to choose among several licenses. The matter is a little bit more complicated if you're planing to accept contributions from others. Their contributions are copyright by them and they (sometimes) may choose any license to give to you or other users to use their work. GPL license ensures, among other things, that these later changes can only be published under the same GPL license (therefore it's sometimes called a "viral" license). BSD does not limit contributor's license. So may be MIT, I'm not sure. In any case, DO NOT try to write your own license.
The GPL isn't as all-or-nothing as it often seems; there are actually several. You can read about the differences here. Libraries and frameworks are often covered by the LGPL, which affects (infects) new versions of the library, but not software built using the library.
Also, I disagree with the 'most companies will not use your code...' statement about the GPL... My company uses almost 100% GPL software for stuff we're building for internal use; you only have to give away the source code if you distribute the program; any changes you keep internal to the company are yours and yours alone.
I'm a big fan of the GPL, but the MIT license is perfectly good... just remember, that under MIT, not only can you change the license at any time, but so can anyone who forks it. So someone could create an awesome new version of your software, close it up, and as long as they credit you for the original, they're in compliance.
IANAL, this is my understanding of the licenses.
It's your copyright, assuming it's all your code. This means you can do what you like with it. If you issue a version now under a particular license you can change the code as you please and release with a different license. The one thing you cannot do is revoke the original license you released it as.
For example, if you release 1.0 under MIT, anybody can do whatever they like with it as long as they give you proper credit. If you release 2.0 under GPL, then people can use that under the terms of the GPL, but they can still use 1.0 and possible changes under the MIT license.
It sounds like you probably want the MIT license. People generally use the GPL (or, to be precise, variants of that family) when they want to further the cause of Free Software, or when they have to because they're using GPLed software, or when they don't want other people to use their code without giving back. (The GPL is a good share-and-share-alike license.) People use the MIT and similar licenses if they don't care who uses the code or for what.
You don't need to register anything. You don't even need to register the copyright, although (at least in the US) it gives you advantages when dealing with infringement. Put the copyright notice into each source file, along with either the license or a notation of what license it's available under. If each source file doesn't contain the full license (which would be awkward with the GPL), include a copy of the license you're using.