Licensing rant / debate thread

[astyle]

We have lots of licenses in the Open Source / Free Software world. CDDL, GNU GPL v.1/2/3, BSD, MIT, and more. Even QT Company has its own licenses that dictate what you may or may not do with their software. And those licenses do have purposes - like controlling the extent of plagiarism, making money off the software, and more. Yes, there's reasons for licenses to exist - but I sometimes see people talk like a 'proper license' really matters for their project. A bit of probing reveals - the 'proper license' (or any kind of license) doesn't really matter for their scenario, they don't even have anything really working, let alone something worth protecting with a license.

I can see situations when software licenses do matter. For example, there's a reason most workplaces prohibit installing unlicensed versions of Microsoft Office on their machines... Even with Java, you sometimes have to have a commercial license to install it on a work machine. Xorg is a big name in the Open Source / Free Software world, and it's got the MIT license as its preferred license. In case of Xorg, I see the license as more about protecting the good name of the project, and attempts at controlling plagiarism, rather than just about anything else.

I have also seen random comments on the Internet suggesting that one reason that Linux distros have not adopted (Open)ZFS is due to 'incompatible licenses' between ZFS and the rest of the distro...

As end user, I usually don't want to go down the rabbit hole of researching all those licenses and making sure that the terms line up and are palatable to me. I'm just happy if my software on my machine works correctly, has features I want, and doesn't break anything else. If I need to spend some time learning another feature of the software, that's OK. At work, I once had to spend some time with a rather awkward installation procedure because the license seat was supposed to be associated with one machine per license. It was just 5 machines, though. It's easier to just play along with that than complain about a weird / restrictive license.

So, why do people talk like the software license matters, when it really doesn't (for most people) ? After all, how many people are actually in a position to even care?

I'm hoping this invites comments and debates, and let's keep it civil, people!

 

[ralphbsz]

but I sometimes see people talk like a 'proper license' really matters for their project.

Completely agree. Most people who talk about software licenses in public don't need them, since they don't have anything of value that needs to be protected. Most of the debate is on religious or dogmatic grounds, and comes from deeply held but usually unfounded views.

In the real world (where real money and real world exist, usually in large quantities), licenses matter greatly. They do get talked about, but usually by experts, often lawyers specializing in the field.

one reason that Linux distros have not adopted (Open)ZFS is due to 'incompatible licenses' between ZFS and the rest of the distro...

It's deeper than that. As a file system, ZFS really wants to be in the kernel (or at least have extensive hooks there). In the case of Linux, that means that the code HAS TO BE licensed under GPL version 2. Why is this? Because Linus has said so. The kernel components of ZFS are licensed under the CDDL, which is not compatible with the GPL. From a technical viewpoint, it is obviously possible to make ZFS compile and run (even extremely well) under Linux. The few Linux distributions that ship ZFS are perfectly legal; they distribute ZFS as a patch to the kernel. But Linus will NOT UNDER ANY CIRCUMSTANCE allow that to be distributed with he standard kernel, and all the big distributions are unwilling to ignore his wishes. So the basic reason here is that Linus is the malevolent tyrant for life, and a jerk.

I guess I wasn't civil, sorry about that.

 

[astyle]

From a technical viewpoint, it is obviously possible to make ZFS compile and run (even extremely well) under Linux. The few Linux distributions that ship ZFS are perfectly legal; they distribute ZFS as a patch to the kernel. But Linus will NOT UNDER ANY CIRCUMSTANCE allow that to be distributed with he standard kernel, and all the big distributions are unwilling to ignore his wishes. So the basic reason here is that Linus is the malevolent tyrant for life, and a jerk.

I do have a hard time buying this without links... Like, is there any substance (and external analysis) to the claim that Linus himself is actually against shipping ZFS with the standard kernel? The adage about Hanlon's Razor actually says this (quote straight off Wikipedia):

"Never attribute to malice that which is adequately explained by stupidity."

I think there was some misunderstanding early on that snowballed into claims like that. Probably the same social dynamics that mangled the "I took the initiative" quote into a pop culture joke about being an incompetent liar who's trying to take credit for something they didn't do...

 

[mer]

Don't Use ZFS on Linux: Linus Torvalds

“Don’t use ZFS. It’s that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me.” This is what Linus Torvalds said in a mailing list to once again express his disliking for ZFS filesystem

itsfoss.com

There are plenty of instances on the Linux Kernel Mailing lists saying basically "ZFS is the devil spawn and should never be anywhere near the kernel" Some were pretty epic; don't recall who, but someone associated with the kernel proper basically said "ZFS, eff them"

 

[sidetone]

Linus Torvalds says “Don’t use ZFS”—but doesn’t seem to understand it

Linus should avoid authoritative statements about projects he's unfamiliar with.

arstechnica.com

There's something I didn't realize before, that's in this article. It says, LGPL isn't only for being able to use code outside of GPL, it can lead to proprietary code being forced into GPL. This hasn't been enforced yet.

I'm not completely certain, but maybe that can only happen when a decision is made by the original authors or a fork of that, for the license of LGPL code to be turned into GPL, so after that, proprietary programs which used that LGPL can still run on that old LGPL licensed product, and become not used with GPL code. If someone runs that GPL code with proprietary programs, the fault would be on the GPL side, not on the side of the proprietary or even opensource non-GPL side. No one should lose their rights should LGPL turn into GPL, and I'm not 100% certain this can't happen.


My point of view is that weak copyleft licenses are best, unless they come with hooks. Permissive code is needed for use with everything, that it can become a standard. I've been a proponent of permissive licenses, then, I see how permissive licenses can be a paradox with GPL or anything else. Permissive code isn't under threat, as it will always exist by the author in the last form it was in, as long as that code as it was, is preserved. I believe weak copyleft licenses have a protection that goes beyond end of software lifespans and authors, and it allows those who use derivatives to preserve it further in that free form including, if the original codebase it was derived from becomes lost.


A lot of it is dogma, and how I try to organize ideas.

In the future, I hope to pay others to write programs, and it be something with good terms and compatible with licenses of other programs, with less ability to be absorbed under a forced license. Some parts will be under permissive, and others will be weak-copyleft. I wouldn't need a stronger license, but there will be a frontend program that's under that as an example, that would be under a GPL alternative.

I also didn't like how CDDL was spoken as not good, because it had a different philosophy than GPL. I fell into that argument too. CDDL is actually better than GPL: it protects freedoms more than it restricts them, and that restriction is protecting it from becoming under GPL's terms. The only problem is the incompatibility, but it's compatible with more types of licenses, yet GPL2+ is incompatible with GPL3+. If people want to keep in the only compatible with GPL ecosystem, then fine. There should be alternatives, and if GPL's border limit is defined by link exceptions and use with API's allowed by the original author, that helps GPL work with other opensource licenses. GPL is viral in both directions, which tries to impede the spirit of what authors under other code wanted, so they simply can't use GPL. Other code can be used with other permissive licenses. What I didn't understand before, is that GPL's viralness doesn't extend down through a compatible license, then upward of all code which depends on it: it doesn't force code dependent on permissive code into GPL. The code exists as two different snapshots under rights and terms under both (or more) licenses. It's what the author dictates, until it's given up by that author.

