I've been thinking about CDDL, and it's actually more honest and more functional for dual business opensource/share than dual licensed GPL to proprietary. CDDL 1.1 isn't OSI approved, and it was speculated that, it was because they didn't apply for approval. I wonder if it's because the patent clause, while is really basic as necessary, protects the shared product over that of other opensource. CDDL1.0 is OSI approved, yet the difference is that it lacks a patent clause. CDDL doesn't infringe on other opensource, however, it's incompatible with GPL, so that in itself might be perceived as an attempted infringement. Actually, the viralness of GPL is more infringing compared to other opensource. For instance, when a product is dual licensed, to proprietary and GPL, they get to receive improvements from competitors, but they get to keep their code from the GPL. This is where CDDL is better by being fair, and more honest. So what if company code is protected!? That's a good thing! That's the purpose of it, so they can share it, and neither side (company and free use) is infringed upon.
We should embrace CDDL, because that's one of the best ways for companies to share code freely, while at the same time, protecting their assets. When, thinking about GPL, all that's really missing is, for it to allow use of other opensource code through dynamic linking, but it doesn't. Arguably, this could be for use of only opensource code, or also dynamic linking of GPL code using any code which allows it, including proprietary code. They'll define what constitutes opensource, and whether CDDL is defined as approved to them. They likely won't allow it. However, GPL2.1 needs to be allowed for use with both major versions of LGPL. It also seems wrong that the only reason that LGPL is accepted with certain versions of GPL, is that LGPL can be absorbed directly to be GPL. Opensource, should allow the use of dynamic linking, but it should NOT force the absorption of libraries which can be dynamically linked, at minimum! Until GPL updates a minor revision for standardized acceptance of dynamic linking at minimum of other opensource, I can't embrace it like better opensource. I tolerate it, and have to pretend it's the way, it should be (while not pretending to the extent of going against its terms, which require complexity and additional explanations to make up for its shortfalls, and how it chooses to be and how its intended use). I disagree fundamentally with terms that it doesn't allow the use of other libraries through dynamic linking. I largely agree with if the part that restricts dynamic linking from it, as that's the author's choice on that part.
The other case about allowing dynamic linking to proprietary code which allows it, there's hocus pocus of how GPL is allowed to run on top of Microsoft Windows. There's no clear statement of separation, that GPL is used on top of a proprietary system. They'll say there is, but the fact is, even if Microsoft libraries aren't somehow used, somehow, the proprietary Microsoft system is used underneath. For the Linux kernel, the separation is in the license itself, as on top of a specific API, that noncompatible code is allowed beyond that. Another case is that, GPL could use something like ZFS libraries, without making hocus pocus statements, in a clear and way that simply avoids being challenged, if they allowed dynamic linking. They don't have to use ZFS itself, they could have made their own product, only using its libraries. Though they have their own alternative product now. Allowing use of dynamic linking, would also make it worthwhile to improve code, which currently has obstacles by the redtape that it has now.
In addition, GPL gets to virally pollute code intended under permissive license. One minor insertion, renders it all having to go by having GPL terms, unless it's cleared out, and people insist on keeping that GPL piece in that product. No one ever clears it out, such as to Xorg, with the rare exception of Xenocara which through using the minimalist of options. CDDL and Apache don't have the capability to do this. MPL2.0 only has the capability to do this, by its terms of making a description of when it's dual licensed with GPL, but it's not done through MPL at all by itself. GPL made that hurdle for which MPL tries to make a defined way to be compatible with it, which was already available through combo licensing. Unless an organization wholly keeps its terms to permissive or limited in not allowing viral license insertions, such as FreeBSD, NetBSD, OpenBSD, Postgresql, Apache Foundation, Mozilla Foundation and others do, massive pieces of code cannot be properly maintained. They'll continue to make excuses as to why Xorg includes unwarranted pieces of GPL. Yet, those orgs keep their code maintained, and keep it out, while when they can do that, it's ok for them to add GPL, outside of those large pieces of maintained code.
If I were to Tier licenses: the directory wide license, which always allows dynamic linking to and from with a patent clause, and those which are directly compatible, aside from dynamic linking, would be 1st tier. This would be due to the protection from being aborbed and restricted. Permissive licenses would be second tier, because they allow relicensing. Apache also protects itself better than other permissive licenses, by requiring preservation through notation of the original code. MPL and CDDL would be 3rd tier. LGPL would be 4th tier, because it's made to be abosrbed into GPL, without benefits of other licenses. LGPL allows other code to use it through dynamic linking, until it allows GPL to absorb it. LGPL will still be embraced, due to what it allows. GPL would be at the bottom or not approved by a new standard, simply for its viralness beyond where necessary, and prevention of default use of dynamic linking. It would just be tolerated, until if it's ever improved. It needs a direct replacement, if they don't improve that part.
Back to my proposed license of directory wide, and unconditionally permitting dynamic linking. Two clauses (directory wide file-based and dynamic linking unconditionally allowed) may seem redundant to each other, but it's better that way. If a compatible license wants to absorb this license, that combination can have stricter terms, except cannot infringe on the directory license and must still allow dynamic linking, when used in that combination. Those additional rules won't apply to code which is only used through dynamic linking. If someone doesn't like the additional rules, they can always pull the code out that's under the original license from that of the overlapping license, because those two licenses were used on compatible terms, where it applied to that combination. Also, by allowing compatible terms on top of the license, they can give a warranty to any version and combination of their choice, and it doesn't have to apply to everything under the above directory/dynamic linking allowed license, because it permits it. It's up to them what they want to do, such as warrant under the terms.
Let's say, an overlapping compatible license wants to provide a static library based on the code, then wants to restrict static linking from beyond that combination use. Then, that's accepted, because dynamic linking is always allowed from that license and closely used compatible license combination. Depending, also, static linking is allowed, until a license code combination restricts it, but dynamic linking can never be restricted directly from that closely used license combination.
If a piece of code is used through dynamic linking or even static linking, when that's not restricted by additional terms, then, that code doesn't fall under the applicable full terms.
This proposed license doesn't also need all of the terms such as that Apache 2.0 or MPL2.0 has, because it's intended to be permissive in principle and allow freedoms beyond the set down terms of clauses 3 and 4. In addition, it has other fundamental parts: the protections through the patent clause, and parts taken from other permissive licenses. If someone has a reason for additional terms incorporating code from under this license, or reasons to add permitted clarifications, they're free to make their own incorporating license.
For this proposed license, there would be different levels of use with other licensed code:
- Code which is under and compatible with terms of both the license and sub-license.
- Let's say, an organization wants to only give additional benefits like warranties to certain parts or versions. That would be fine, because the rest of their contribution to that directory still falls under the terms, and not their terms for additional benefits, which they would keep a clear additional separation for those benefits not restricted by that license.
- Also, code which is outside of the licensed directory, absorbed by the sublicense, but that combination of work still adheres to both licenses. Still, everything from the directory can be separated back out, under the terms of the original license.
- Code which is outside of the directory, and used side by side, such as with Apache, MPL or CDDL.
- That code doesn't fall under the license terms, except for allowed use.
- This perhaps might require the use of permitted static linking or additional another way of use. Static linking allowed, unless sublicense combo prohibits it.
- Code which is used through dynamic linking. If permitting, static linking, but see point 2 above for that.
- More freedom of use with that code through dynamic linking.
