Even though tinymce isn't written in Rust, it's plausible that a similar scenario might happen in a Rust crate: Someone wants to make a proprietary program and they see a cool crate that has MIT license so they start using it. Then they update their dependencies for whatever reason (routine of keeping things up-to-date, or they were notified of an important security patch, etc) via cargo update. And now all of a sudden the proprietary software is now legally forced to become copy-left & open-source against the intentions of the crate user.
Would be nice if we could add a warning mechanism to cargo update that notifies the user of a license change and asks for confirmation if the user intends to change licence on a dependency (which could affect the requirements of the dependent's license).
That sounds like a useful idea. My main concerns are
cargo update is not an interactive command today and I worry about surprising effects of adding interactivity to it without an opt-in which would reduce the benefit.
cargo updates messaging is transient and could easily be missed, especially if you automate your dependency updates
As mentioned, having an explicit lint for licensing seems like a better solution as it can prevent merging upgrades that change licenses.
We are starting to finish up the story for Cargo's built-in linter (User control over cargo warnings · Issue #12235 · rust-lang/cargo · GitHub) and have started to track what lints we may want to add. Baking cargo-denys licensing lint in directly into Cargo could be useful. If someone wanted to help it move along, it would help to explore how that feature has changed, what it lacks, and any other prior art so we have a better idea of what direction to design towards so we have a good foundation for this.
Small quibble: The more accurate effect is that the proprietary software developer could be forced to pay damages. Since they never agreed to the terms of the GPL, the worst you can say of them is that they infringed copyright.