I have a mental model of how opensource licenses (including GPL) can work together better. They already work alongside each other in some form, though without needing excessive replication of programs. I didn't understand LGPL2+ (LGPL2 series, not LGPL3 series) much at first, how it can be used, when dynamically linked, for almost everything, from GPL, to other opensource licenses to proprietary. LGPL2+ means there doesn't need to be replication. I used to notice how programs which were under LGPL came with dependency hell. For instance, svg added Cairo, which installed 50 other programs, when adding jpg, png or bmp added few dependencies. I believe sorting the licenses and using appropriate ones can result in less complicated dependencies.

In mailing lists, there have been people who say they want an opensource license, which has patent protections and that isn't compatible with GPL.


One reason it's important is, because how would you get proprietary software to run on Wine or on Linux? Isn't that a purpose of Wine? Because Wine is under LGPL, and because the Linux kernel has an exception on its API, which allows programs to run on it without being absorbed into GPL.

 

[astyle]

This ZDNet article actually also does a decent job explaining why the claims (of Linus not wanting to ship ZFS with the Linux kernel) are substantiated. I can see Linus wanting to avoid a lawsuit from Oracle. If Oracle would sue Google over how it puts Java to use, then yeah, you can't put it past Oracle to sue Linus over ZFS... And that's where licensing actually matters, not in a small-time roll-your-own project.

I can see Linus not being impressed with benchmark numbers (Yeah, ZFS does have a LOT of features, and they do take up RAM and processing power). But no, there's nothing Linus can really do to stop distros from shipping with ZFS. Yeah, Linus is the rock star, he does have the talent and many accomplishments to his name - Git, the very Linux kernel, and more. But, he also does not want to be a central focus of potential lawsuits from Oracle over ZFS. Or would it be expected that Oracle will go on a rampage over ZFS like SCO did over UNIX?

 

[mer]

I don't have the links handy, but the messages on LKML around ZFS as a "proper kernel module" were quite nasty.
Oracle lawsuit is a legitimate concern, but lots of other comments, have a more "not invented here" vibe.

 

[astyle]

I don't have the links handy, but the messages on LKML around ZFS as a "proper kernel module" were quite nasty.
Oracle lawsuit is a legitimate concern, but lots of other comments, have a more "not invented here" vibe.

Whoo! sounds like this: "Insider comments were not helping the situation, so it's easier to just not bother with ZFS than run the risk of lawsuit from outside, and uninformed vitriol on the inside"...

 

[mer]

Whoo! sounds like this: "Insider comments were not helping the situation, so it's easier to just not bother with ZFS than run the risk of lawsuit from outside, and uninformed vitriol on the inside"...

I think a lot started from the POV "Is CDDL compatible with GPL/LGPL", which honestly I think was a valid question.
Then toss in Oracle (even though the ZFS code was made CDDL/released prior to anything with Oracle buying Sun) and I can understand concerns around licensing.
But honestly comments against ZFS really did get nasty and sounded more personal and not understanding ZFS.
I followed the discussions for a bit, but then realized there were better soap operas to watch.

 

[bakul]

So, why do people talk like the software license matters, when it really doesn't (for most people) ? After all, how many people are actually in a position to even care?

Look up the Berne Convention. Under it, an author of a work written or recorded on some physical medium is automatically accorded all the copyrights in the work and any derivative work, until 50 years after the author's death (with some changes for various things but this is the main effect). So if you want to *give up* your exclusive rights, you need to say so. It doesn't matter that your work may be useless or incomplete. US joined it in 1988 and before that the US copyright rules were different. Before it came into effect in the US in 1989, you had to explicitly assert your copyright. That is why I got into the habit of adding /* Copyright (c) <year> <author>. All Right Reserved. */ in all my code! "(c)" because © was impossible to put in your 7 bit ascii file!

So the basic reason here is that Linus is the malevolent tyrant for life, and a jerk.

I don't see him as that. Besides, none of us are perfect Re zfs, in 2009 I had a linux zealot tell me I should switch to Linux because btrfs was going to wipe the floor with zfs.

 

[astyle]

Look up the Berne Convention. Under it, an author of a work written or recorded on some physical medium is automatically accorded all the copyrights in the work and any derivative work, until 50 years after the author's death (with some changes for various things but this is the main effect). So if you want to *give up* your exclusive rights, you need to say so. It doesn't matter that your work may be useless or incomplete. US joined it in 1988 and before that the US copyright rules were different. Before it came into effect in the US in 1989, you had to explicitly assert your copyright. That is why I got into the habit of adding /* Copyright (c) <year> <author>. All Right Reserved. */ in all my code! "(c)" because © was impossible to put in your 7 bit ascii file!


I don't see him as that. Besides, none of us are perfect Re zfs, in 2009 I had a linux zealot tell me I should switch to Linux because btrfs was going to wipe the floor with zfs.

I was hoping to limit the scope of the thread to just software licenses... but having said that, this is a good contribution to the thread that provides a nice contrast to the topic. The Berne convention seems to be weak and murky when it comes to software. And it doesn't address what happens when two competing works are developed at practically the same time (See appearance of Dennis The Menace in March of 1951, a British version and an American one).

Asserting the copyright or a license (under which your software can be used/distributed) can be an expensive affair. Comments in source code (even if it's a copy of GNU's copyleft) effectively amount to little more than an honor system. If you want to pick a fight to enforce it in actual court of law (complete with building a convincing case, lawyer consultation fees, and the like), that will take money, no matter how you slice it.

Having said that, the aforementioned honor system still has some use in tracing software lineage. For example, it's easier to use libjpeg from graphics/jpeg than to reinvent the wheel and re-implement the JPEG standard from ground up just to avoid having unpalatable license terms. Code re-use is a useful idea, and I see licenses (even toothless ones) as providing a structure to what would otherwise be a free-for-all madhouse where the ultimate winner is piles of money.

 

[graemep]

But Linus will NOT UNDER ANY CIRCUMSTANCE allow that to be distributed with he standard kernel, and all the big distributions are unwilling to ignore his wishes. So the basic reason here is that Linus is the malevolent tyrant for life, and a jerk.

Linuix does not have the option, nor does anyone else.

You are correct that because the licenses are incompatible (CDDL was deliberately designed to be GPL incompatible AFAIK) you cannot mix GPL code with CCDL code.

However. Linus (Edited - corrected spelling) does not hold the copyright on the kernel code - a large number of organizations and individuals do on different bits of the code. To mix in code that is under an incompatible license would require them all to agree, and the removal of any code whose copyright holder does not agree. No remotely practical.

So, why do people talk like the software license matters, when it really doesn't (for most people) ? After all, how many people are actually in a position to even care?

