It’s assumed that your contribution will be licensed with the current license (generally). Maintainers can change the license but that wouldn’t affect prior contributions. Basically anything up to that license change would still have the original license. This is what makes forks possible when popular software changes their license.
In order to go back in history and change a license, you need either the consent of your contributors or a document that would grant you the power to do that. A CLA could (but not all CLAs will) grant a maintainer to change a license at will back in time.
Other famous software that has seen a license change: Redis and Terraform. In those cases the license changed but already released software is still available with the old license and that old license allows for forks.
My understanding is that permissive licenses (BSD,MIT) can generally be relicensed. For example you can fork a MIT project under GPL. But to do the same for a GPL project requires agreeement from all copyright owners, or just you if you made everyone sign a CLA. This is the whole point of GPL.
Your general understanding is wrong, as there's nothing in either BSD or MIT that allows for re-licensing, and nothing else gives you that right.
You can incorporate MIT/BSD code in a proprietary project, but that imported code itself remains BSD/MIT licensed. For many projects, this is a technicality, but no, you can't claim copyright on MIT/BSD code that isn't yours.
Technically your statement is incorrect. The MIT license allows dealing without restriction and sub-licensing, but the effect of re-licensing an MIT product as GPL would be a license with many unenforceable terms on the code that is MIT licensed.
> Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
> The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
Note the "deal in the Software without restriction" and "sublicense" permissions and the virality of the terms that require the permission notice must be included with all copies.
One problem with this however is if someone has removed the license from the software like what has happened here, then that software really has no license because the license doesn't specifically state that it applies to derivatives. The Apache 2.0 license is much clearer on that subject of derivative works.
No, it cannot. You can incorporate an MIT licensed work into a work that is licensed differently, but compatibly (not a real problem with MIT), but now you have three works that are under different licenses: the MIT part, the "other" part and the whole. The MIT part stays MIT. Someone can cherry-pick just that file (or file snippet) and use it under MIT, without caring about the license of the whole.
What happens when a file was previously under MIT, the license changes, and a new change is made? Do I need to look at the git blame to find which parts I can use as MIT?
You don't need blame necessarily, just git log. You look at the latest version under your preferred license. That's the one you take your snippets from.
Probably the sublicense wording that many techies confuse with relicensing.
Also sloppy wording in discussions like HN where "relicense" is sometimes used as a shortcut for "combined with a compatibly-licensed work in a larger work that can be used under the whole-work license".
It’s assumed that your contribution will be licensed with the current license (generally). Maintainers can change the license but that wouldn’t affect prior contributions. Basically anything up to that license change would still have the original license. This is what makes forks possible when popular software changes their license.
In order to go back in history and change a license, you need either the consent of your contributors or a document that would grant you the power to do that. A CLA could (but not all CLAs will) grant a maintainer to change a license at will back in time.
Other famous software that has seen a license change: Redis and Terraform. In those cases the license changed but already released software is still available with the old license and that old license allows for forks.