On licensing, around hobbyist projects
Suing and other legal processes
Hobbyists typically can't sue or even worse, afford to be sued.
That's a major weakness.
And it means licensing between hobbyists are more like code of honors.
While a corporation can be a "copyright troll", sending a cease&desist
or worse without having the proper rights.
Which in quite few cases has shut down hobbyist projects, at least temporarily.
Yet because corporations can take over projects, either by forking them or acquiring the rights from the maintainers, projects should still have appropriate licensing. Otherwise it could horribly backfire on hobbyists, as frequently seen by either re-licensing to a proprietary license or adding a much more restrictive one than the current users of it can accept.
License compatibility
License incompatibility, unless there's an alternative implementation,
forces to abandon the feature/idea, rewrite the software, or acquire
a better license.
Hobbyist getting a better license from corporations is so rare
there's a whole lot of excitement whenever that happens even for
abandonned projects, meanwhile there's corporations almost entirely
dedicated to acquiring appropriate licences.
Rewriting software also being harder on hobbyists, specially if you need access to costy equipment or paywalled specifications to get part of the work done.
That means license incompatibilities hurts hobbyists the most.
Should also be noted that some corporations love using AGPLv3 combined
with requiring a Contributors License Agreement (CLA) that tends to
fully assign copyright to them or merely restrict to OSI/FSF licences
(meaning MIT and 0BSD are possibilities).
And it's not exactly a new thing:
- last paragraphs of SCALE: The life and times of the AGPL [lwn.net] from March 13, 2013;
- Debian, Berkeley DB, and AGPLv3 [lwn.net] from July 10, 2013.
cf. https://repology.org/project/db/information
Also I think the GPLv3 not achieving consensus with existing GPLv2 users while of course not being compatible with GPLv2-only was pretty much self-sabotage. And so since then, we got with the inability for some major projects to ever share code or even be used together without relying on dirty tricks like using IPC to circumvent copyleft.
Countering CLAs
One way you can oppose Contributors License Agreements (CLAs) is via
creating a community fork.
And if it's originally under a permissive license, consider putting
the changes under a copyleft license that's compatible with existing users
(at least libre ones). That way if they ever want to take code back,
they would have to either weaken or abandon their CLA.
Warranty reminder
Also because of the horseshit of calling vulnerabilities on random projects "Supply Chain", reminder that virtually all public licenses comes with this kind of text (took this one from MIT, you can also pick your favorite):
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Which is why to me, any corporation found whining about Supply Chain should be treated either as incapable of reading warranties meaning their products aren't trustworthy, or as wanting the equivalent of a support contract for free which is abusive.