I definitely prefer to use code that can be forked an redistributed. That depends on the license, but on other things too.
For someone choosing an open source license for their software (whether an individual or an organisation) there are really two groups of licences. Copyleft licences (GPL and variants) do not allow code cannot incorporated into/resold as proprietary software (LGPL has an exception when used as a library), while liberal licences (MIT/BSD, and similar) do allow it. The decision will depend on lots of things - business model (e.g. if you want to dual license a library so you get paid for use in proprietary software but allow open source use), values, political and economic views (e.g. which you think is best for society), whether you want to prevent people running modified code (the reason Apple switched its default shell from Bash to zsh when bash switched to GPL 3) and probably more.

 

[bakul]

And it doesn't address what happens when two competing works are developed at practically the same time (See appearance of Dennis The Menace in March of 1951, a British version and an American one).

Except for the name the British Dennis the Menace had hardly anything in common with the American one. (I used to be a fan of the American Dennis the Menace.) No plagiarism here. You may be thinking of the patent system as independent invention of the same thing is not unusual and rules about who may get the patent have changed over the years.

Asserting the copyright or a license (under which your software can be used/distributed) can be an expensive affair

This has to do with derivative work. If you mix copyrighted material from two differently licensed works, which one applies? I am not aware of what the law is here but I’m sure untangling such use would be pretty involved. This is why it is best to not mix code from differently licensed work.

Just for reference,
Copyright is the legal term used to declare and prove who owns the intellectual property (the code, text, etc.).

Licensing is the legal term used to describe the terms under which people are allowed to use the copyrighted material.

 

[astyle]

I believe sorting the licenses and using appropriate ones can result in less complicated dependencies.

I think that worrying about licenses is an additional layer of complexity, on top of all the technical ones already there. Would you rather have 10 obscure dependencies (with palatable license terms) or just one or two well-known dependencies (which may do the job better, but have license terms that give you pause) ?

There's a difference between letter and intent of the licenses. Licenses can be assets or they can be liabilities. If accounting software Quickbooks has a bug that wipes out your small business, you can sue Quickbooks for the losses that can be pinned on that bug. Good luck suing the guys behind finance/gnucash. Point here is, I think people gotta ask themselves, "Why is the license there in the first place?". And no need to go very far down the rabbit hole to research the specific license. GNU's copyleft is primarily to shield the dev from legal trouble in case something crops up, and the GPL-licensed software stops working right. Licenses for paid software are there to protect the dev's revenue more than anything. Yeah, there's plenty of variety beyond those two. That variety can be discussed ad nauseam without reaching any kind of consensus about how the details line up. I do get the impression that with license conversations, most people are really missing the forest for the trees.

I see licenses as more about protecting the dev from trouble (legal or financial) than to really dictate terms to users. A couple quick examples I can give here:

• Neither Photoshop nor Gimp would arbitrarily shut down just because you're using the software for legally (or even ethically) questionable projects...
• Heck, there's quite a few GPL-licensed, network related userland utilities in any UNIX/Linux/BSD that can be used to launch perfectly devastating attacks like DDOS...

Point is, you can't really control what people do with stuff that you make. You can only keep yourself out of trouble. And that simple seems to be lost on people who try to try to line up license details. As an example, Linus Torvalds merely keeps himself out of trouble by just not bothering with ZFS (as I mentioned earlier in this thread).

There's nothing wrong with respecting the licenses when putting together your own solution - I just don't think that licenses are 'mandates aimed at users'. To reiterate my point, I see licenses as terms under which the devs protect themselves, really. Both in closed-source and Open Source camps.

 

[graemep]

And it doesn't address what happens when two competing works are developed at practically the same time (See appearance of Dennis The Menace in March of 1951, a British version and an American one).

That is a similarity of names, not works. The problem is with trademarks (and some related thing, I think). Unlike with patents it is incredibly rare (has it ever happened) for two copyright works to be independently created.

If accounting software Quickbooks has a bug that wipes out your small business, you can sue Quickbooks for the losses that can be pinned on that bug

I think it unlikely you could successfully do that. You might if you showed a very high level of negligence, but how many precedents (and across how many jurisdictions?) are there of people suing successfully for consequential damages from software bugs. Most licences will contain clauses that shield developers from liability.

GNU's copyleft is primarily to shield the dev from legal trouble in case something crops up, and the GPL-licensed software stops working right.

That is a reason to have a license rather than making a work public domain (although some people do put software in the public domain - e.g. SQLite).

However it is not a reason to choose GPL over BSD (or vice-versa): the BSD license has a perfectly good clause shielding devs from legal trouble.

The EU's Cyber Resilience Act will make such clauses entirely invalid for some classes of software.

 

[astyle]

I love what I'm seeing in this thread...

Licenses can be seen as a tangible guarantee of quality.

That does obligate the dev to put in some effort into chores like customer support, remediating bugs (AND the fallout from the said bugs, to an extent), maintain distribution channels, etc.

But....

Where do licenses even fit in the big picture of software? I'm trying to focus this conversation on the very idea of software licenses, why they exist, and when\why they matter at all. Having solid, well-thought out examples to give when participating in this conversation is what makes this conversation so good.

This conversation actually prompted me to find a good definition of the very term we're discussing: https://en.wikipedia.org/wiki/Software_license

For the dev, a license is a way to protect the good work (if the work is good enough to be useful to the general population). But for the user/consumer? That's a very different arena, with a very different set of interests and concerns. If a consumer finds license terms for a specific software to be unpalatable (Costs too much money, dev wants to be paid for every separate machine the software is installed on), it's not that difficult for the consumer to just say, "You know what, this software is not worth it", and go looking for something else. But if you want the software for its features, in spite of unpalatable (for the consumer) license terms? Either find a combination of features, quality, and palatable license terms, or you have a fight on your hands - right? Not so fast!

For private end users, license terms do have the effect of taking options off the table (Like not wanting to pay for Photoshop or AutoCAD, leaving you with GIMP and Blender). For those who are NOT private end users (think employers and distributors), it's more complicated, and that's where it pays to know what the license terms are, what is negotiable, what's not, the risks, the differences in available options, and other related details.

 

[mer]

Licenses can be seen as a tangible guarantee of quality.

I disagree.
Windows has a license and I've always questioned the quality of the product.

