There have been debates about which licenses or license types are best for preserving opensource freedom. I believe file-based weak copyleft licenses are exceptional. The purpose would be keeping code separate, while allowing use in some form. Dynamic linking is enough for most purposes, which use of the code is the most important objective of opensource.
File-based and permissive license ecosystem
There has been opposition to CDDL, because it had a different philosophy about openness than GPL. It turns out that CDDL is great, because it preserves a clear separation of its code, doesn't restrict usage unless it's not allowed by the other license, and is compatible with side by side use with more other open source licenses. Apache, MPL, other CDDL based licenses and LGPL when following certain rules can be used with each other. GPL doesn't have that type of compatibility with other licenses, and there's even restrictions of use between GPL versions to certain LGPL versions. For GPL versions to remain compatible, the patent license must match, or one version must be lenient on the patent license, because that part is viral beyond its own directory too.
Rationale for requiring those who add to programs to give back to opensource
Some tend to think Stallman's ideas are bad. We all don't fully understand GPL and how far its license boundaries go into other programs. GPL was intended to preserve openness. ISC changed to using MPL2.0 from the ISCL license because organizations would use their code and not give back. Receiving and not giving back was also a premise for Stallman forming GPL, because he wrote programs, which were used and added on to, then he couldn't use derivatives of programs he authored.
My misunderstandings
I used to see LGPL as a one way street into being converted into GPL, but so can any permissive license. As long as the code of the original permissive or LGPL license is preserved, all is good. One situation which we can see as became unfavorable, is the window manager FVWM, where one version is under a permissive license, and the derivative, which is version 3, is under GPL. It's a one way street, but at least we're allowed to still use FVWM3 under those opensource terms. There's many similar alternative and lighter window-managers and compositors, which use permissive licenses, and an infinite way for window managers or compositors to come into existence that, this isn't a loss. One way of protecting a permissively licensed programs' boundaries, while allowing its use, is incorporating it into weak copyleft licenses, that are incompatible with being absorbed into GPL or any other license.
I used to think of GPL as more viral than it was. In a way, it's viral to programs directly connected to it. A lot of source code under GPL is multi-licensed, by the author or because permissive code was absorbed into it, so the code can alternatively keep those terms, so long as its not connected to a GPL program. I also used to think, GPL would revoke a permissive license, but only, if and while that snapshot is connected to GPL. If GPL code would depend on an LGPL or permissive library, I used to think, that GPL would force that and other programs which depend on that permissive library into GPL, which it doesn't. So, because GPL isn't as viral as I thought it was, it's not too bad for lots of programs, especially graphical and capstone programs. GPL is good for endpoint programs, especially graphical ones, like Xpaint, Gimp and multimedia players/applications with GUI's, but not dependencies which are meant for widespread use across multiple programs.
Where the idea of GPL makes sense
The idea of GPL which is intended for returning improvements to programs, also makes sense for endpoint programs which are run by nonprofits and community use. While, GPL is made so companies or people must give back their improvements, the author doesn't have to do that, and can benefit financially from others improvements without having to give back all of their improvements. The author is able to use their program in a proprietary way, while the license to others is under the GPL. In fairness, that organization or program did give usage for that program in the first place. Also, another author can write a separate GPL program, which is used with that program, and keep their own controls on that, which if I'm not mistaken, the other author can't use those parts in a proprietary way. We see the problem of what happened with ownership of Audacity, but it can always be forked by the community and/or nonprofits without worrying so much about who profits. Code in complementary GPL programs can be created, which has its own likewise controls as the author, which leverages the code of the other author, while it doesn't go against the stated purpose of the GPL's own vision of free software.
The Linux kernel is GPL, but obviously, programs with incompatible and opensource licenses run on Linux. Wine runs on Linux and is also GPL, but proprietary programs obviously run on it. We knew that these ran together then, but maybe didn't see it thought out. Seeing these examples, GPL isn't as viral as the basic description would seem.
GPL needs alternative for similar purposes
If a newer version of GPL is made, which the patent clause doesn't go viral into dependencies or at into least FSF and OSI approved dependencies which have a patent clause, I believe it would be compatible with LGPL2 and LGPL3. I see a need for a or a few GPL replacements, where it can use MPL, Apache, CDDL, LGPL2+ and LGPL3 as dependencies, but where the viralness only applies to code which is dependent on or upwards of that GPL code.
I also see a reason for a replacement of LGPL with a file-based copyleft license, that is directory wide. It would be like LGPL, except, it would have simpler terms and wouldn't be incorporated into GPL.
Multi-licenses, also allow different codes to work together, though in MPL2.0, it is wordy to include this description, which otherwise programs already do this.
Previous LGPL and GPL licensed programs can and should stay, their roles would be limited in the opensource ecosystem to programs that aren't libraries or aren't needed by lots of other programs, just within a program's needs. There should be less need for competition with other opensource licenses, while those can remain on their own front end or end-cap place of the program ecosystem. Libraries and other programs which lots of different programs depend on shouldn't be closed off to GPL, while it's good that this largely isn't the case.
I used to see GPL as an issue, when thinking of how to reduce redundancies of programs which did the same thing, but had too many dependencies which dependency hell became an issue. The problem on FreeBSD isn't as bad as it used to be. OpenBSD's sndio, and certain audio programs turned into libraries (libcanberra), instead of full fledged form, made dependencies better. Now, I understand that, many libraries and dependencies of many programs are under LGPL, and I see LGPL in a better light now, as compatible for use with other programs. Another program is webcamd, which uses Linux drivers with GPL licensed code, but has BSD licensed files added to it, which that code can remain open for use with other permissive and file-based copyleft licenses.
Ecosystem of GPL, with permissive and file-based copyleft
I see a model, where permissive licensed code is kept separated as a different program, and makes use of that stripped GPL licensed code through linking. I believe that drivers should have been created (from Linux's side) as LGPL2+ at least: this includes webcamd and scanner drivers, which are GPL. GPL limits what kinds of opensource licenses programs that are used with it can be.
LGPL, CDDL and MPL allow other code to be dynamically linked to it, even proprietary code. While LGPL can't use MPL or CDDL dependencies, if I'm not mistaken, CDDL and MPL might be able to use LGPL libraries through dynamic linking, as they would be treated on the same terms as proprietary to LGPL's definition. Anything which is intended to work as a widely used library has to be LGPL, other weak copyleft licensed or permissive, provided that it's upward compatible with other open source licenses. GNU acknowledges the need for libraries which can be used across the board, if they are to be widely used. CDDL can be a glue which I believe can use LGPL below it, while it keeps GPL from being dependent on it. LGPL2+ is a glue which works with when what relies on it is kept separate, GPL, other opensource code and proprietary code.
diagram of permissive, file-based copyleft & GPL ecosystem, by dynamic linking use, not by inclusion into code. Parts may be wrong, or a detail may be lacking. This is to my understanding now.
Ports: organizing GPL from other licenses
FreeBSD allows the choice of license and license groups to use in /usr/ports/Mk/ of bsd.licenses.mk and bsd.licenses.db.mk.
I see a model, where code with FSF and OSI approved software with opensource licenses, that isn't GPL only, is kept organized. Then, GPL code which isn't mult-ilicensed to an other type of opensource license is sorted on top of that. This way, the dependencies which are opensource but aren't solely GPL can be sorted. Then, the capstone programs in GPL can be sorted on top of those dependencies.
Furthermore, fork model of Ports and Pkgsrc, where a main repository only has FSF and OSI opensource code, which are not exclusively of any GPL. The repository or sub-repository that depends on it, would be GPL2 and GPL3, without other opensource licenses, which would make it qualify for being in the main repository. In other words, if it had a permissive or weak copyleft license (including LGPL), it would go into the main repository, and GPL code without those other licenses would go into the sub-repository. For code which doesn't fall under either category, there would be another miscellaneous repository. The organization of those programs and the licenses they use would help people see and improve dependencies.
Diagram of model as basis of use within Ports, or basis of fork of Ports or Pkgsrc. It can be thought of as the part exclusively being GPL as jailed.
For short term use, a lot can be done without that model, and with basic understanding of how LGPL code can be used with other opensource licenses in the ecosystem.
LGPL association with bloat
In the past, I associated LGPL with bloat, seeing as how Cairo added a lot of excessive programs for simply enabling an SVG dependency. Another problem is how Pulseaudio, Avahi and Pipewire are intended to ingrain themselves within everything, including the network. I sort of get the idea, but it's pointless when OpenBSD's along with use by other BSD's alternative programs which do the basic sound or Zeroconf capabilities aren't full of that. JACK is also said to be good for professional audio. It's also pointless, when everyone complains about PulseAudio and Pipewire, and when its creator blames Ubuntu for implementing it incorrectly. It's because the program isn't as great as its creator thinks it is. A lot of code under LGPL is still implemented in a Linuxism way, for example, programs which compiling them calls for RedHat build tools which aren't native to FreeBSD. So, a benefit that those are LGPL licensed programs is, it gives the opportunity for forking, trimming, and using a layer to be linked to BSD programs. Because of the shortage of BSD share, it would make sense for loose opensource BSD standards so BSD's, other Unix-like OS's (OpenIndianna, Haiku, Minix) and opensource software makers can work together sharing the load, needing less contributors. Example of type of open standards and explanation Thread opensource-communication-frameworks-xmpp-sip-amqp-mqtt-cap-iax.79474
On the other hand, LGPL2+ has usage compatibility including through dynamic linking with GPL, other opensource licenses and proprietary code. This is what makes it and permissive license which don't have patent clauses most compatible, including with versions of GPL.
File-based and permissive license ecosystem
There has been opposition to CDDL, because it had a different philosophy about openness than GPL. It turns out that CDDL is great, because it preserves a clear separation of its code, doesn't restrict usage unless it's not allowed by the other license, and is compatible with side by side use with more other open source licenses. Apache, MPL, other CDDL based licenses and LGPL when following certain rules can be used with each other. GPL doesn't have that type of compatibility with other licenses, and there's even restrictions of use between GPL versions to certain LGPL versions. For GPL versions to remain compatible, the patent license must match, or one version must be lenient on the patent license, because that part is viral beyond its own directory too.
Rationale for requiring those who add to programs to give back to opensource
Some tend to think Stallman's ideas are bad. We all don't fully understand GPL and how far its license boundaries go into other programs. GPL was intended to preserve openness. ISC changed to using MPL2.0 from the ISCL license because organizations would use their code and not give back. Receiving and not giving back was also a premise for Stallman forming GPL, because he wrote programs, which were used and added on to, then he couldn't use derivatives of programs he authored.
My misunderstandings
I used to see LGPL as a one way street into being converted into GPL, but so can any permissive license. As long as the code of the original permissive or LGPL license is preserved, all is good. One situation which we can see as became unfavorable, is the window manager FVWM, where one version is under a permissive license, and the derivative, which is version 3, is under GPL. It's a one way street, but at least we're allowed to still use FVWM3 under those opensource terms. There's many similar alternative and lighter window-managers and compositors, which use permissive licenses, and an infinite way for window managers or compositors to come into existence that, this isn't a loss. One way of protecting a permissively licensed programs' boundaries, while allowing its use, is incorporating it into weak copyleft licenses, that are incompatible with being absorbed into GPL or any other license.
I used to think of GPL as more viral than it was. In a way, it's viral to programs directly connected to it. A lot of source code under GPL is multi-licensed, by the author or because permissive code was absorbed into it, so the code can alternatively keep those terms, so long as its not connected to a GPL program. I also used to think, GPL would revoke a permissive license, but only, if and while that snapshot is connected to GPL. If GPL code would depend on an LGPL or permissive library, I used to think, that GPL would force that and other programs which depend on that permissive library into GPL, which it doesn't. So, because GPL isn't as viral as I thought it was, it's not too bad for lots of programs, especially graphical and capstone programs. GPL is good for endpoint programs, especially graphical ones, like Xpaint, Gimp and multimedia players/applications with GUI's, but not dependencies which are meant for widespread use across multiple programs.
Where the idea of GPL makes sense
The idea of GPL which is intended for returning improvements to programs, also makes sense for endpoint programs which are run by nonprofits and community use. While, GPL is made so companies or people must give back their improvements, the author doesn't have to do that, and can benefit financially from others improvements without having to give back all of their improvements. The author is able to use their program in a proprietary way, while the license to others is under the GPL. In fairness, that organization or program did give usage for that program in the first place. Also, another author can write a separate GPL program, which is used with that program, and keep their own controls on that, which if I'm not mistaken, the other author can't use those parts in a proprietary way. We see the problem of what happened with ownership of Audacity, but it can always be forked by the community and/or nonprofits without worrying so much about who profits. Code in complementary GPL programs can be created, which has its own likewise controls as the author, which leverages the code of the other author, while it doesn't go against the stated purpose of the GPL's own vision of free software.
The Linux kernel is GPL, but obviously, programs with incompatible and opensource licenses run on Linux. Wine runs on Linux and is also GPL, but proprietary programs obviously run on it. We knew that these ran together then, but maybe didn't see it thought out. Seeing these examples, GPL isn't as viral as the basic description would seem.
GPL needs alternative for similar purposes
If a newer version of GPL is made, which the patent clause doesn't go viral into dependencies or at into least FSF and OSI approved dependencies which have a patent clause, I believe it would be compatible with LGPL2 and LGPL3. I see a need for a or a few GPL replacements, where it can use MPL, Apache, CDDL, LGPL2+ and LGPL3 as dependencies, but where the viralness only applies to code which is dependent on or upwards of that GPL code.
I also see a reason for a replacement of LGPL with a file-based copyleft license, that is directory wide. It would be like LGPL, except, it would have simpler terms and wouldn't be incorporated into GPL.
Multi-licenses, also allow different codes to work together, though in MPL2.0, it is wordy to include this description, which otherwise programs already do this.
Previous LGPL and GPL licensed programs can and should stay, their roles would be limited in the opensource ecosystem to programs that aren't libraries or aren't needed by lots of other programs, just within a program's needs. There should be less need for competition with other opensource licenses, while those can remain on their own front end or end-cap place of the program ecosystem. Libraries and other programs which lots of different programs depend on shouldn't be closed off to GPL, while it's good that this largely isn't the case.
I used to see GPL as an issue, when thinking of how to reduce redundancies of programs which did the same thing, but had too many dependencies which dependency hell became an issue. The problem on FreeBSD isn't as bad as it used to be. OpenBSD's sndio, and certain audio programs turned into libraries (libcanberra), instead of full fledged form, made dependencies better. Now, I understand that, many libraries and dependencies of many programs are under LGPL, and I see LGPL in a better light now, as compatible for use with other programs. Another program is webcamd, which uses Linux drivers with GPL licensed code, but has BSD licensed files added to it, which that code can remain open for use with other permissive and file-based copyleft licenses.
Ecosystem of GPL, with permissive and file-based copyleft
I see a model, where permissive licensed code is kept separated as a different program, and makes use of that stripped GPL licensed code through linking. I believe that drivers should have been created (from Linux's side) as LGPL2+ at least: this includes webcamd and scanner drivers, which are GPL. GPL limits what kinds of opensource licenses programs that are used with it can be.
LGPL, CDDL and MPL allow other code to be dynamically linked to it, even proprietary code. While LGPL can't use MPL or CDDL dependencies, if I'm not mistaken, CDDL and MPL might be able to use LGPL libraries through dynamic linking, as they would be treated on the same terms as proprietary to LGPL's definition. Anything which is intended to work as a widely used library has to be LGPL, other weak copyleft licensed or permissive, provided that it's upward compatible with other open source licenses. GNU acknowledges the need for libraries which can be used across the board, if they are to be widely used. CDDL can be a glue which I believe can use LGPL below it, while it keeps GPL from being dependent on it. LGPL2+ is a glue which works with when what relies on it is kept separate, GPL, other opensource code and proprietary code.
diagram of permissive, file-based copyleft & GPL ecosystem, by dynamic linking use, not by inclusion into code. Parts may be wrong, or a detail may be lacking. This is to my understanding now.
Ports: organizing GPL from other licenses
FreeBSD allows the choice of license and license groups to use in /usr/ports/Mk/ of bsd.licenses.mk and bsd.licenses.db.mk.
I see a model, where code with FSF and OSI approved software with opensource licenses, that isn't GPL only, is kept organized. Then, GPL code which isn't mult-ilicensed to an other type of opensource license is sorted on top of that. This way, the dependencies which are opensource but aren't solely GPL can be sorted. Then, the capstone programs in GPL can be sorted on top of those dependencies.
Furthermore, fork model of Ports and Pkgsrc, where a main repository only has FSF and OSI opensource code, which are not exclusively of any GPL. The repository or sub-repository that depends on it, would be GPL2 and GPL3, without other opensource licenses, which would make it qualify for being in the main repository. In other words, if it had a permissive or weak copyleft license (including LGPL), it would go into the main repository, and GPL code without those other licenses would go into the sub-repository. For code which doesn't fall under either category, there would be another miscellaneous repository. The organization of those programs and the licenses they use would help people see and improve dependencies.
Diagram of model as basis of use within Ports, or basis of fork of Ports or Pkgsrc. It can be thought of as the part exclusively being GPL as jailed.
For short term use, a lot can be done without that model, and with basic understanding of how LGPL code can be used with other opensource licenses in the ecosystem.
LGPL association with bloat
In the past, I associated LGPL with bloat, seeing as how Cairo added a lot of excessive programs for simply enabling an SVG dependency. Another problem is how Pulseaudio, Avahi and Pipewire are intended to ingrain themselves within everything, including the network. I sort of get the idea, but it's pointless when OpenBSD's along with use by other BSD's alternative programs which do the basic sound or Zeroconf capabilities aren't full of that. JACK is also said to be good for professional audio. It's also pointless, when everyone complains about PulseAudio and Pipewire, and when its creator blames Ubuntu for implementing it incorrectly. It's because the program isn't as great as its creator thinks it is. A lot of code under LGPL is still implemented in a Linuxism way, for example, programs which compiling them calls for RedHat build tools which aren't native to FreeBSD. So, a benefit that those are LGPL licensed programs is, it gives the opportunity for forking, trimming, and using a layer to be linked to BSD programs. Because of the shortage of BSD share, it would make sense for loose opensource BSD standards so BSD's, other Unix-like OS's (OpenIndianna, Haiku, Minix) and opensource software makers can work together sharing the load, needing less contributors. Example of type of open standards and explanation Thread opensource-communication-frameworks-xmpp-sip-amqp-mqtt-cap-iax.79474
On the other hand, LGPL2+ has usage compatibility including through dynamic linking with GPL, other opensource licenses and proprietary code. This is what makes it and permissive license which don't have patent clauses most compatible, including with versions of GPL.
