[cyphar]

GPL doesn't require copyright assignment (the two issues are completely separate). And if the original author isn't the only copyright holder, they can't make GPL'd code proprietary either. Which is why going GPL is a benefit for everyone -- nobody can effectively make the software proprietary unless there is only a single copyright holder.

With BSD-style licenses, everyone is also on an equal footing, except that now users have no guarantees that the software they use will be maintained as free software. At any point, a treacherous developer or company could scoop up the talent from the community and make a maintained fork of the project proprietary. The original project dies because of lack of talent and now free software has helped expand the reach of proprietary software.

Note that even with copyright assignments, there are some good ones. The FSFs (optional for projects) copyright assignment has specific wording that guarantees they will always keep the code free (and even go further to state that it will always be copyleft and in keeping with their well-documented philosophy). If I had a single foundation I had to pick to assign my copyright to, it would be the FSF.

[Sanddancer]

That same treacherous developer can scoop up talent from a GPLed project too, such as the examples I gave. Sourceforge used to have a GPLed, but was brought closed, and the free version mouldered from disuse. Free software helped expand the reach of proprietary software. The GPL is no guarantee that a free version will always remain the most used branch either.

Going GPL also has drawbacks. Look at how Apache 2 and GPL 2 weren't compatible because of the Apache license's patent clause. That lock-in effect of the GPL means that your software package can't be used by the larger free software community. Which if you're satisfied with it, fine, but some people don't want to encumber their software as such. There's no such thing as a universal benefit.

[cyphar]

> That same treacherous developer can scoop up talent from a GPLed project too, such as the examples I gave.

I don't understand what this sentence means? Do you mean they take the developers and stop them from working on the original GPL version? In this context I'm referring to the most common case which is a GPL project that has more than one copyright holder.

In _that_ context is is not possible for a developer to take the existing work of the developers, make a proprietary fork, and convince the developers (in a moment of weakness) to switch and start working on the proprietary code. They can create a new project, but that's always true and not possible to restrict (nor would anyone want to).

> That lock-in effect of the GPL means that your software package can't be used by the larger free software community.

And this is the whole point of the "or any later version" clause. Every complaint you're bringing up has already been resolved by how the GPL is used and has worked for >20 years. Of course the GPL does have its downsides (the whole MPLv1/CDDL thing is a real shame) but "lock-in" is not one of them (unless you explicitly decide to lock yourself in, which is your own fault).

[Sanddancer]

It's absolutely possible in such a for the developer to make a fork. People can agree to change licenses, portions can and have been rewritten. Nothing keeps a license in stone.

I'm referring to the GPL's "no other restrictions" clauses that keeps things from interoperating with the Eclipse public license for IBM wanting to maintain choice of venue, the MPL, CDDL, 4-clause BSD, etc. Each of which the FSF says, "well, if they just used our license." The GPL is absolutely a barrier to cooperation.