Licenses simply grant how something can be used, nothing more nothing less. In theory it binds people legally (that is often hard to prove/collect on/enforce.

 

[astyle]

Windows has a license and I've always questioned the quality of the product.

Thanks to that license, you can demand money back or legally compel their techs to troubleshoot the bejeezus out of Windows until it works right or those techs say uncle.

 

[patmaddox]

Where do licenses even fit in the big picture of software? I'm trying to focus this conversation on the very idea of software licenses, why they exist, and when\why they matter at all.

A software license is an agreement offered by the developer, made to prospective users of the software. That's really it – and then you can dig into what the terms and intent are of various clauses in the agreement.

I have a simple viewpoint: whoever makes the software gets to set the terms (i.e. choose the license). That's true in a legal sense, but I mean it more practically. I will never tell anyone what license I think they should use, or even advocate for a particular license in general. Instead, I license my work the way I want to, and am happy to share my reasons why. If other developers find that compelling for their use case, then great.

If you make the software, then as far as I'm concerned, you can choose copyleft, permissive, closed source, source available, or even that users-must-be-born-of-human-females one we saw recently. You make the software, you set the terms; I choose to agree to or decline those terms, and thus usage of the software.

 

[sidetone]

Liability and patent protections
Apache2 and MPL2.0 include liability protections for authors, like most other opensource licenses. MPL2 has an additional part, where someone who uses it can choose to offer their own guarantees accepting liability up to their choosing, but liability that doesn't extend to authors and others of that software. I used CTRL-F to search the term "liability" in MPL2.0

As for these, they have patent clauses. This is additional protection from patent trolling, while MIT offers protection by default, due to basic copyright law that once it is copyrighted, the idea can no longer be patented. MIT and other permissive licenses may be enough, though Apache and MPL's patent clause gives more legal power to protection from patent trolling. They allow patent use, but offer more protection from infringement by patent trolling or claims by those using this software. I believe the MPL's patent clause is more fair, because it allows overall judgements by judges. I thought I saw one of these licenses which stated, questions to court about patents were allowed, which would be good by allowing that freedom. MPL2.0's section on patent clause rights/protections:

If You initiate litigation against any entity by asserting a patent
infringement claim (excluding declaratory judgment actions,
counter-claims, and cross-claims) alleging that a Contributor Version
directly or indirectly infringes any patent, then the rights granted to
You by any and all Contributors for the Covered Software under Section
2.1 of this License shall terminate.

Apache's is simpler, but doesn't have these additional rights (named after "excluding" in parenthesis). While, Apache is permissive, it can't be used with certain GPL versions, because when a patent clause is not exact with those terms, it can't be taken into code under that GPL code (since GPL is viral). Now, Apache and MPL can be used together, while their codebases must be kept separate. Code under varying weak permissive copyleft licenses in general can be used side by side, while keeping their code bases separate and under their own license terms.

Apache and Mozilla are strong backers of their licenses, so using these offers much copyright and patent protection for authors' software. These are some of the largest companies for opensource software.

Libraries and backends, code which is depended on by varying code under different licenses
As for libraries, code which can be used with everything (while protecting the author's terms) is desired when linked dynamically or through API, including, varying opensource plus proprietary. All that fits this bill is permissive licenses and weak copyleft licenses. When intended to use with GPL, this places more limits to exclude Apache, copyleft weak licenses and other licenses. In short, permissive licenses without patent clauses and LGPL can be used by everything.

For libraries, the best choice for code, or for style desired can be chosen from. By using libraries which everything uses, it eliminates the need for duplicate coding.

LGPL is great, except, that it can be relicensed to GPL.

The problem with GPL
While, it seems great upon first hearing about it, it's viral more than they admit. It extends into software not written by the authors, and threatens to take it in through linking. They keep arguing that it's not so viral, but it is. To keep software under your own terms, you have to understand the reach of its license.

Where GPL is best, is for non-profits, and when their reach can be limited by a link exception at some API. If someone wants to use GPL, that's good, there's limits where it's useful for the rest of the opensource world.

Weak copyleft file-based permissive licenses
What's good about these, is they force those who add to their code to give back, however, only to the files under these licenses. This doesn't extend to software not authored by them, which some companies stay away from GPL, because they fear losing their own code that goes far beyond what they link to. To use GPL or LGPL, it has to be fully understood, because its terms reach too far, beyond a directory or file.

When code is put under a file-based weak copyleft license that doesn't allow re-licensing of forks, this is protected for use beyond the original author's terms. Let's say something is copyrighted under CDDL2, then that gets forked several times, and the original codebase is lost. That is preserved through the forks, so if someone wants to remake code similar in function to the original codebase or any codebase in that fork sequence, they can, without giving up rights or losing rights to that license. This is a protection that goes beyond permissive licenses.

Compare versions or forks of FVWM. The original was under a permissive license, and its still preserved. Additions and versions/forks of FVWM are under GPL. To stay under the original license, improvements or added features of GPL FFVM can't go to the original freedoms, of the permissively licensed code. Now, if it went under a weak copyleft file-based license, you can reuse code of any version since it came under or started under this license, in the newer versions of this, and keep it under these free terms. Permissively licensed versons of FVWM are still available online, but buried and have to be found. Features of GPL versions of FVWM can't be used without turning it into GPL.

Code under these licenses can get contributions from the closed source world, because there's a limit to what they can lose, and it doesn't extend to programs which are merely used with GPL. They got use of it, so giving back is insignificant, when the limits of what must be given up don't extend past the directory of the source code. The program got made better for all.

Comparison
An example of a clone or program of the same function of GPL written in a permissive file-based weak copyleft license, is Asterisk and FreeSwitch. Asterisk is under GPL, while FreeSwitch is under MPL1. Many developers made code for Asterisk, and they moved over to FreeSwitch. Asterisk is good, and those improvements wouldn't have happened without it and Digium. They'll still get their business, and good reuptation for making opensource software. For anything which needs additional rights to not lose software, which companies use hardware, they can use FreeSwitch.


Also, for Apache and MPL, code of these opensource licenses must be given up, but not their own code, if there's a conflict or if there's a lawsuit. With GPL, an entity loses their own code used with the GPL. The problem is, how far does that loss extend, by merely linking to GPL, because it's viral. Apache and MPL aren't threatening intrusiveness into other software, while GPL is.

I think that GPL controlled the narrative, and one perspective of free software and freedom, doesn't include other perspectives of free software and freedom. It needs to be challenged or pointed out, that there's better or other ways for opensource freedoms. As freedom for use, protecting rights, having a license which makes for a good library for varying other licenses, without losing rights is what's important. License proliferation may be complicated, as proliferation is bad for other topics, it would hinder GPL's reach. GPL2 and GPL3 actually hinder each others' reach, because they're incompatible for use together.

What I would make is a near replica of LGPL2.1, and make it so that forks can't be relicensed under GPL or anything, and so code and derivatives it covers always preserved under this license. If that allows use by GPL2 and GPL3, then great, but if it's not possible, that's also the best that can be for that purpose of license which would be for everything except GPL. If possible, it would be a library compatible for use with everything that allows it: GPL, proprietary, CDDL, permissive, file-based copyleft, permissive with patent clauses. Also, if possible to be compatible with everything, a patent clause like MPL2's, with clause exceptions for GPL licenses, but that can't lose its own terms to those other licenses, so, this license's rights come first. If they're incompatible, then that would be fine, as it won't lose its rights to another license.

My idea is to keep the GPL ecosystem, but keep it contained in one end of the opensource network, and limit its viral range, to that corner of the ecosystem, so people can use the whole combination of opensource software, while keeping the terms.

This is about legal use and of legal entities, not prohibited use. As it can be enforced and the rules of authors need to be respected by opensource licenses. Even if CDDL can't enforce its license, its terms should not be eaten up by a legal entity. If there's a way, it has to be through a loophole, where CDDL's terms can't be eaten up either. Why needs to be explained, or even investigated by a third party. Not for the sake of which is better, but for the sake of each license respecting the other, and the original code license respected.

I see CDDL's license of ZFS as a minor pyrrhic victory, where it proved its way, even if the original company is no longer. Licenses based on this have a purpose for software writers, based on using it for those purposes. Sun won ideologically, but sold the company. It proves (even eventually for more of us) that there's another way, that code doesn't need to be eaten up into a few dominant licenses, and not threaten other code's rights.

Preservation of codes' boundaries, and use of code with all that permits it while retaining the original rights intended are what's most important about opensource.

 

[sidetone]

CDDL has benefits but not fully ideal
I'm not sure that CDDL 1.1 protects patent rights for the opensource software, that it seems to prioritize patent rights of proprietary software rather than protecting opensource software. I didn't fully understand it. Either way CDDL 1.0 and CDDL 1.1 don't protect the way Apache 2.0 and MPL2.0 do. I'm not sure if CDDL 1.1 doesn't have OSI approval because of how its patent clause is, or because they didn't apply for it, as was theorized. CDDL 1.0 is OSI approved, and its only difference to 1.1 is a section on patent protections. Still, because CDDL licenses aren't viral, they can be used side by side with other nonviral opensource software. That's good for having a catalog of software which isn't GPL to work side by side with.

Benefits and limits of LGPL
As for LGPL2.1, it has a section that permits it to be unconditionally relicensed to GPL.

3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.

Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.

This option is useful when you wish to copy part of the code of the Library into a program that is not a library.

The GPL FAQ states, that what makes LGPL2.1 compatible with versions of GPL is that it can be relicensed to those. The following, in addition to the compatibility matrix:

7: LGPLv2.1 gives you permission to relicense the code under any version of the GPL since GPLv2. If you can switch the LGPLed code in this case to using an appropriate version of the GPL instead (as noted in the table), you can make this combination.

I was hoping it were compatible with GPL without that relicensing.

Before, I said that LGPL can be embraced, however, it's only useful as a layer compatible for GPL and everything else. All of its forks aren't safe from being restricted to GPL, but it's good enough for now. At least it doesn't force code used aside with it, to go under GPL and LGPL. When that GPL library compatibility isn't needed, LGPL should be recommended to be replaced. Perhaps LGPL should be tolerated, and in theory used only when necessary, rather than embraced.

Lessons from GPL and other opensource licenses
Sometimes GPL makes good points. One is to protect code from being made proprietary. Though, I want a license that also protects code from GPL, or if possible allows use with it if it permits it to keep its boundaries under its own conditions.

GNU complains about certain BSD licenses with advertising clauses, for said reason: each institution/author has to be listed, and this takes up a lot of pages. This makes sense, but it's actually less of a hassle than dealing with GPL's incompatibilities and far reaching restrictions. Because FreeBSD's license doesn't use advertising clauses, it's a preferred license by the GPL camp.

Apache 2.0 is compatible with GPL3, yet it's permissive, allowing it to be relicensed to that, because GPL3 made its patent clause around Apache 2.0's. FSF likes Apache for how patent clause protects open source. They also pointed out how code used alongside Apache goes into a one way street to proprietary code, not allowing its use for opensource. This is a similar concern I have had about code going one way into any direction, restricting use of additions to it. GPL protects code from certain cases, but code also needs to be protected from it.

On another note, one misunderstanding I have is that a BSD license requiring the license to be displayed, or Apache requiring that plus marking non-Apache licensed code, may be seen as restrictions, which GPL doesn't allow restrictions on its code. Though, that's more of a requirement for use, than a use restriction. This is how we use it, and accept its use, so that's fine.

Onward
Mozilla, BSD, MIT, CDDL and LGPL are good models and predecessors to what I have in mind. Without those, I wouldn't have an idea of a license which isn't ironic in terms of preservation of those freedoms. It's still ironic to me that, people who like BSD's and MIT's permissiveness, which means something else can take it up, complain about GPL. I've been in that camp, it takes coming up with a better license to circumvent that contradiction.

If I made a license that was like BSD and was directory wide, or if I took the Apache license, kept its terms but changed it to be directory wide, it would be up to them, whether that's compatible with different versions of GPL. If being directory wide, makes those incompatible for use with GPL, then GPL's presence should be challenged. It wouldn't be that difficult as GPL2 and GPL3 series challenge each other, and CDDL's are incompatible with GPL. What would make a directory wide license incompatible, is that it would carry the other license to its boundaries, and not be further restricted to GPL, by keeping its freedoms forever. In effect, that part of preserving its boundaries would be compatible with GPL, but it may not be further compatible, because it would have to carry both licenses, or the full code added later to it would keep freedoms that GPL doesn't permit. Come to think of it, this forcing by GPL may make that incompatible with a license that ensures it doesn't get forced. Permissive licenses which require marking code that's not under the license are close to weak copyleft file based licenses, as the difference in what belongs under the terms is file wide as opposed to commented.

So, my only issue with LGPL2.1, is how to have a replacement for it that's compatible with GPL's. Other than that, there should be a few types of replacements for GPL. GPL programs should stay for programs which are meant to work together, but it should be obsoleted for a wider ecosystem. It may not be possible to obsolete LGPL2.1 for libraries used for all, including GPL, except to make something slightly better and simpler, but that will unfortunately keep the premise of being able to be relicensed to GPL. The GPL alternative I would make, which would be incompatible with GPL, would be one that doesn't extend its viralness to dependencies and past any API, so it can be compatible with use with most libraries. This GPL alternative would be more restrictive than a directory wide license based on Apache or BSD licenses, as it would be viral only to dependencies, only forcing those to use the same restrictions. Instead of adding link exceptions to this GPL alternative, the directory wide based licenses based on BSD or Apache would make a less complex choice.

The license I would make would be based on FreeBSD's license, yet have an additional patent clause like Mozilla's, and be file-based, extended to directory wide. In effect, that would make it file-based weak copyleft as opposed to permissive, and any changes within the directory have to be given back, while the freedom remains for use (including linking, and keeping proprietary code) outside of that directory. This patent clause would make it incompatible with GPL. If a FreeBSD license variant could be directory wide, without a patent clause, or have a patent clause exception, and be accepted for compatibility with GPL, then, that could be a variant. It's better to have the best type of directory wide license availabile, which has the patent clause than be GPL compatible, regardless if being directory-wide also makes it incompatible. If being directory-wide in itself makes it incompatible with GPL licenses, then, those license are too invasive anyway. It would be up to GPL's determination if a directory wide license which is other wise compatible with GPL remains compatible with it, which it may not be. A directory wide license may possibly not be compatible with GPL, for the reason that it keeps its own code to itself and that prevents from GPL from directly using it fully as GPL. That code to this license must be kept to itself, and not forced into GPL exclusively.

The simple proposed license above wouldn't be the close GPL alternative though, as that would be a more restrictive license more closely mirroring GPL, which differences would be less viral that it wouldn't extend its viralness downwards, so it would have freedoms to use more opensource libraries, allow more linking, and its viralness wouldn't extend past any API, thus allowing freedoms past those directions too. This would be directory based also, but perhaps closer to strong copyleft, than weak copyleft.

I would also take Apache 2.0's license as is, but make that directory wide, for the purpose of further protecting additions to code which are used under it in future forms.

The purpose of a directory wide file-based copyleft license would be that no matter how many forks are made, if any are lost, the missing part of a wanted version can be recreated in spirit, and forks don't get closed off to proprietary or GPL. The freedoms would remain indefinitely for use (including linking), and to use it with anything which allows it. Only code added to the directory would be locked into the license, and code use outside this directory keeps its freedom from it.

Additions of new licenses would change the status quo of GPL, and those less viral licenses would be more compatible for use alongside each other. Proliferation would be ok as long as it doesn't become too complex. How programs are used side by side would be less complex and allow more choices of compatible opensource code to be used side by side. License proliferation is a threat to GPL's dominance, when there's a need for license compatibility with licenses which preserve freedoms, and when better licenses can do a better job in regards to opensource use, that GPL doesn't need to dictate the dialog any more. GPL2 and GPL3 are already incompatible with each other, and cause a break in the GPL sphere. They'll remain relevant to the program level, and for existing programs, but less so for system wide use.

 

[sidetone]

Basic patent protection and additional deterrents of patent clauses
It seems that Apache 2.0 offers a deterrent from infringement, intended as additional patent protection, from those who are using that Apache licensed code. It perhaps provides additional deterrent from those suing on infringement claims, that they plan on using the Apache 2.0 code as well. Apache 2.0's patent clause in its license is a deterrent, rather than an absolute protection.

I was looking for a term on here, which meant that permissive licenses are protected from fraudulent patent claims by default. This term may have been "prior art." This must already be the fundamental protection for all opensource licenses, including Apache and MPL licenses. The patent clauses that Apache 2.0 and MPL 2.0 have are additional, which don't cover all scenarios that default copyright laws cover.

I haven't read the patent itself but there's no way that's going to stick. Simply because of something called "prior art".

• https://www.uspto.gov/sites/default/files/documents/May Info Chat slides (003).pdf
• https://www.epo.org/en/learning/lea...handbook/novelty-and-prior-art/what-prior-art

These opensource licenses would apply as long as that opensource code were legitimately created by its authors. Although those affiliated with the opensource code would fix the problem if it there were actual copyright infringement, which isn't the intent of opensource.

OpenBSD's stance on patent clauses is a little extreme, as it says patent clauses restrict freedoms. Those freedoms shouldn't include patent trolling to infringe on copyrights. The only logical case against a patent clause, is the lack of widespread compatibility intended for libraries with specific viral licenses. One setback, while not a reason against, is that a patent clauses' protections are limited and are instead deterrents to infringements in limited cases. They're still a good addition in conjunction with true protection of prior art.

Some information for comparison of patent clauses and comparisons between MPL 2.0 and Apache 2.0 is at http://endsoftpatents.org/ and there's other insight from various stack exchanges. End Software Patent's position is as its name suggests, to abolish software patents. Seems good as it simply covers widespread protection, however, I'm not completely sure about that as there could be a middle ground stance. Ending software patents would be the simplest widespread solution However, software does need protection from fraudulent patent claims. I'm for protection of rights, including copyright or patent, so long as they're not frivolous or IP trolling, for both opensource and proprietary. The licenses aren't meant to infringe on those, and the assumption is that the authors won't do this. If such a scenario were to happen, I don't think patent clauses should remove legitimate rights to sourcecode. But if they're using the software, then, that license is open to others as well, and they're using the software under the licenses terms (patent clause or not) which includes their own contributions. Maybe if different contributions were infringed upon, instead of the one chosen to be shared in the same set of code, there would be a legitimate case of infringement caused by within the opensource side.

Back to comparison of Apache 2.0's to Mozilla 2.0's patent clauses
Apache 2.0 has additional restrictions, which cross-claims and counter-claims cannot be claims for patent infringement. It would make sense for a company to protect itself with cross and counter claims, although, this clause only is for patent infringement claims. In an example, a company gets sued for using Apache 2.0 licensed code, and the defendant, claims, it's not their fault, it's Apache's or the authors of that code's fault. The company should be able to defend itself, with Apache's help of the Patent itself, without resorting to shifting blame. Secondly, what if company set a trap, where one sues on fraudulent terms, and the second company is exempt from the terms, because it was a cross or counter claim, and they are able to get a ruling infringing on Apache code. This simply is unlikely to happen, because of prior art, but it's not a good additional deterrent if cross/counter-claims of infringement are involved.

The only part would be declarative judgements, which I question now. A company shouldn't lose rights, for asking of their license rights. However, this might be ok, because as long as the ruling is not a basis for infringement, so may get the client to seek a lesser ruling from a judge. Also, all they lose is the use of the licensed code. A person should have the right to ask what their freedoms are, and seek a judge's ruling, so long as their intent or result doesn't end up as an infringement claim. This is also on the basis that the authors don't actually infringe on copyright code, and do their work legitimately, which is expected in the first place. When people make accidents, the authors of opensource code fix it and are expected to fix it when it's found out.

From a search, it was pointed out how Mozilla's patent clause revoked all rights, patent and copyright for breaking the patent rules. Apache's license only withdrew patent rights for infringing on the license.

Apache and Mozilla are reputable and are cornerstones of non-viral patent clause included opensource. As for Mozilla, they may have more ability to protect their own licensed software with the more complex license. The Apache License is not overly complex and well written. Mozilla's license covers more details, and is complicated to be compatible by author's choice with multiple GPL licenses.

About Mozilla making its MPL2.0 to be compatible with Apache 2.0, from 2010: https://www.zdnet.com/article/mozilla-license-becoming-apache-compatible/. It also shows the popularity of Apache and Mozilla software communities and licenses in comparison to GPL.

Apache's license is revolutionary and other licenses have clauses based on it. Still, the patent clause is favorable among to those which were based on it. With an updated perspective, I would fork Apache 2.0's license, and only make up to two differences: make it a file-based directory wide license, and perhaps only change the declaratory judgement in the patent clause.

Apache 2.0 fork relevance to GPL 3
Adjusting the patent clause would definitely make it incompatible with GPL and making it directory wide would likely make it incompatible. The purpose would be to make the best possible license, which remains simple, than be compatible with a certain set of licenses.

Let's say the Apache fork keeps the same license terms, for that part to be compatible with GPL3. Make it a file-based directory wide license, whether or not that makes it incompatible with GPL3. It seems that, one criteria for a license to be compatible with GPL, is that it must be able to be fully absorbed under its terms at any time and through any fork. Licenses should be free from being locked off into exclusively GPL. permissive licenses and LGPL can be turned into GPL code, though ironically, before they are, they have freedom and their code isn't locked off, while being used side by side with GPL. The directory wide license would keep its code safe from viral licenses and proprietary license, while allowing use only with licenses or terms which allow it to be used. If a directory wide license is to be incompatible, then, let GNU, FSF or some other entity make a new license or variant of GPL3, which allows it to be used with a directory-wide filebased license, which would be compatible through, allowing use with that license while not forcing that code to become GPL under any circumstance.

For this type of compatibility, and forcing a compatible (GPL or GPL like) variant to be created based on GPL 3, I would only fork a change of Apache 2.0's license to be directory wide, and leave the patent clause and everything else as-is in the original Apache 2.0.

With this type of license, all variants, through all implementations, would be preserved for use with licenses which accept it. If a company or author stops producing or hosting a software, any version of that which is saved can continue the lifecycle of that code, to where it's not locked in to any license, opensource or commercial. Software, especially complex software, shouldn't be locked into proprietary or viral opensource licenses. The more I look at Apache 2.0, the more I like this license. Stallman (GPL) made a good case, how software needs to be protected from forks being locked into proprietary, and how as good as Apache 2.0, that code alongside it goes into proprietary and can't be used for opensource. This makes sense, however, in addition, code needs to be protected from being locked into GPL which doesn't allow code to remain in its own licensed codebase as well. Without GPL compatibility, a variant directory wide Apache 2.0 fork would still stand on its own, as there's plenty of opensource software already readily compatible.



I wrote Thread case-for-directory-wide-file-based-weak-copyleft-licenses.91037, which could probably be merged under this thread.

 

[GoNeFast_01]

Appreciate you going deep into this, I was going to do it privately on my own (did not have the chance)... So what I did in the meantime is just focus on software that are MIT, Apache, or BSD but always good to know the intricacies of all the license types in the wild. Thank you.

 

[sidetone]

Patent clause limits
About Patent licenses again, many contributors or users of software don't own patents, and may own copyrights. Apache's or Mozilla's patent clauses couldn't infringe on their IP (Intellectual property).

For those who have patents which need protecting, they can use their code with code that has permissive licenses, or nonviral copyleft licenses which don't contain patent clauses. Some, including nonprofit organizations, may be ok with allowing use of their patents, so long as it's only used by them and under the license for software they authored or used. The patent clause may be suitable for them, as authors and also as users of the code. For companies and people which have patent rights, where the priority is protecting the author's software over the opensource, they can look into CDDL 1.1. Whoever it applies to, can also look into CDDL 1.0.

For those which have patents they want to keep protected from the opensource, I propose a license on the basis of a permissive license without a patent clause, which is turned into a directory wide license.

Prior Art is the basis for protecting from patent trolls and other fraudulent patent claims. Patent clauses are a deterrent rather than a protection.

Another term which protects copyrights and use of public domain, that I forgot to mention is "de minimis". When a public domain or licensed work which allows other work to use it and place its own additional restrictions, de minimis means that minor changes that are slapped on to it and put under a more restrictive license, aren't original work enough to prevent those same changes from being made to the original. So, GPL can't take a page of BSD code, and add exclamation points to every sentence, or change a few spellings, and then lock those insignificant changes off from BSD code's use.

Library compatibility
GNU showed one way of using different versions of LGPL libraries with GPL. There's another way for GPL use with incompatible libraries. Authors can insert a linking exception. There are additives to other, including GPL, licenses that allow linking exceptions to otherwise incompatible libraries. I thought I saw licenses, which were partial licenses from OSI, which were license exceptions that could be added in addition to opensource licenses, but I couldn't recently find what I thought I remembered there was. SPDX and GNU list a few license exceptions.

• https://spdx.org/licenses/preview/exceptions-index.html
• https://www.gnu.org/licenses/exceptions.html
• https://www.gnu.org/software/classpath/license.html
• https://www.revenera.com/blog/softw...d-notes-understanding-gpl-linking-exceptions/

This of course depends on the author, also, when multiple software under the same license is used together, I'm unsure if that linking exception is still compatible with that other software. It's also unclear, how software will be labeled as a certain version of GPL, and while these linking exceptions are within the documentation, while when these pieces of software are listed, their license descriptions tend to get oversimplified to simply GPL and the version.

GNU/FSF/GPL simply needs to include a linking exception for a minor version update of GPL2 so it can be used with LGPL3 and Apache 2.0, that its patent terms don't extend into them. A minor revision update for LGPL3 could also make a patent exception for use with GPL2, so that the patent license wouldn't extend to LGPL3 and Apache 2.0. In short, LGPL3 is incompatible with GPL2, so make patent exceptions written into minor updates for both of these major versions, so that updated LGPL3 and GPL2 code can be used together without needing additional patent exceptions.

If the author of GPL code desperately wants to use a library from a license that's only incompatible due to its viralness, they can use a linking exception to that library.

GPL also needs minor updates that force minor versions to evolve, or simply get GPL replacements, so these can be compatible by not forcing patent viralness into permissive libraries, and to allow their use with directory wide libraries which keep their own terms, and are otherwise compatible.

I'm not sure if I misread from somewhere while writing this, about a problem with the GCC runtime exception. That if other GPL code was added into the compiler, that it makes that compiled code have to be GPL. The GCC compiler with the runtime exception is supposed to produce code which is free to license apart from the GCC license. So, if this is the case, GCC should include in its license, that these impurities that force up compiled code not to be included even if they are GPL, can't be included.

GCC Runtime Library Exception

GCC normally includes some GPLed code in the binaries it creates.

I didn't understand the context of that in https://www.gnu.org/licenses/exceptions.html, if the code produced by GCC is supposed to be free from the GPL license. The context was that proprietary plugins and extensions couldn't be used with GPL's GCC to compile, and that text is about contexts beyond that.

If I were to replace GPL
At the least, it would be a license, where it doesn't extend viralness into opensource libraries, by always having linking exceptions to permissive, directory wide copyleft, and other copyleft libraries. This license wouldn't be compatible with any current GPL license except LGPL.

It could alternatively be a license, which doesn't force its viralness into dependencies it relies on, including libraries.

These two ways would allow compatibility with all sorts of permissive and copyleft libraries, without forcing them to give up their code into its library at any time.

Then, allow it so that any API can be used to escape from the license. Anything used with the licensed code directories or group of software, must be given up to that code. At least this would have clear borders, and be simpler to understand without additional detail of where the exceptions are.

Licenses working together while keeping their terms
Now Apache 2.0's patent clause can be recycled into other licenses where it's needed, allowing more combinations. GPL needs to adapt to be used alongside software under more licenses, as software catalogs should grow under other licesnes. However, GPL can stay as is for more limited or current uses, and perhaps use linking exceptions as is to make use of certain libraries. Libraries are the most essential to be used with more software. If allowed, their terms would be more protected and contributions kept locked in, while not having to be forced to be more permissive, so they can be still used with current forms of GPL and everything else, and not be forced into being LGPL either. LGPL works for now, but it's the wrong balancing act.

• https://tech.popdata.org/the-gpl-license-and-linking-still-unclear-after-30-years/

 

[sidetone]

Noncompete licenses, relationship to opensource
I've seen the term BSL before, and I paid it no mind, because it wasn't opensource approved. I recently came across https://www.infoq.com/news/2023/12/functional-source-license/. After reading this, it becomes apparent that there's importance of contribution to opensource by this type of license.

This article is about the BSL and FSL licenses which are non-free, but are interesting, that they convert into particular opensource licenses, after a time period. The intent was to give the authors of code a head-start against competitors, but eventually make their code free to everyone, including them. They're called "non-compete" (or noncompete) licenses.

There are a few versions of Business Source License (BSL) used by a few organizations. Under Hashicorp it converts into MPL 2.0 after 4 years since publication of work. Under MariaDB's implementation, it converts into GPL2.0 after a certain amount of time.

Functional Source License (FSL) is a new license by Sentry based on BSL, to have clearer guidelines and to have a shorter con-compete period. It claims that 4 years is too long, and 2 years is sufficient. After the 2 year expiration date from publishing, the code goes under the Apache 2.0 License, through FSL-1.0-Apache-2.0: https://github.com/getsentry/sentry/blob/master/LICENSE.md

Sentry uses the 3 licenses of: FSL-1.0-Apache-2.0, Apache 2.0 and MIT. Their rationale for the MIT license is when a software needs to be used with a wider range of opensource applications, such as with GPL.

https://fsl.software/ is of the FSL. There's also the FSL-1.0-MIT license there: https://github.com/getsentry/fsl.software/blob/main/FSL-1.0-MIT.template.md

Even though non-compete licenses aren't opensource, they're a part of the opensource license extended community, because they convert into opensource licenses after a set time. They also have free use within certain limits during the non-compete period. In the meantime, within limits of the noncompete licenses, it could be used by some alongside opensource and nonviral copyleft licensed code. Noncompete licensing is also a part of the community, because it shows examples from more stewards contributing to opensource code, as it eventually becomes that. These organizations also separately host opensource code. In addition, Sentry has also donated to opensource maintainers, according to the topic article in this post.

Furthermore, there are many applications within Ports which use BSL, including quite a few which use it exclusively:
cd /usr/ports
grep LICENSE= [a-l]*/*/Makefile| grep BSL
grep LICENSE= [m-z]*/*/Makefile| grep BSL

Then, I stumbled on https://www.theregister.com/2023/11/24/opinion_column/. It argued that BSL and FSL aren't useful to opensource, while I disagree. It was against the newer FSL license, because it had a bias against BSL. However, newer FSL license is less restrictive and more free than the various unclear variants of BSL.

FSL is better than BSL, and they both become opensource over time, A premise of FSL, is that it makes innovations which need to be protected from rivals for a short period. It's better than BSL, that it converts into Apache 2.0, rather than GPL. BSL is also unclear and its patent clause is more open to interpretation by the various implementations of it. FSL's terms are much clearer.

Noncompete licenses were what I was looking for in 2017, which I refereed to as time delay licenses, Thread gift-of-open-source-freebsd-for-nintendo-of-private-property.60114:

It would be nice if there was a license that prevents a code from being GPL'd, until after a set time period so it can be fixed without interference, but then ensures that it becomes fully BSD licensed after that. A small problem with that could be, each line of code would be on a delay from the time it was created to be fully BSD licensed, but it doesn't have to.

As for a such time delay license, that wouldn't be an MIT license, it would be a different license that after a short time, automatically dumps the code to an MIT like license, without restrictions, releasing it completely once that happens. Also, I don't think that a time delay license should be enforced by BSD, but instead just be pointed out.

Other non opensource licenses
This later article introduced two more licenses, which weren't opensource approved. It grouped a seemingly harmless license together with a terrible one. FSL goes against the thesis of that article, while SSPL is an exclamation of it.

Commons Clause seems like an ok license at first glance, for one which isn't opensource approved. I didn't understand it, but it's rather a shareware license which gives more permissions than typical shareware licenses do, and has many opensource license aspects. https://commonsclause.com/. There's one argument that, it can be used on top of opensource licenses to make them less free and be used for one sided monetary gains. Then, there's another argument, that its use prevents that code from being taken over by predatory licenses and by companies which take and don't contribute. An argument against Commons Clause was certain restrictions for use. Commons Clause might be better than GPL in a few ways. For a shareware license, it may be good.

SSPL (Server-side Public License) is more restrictive than AGPL, and endangers the owned code to those who use it. It's extremely viral. Arguments for why that's not an open source license, I believe could be used against AGPL, and in smaller ways to GPL. It's used by MongoDB, and Elastic uses that and a variant of it.

A license I'm against, is one which is restrictive, heavily viral and which there aren't clear boundaries for use, that other code becomes endangered to it. SSPL is red alarm in my mind, in that regard. This license hurts the assumptions for other not opensource licenses, which aren't invasive, not viral and aren't terrible like this one.

The flaw in that, is that permissive licenses allow such a fork to something like horrible SSPL. Permissive licenses may be needed for libraries, so long as downward viral licenses like GPL exist. Elastic moved its products from Apache 2.0 to SSPL, so old versions of Apache, as long as they were preserved are free to be forked and continue to go into opensource. Mongodb was once under AGPL3.0 until 2018, and if that's preserved, that could be forked under that license.

• https://blog.opensource.org/the-sspl-is-not-an-open-source-license/

There's a distinction not addressed, from authors which produce code and put licenses on them which give freedoms within certain restrictions, to those who take others code without contributing in return and close it off. It a heavy contributor of code slapped a Commons Clause license on their affiliated work, it would be fine. If someone forked a piece of code to slap a Commons Clause license, to make money off of someone else's work, the argument could be made that it's a bad license. As for FSL, the authors have code to give, as they are putting a time delay or noncompete clause on their own work before it becomes opensource.

A lot of issues in this about the worry of code being blocked off could be solved with weak copyleft file-based directory wide licenses, or a license which isn't viral to dependencies or libraries it uses, and past API's. That code remains opensource, and stays in circulation as long as there's a copy anywhere forever, and it always keeps the liberty for it to be used with when it's allowed to. This shows, there's more need for it, as it's a near perfect middle ground to perpetually protect code in such a way. Instead of the Commons Clause being slapped onto that, it could only be slapped onto their own additions, plus, the code would be protected from what Commons Clause was supposedly meant to protect against, and from Commons Clause itself. It would be useful aside FSL too. It would absorb permissive licenses, and protect against AGPL, SSPL, viral licenses and predatory licenses. It's difficult for me to distinguish between AGPL and SSPL, except one is harsher and even more viral. In that case, MongoDB mainly belonged to the authors, so they were able to relicense future versions of it to SSPL. Perhaps AGPL protected versions of that code to itself before that relicense. That's plenty around the noncompete license and Commons Clause license, and stewards for those causes, means a larger ecosystem around opensource, which needs that type of license around.

• https://www.zdnet.com/article/open-source-licensing-war-commons-clause/
• https://www.zdnet.com/article/redis-labs-drops-commons-clause-for-a-new-license/
• https://www.finnegan.com/en/insight...-a-commons-clause-may-become-less-common.html