Big Time Public License
writing.kemitchell.com
writing.kemitchell.com
Besides that, the definition of a "small business" is terrible. A company is only eligible to use the software if they meet all of these conditions:
- had fewer than 100 total individuals working as employees and independent contractors at all times during the last tax year
- earned less than 1,000,000 USD (2019) total revenue in the last tax year
- received less than 1,000,000 USD (2019) total debt, equity, and other investment in the last five tax years, counting investment in predecessor companies that reorganized into, merged with, or spun out your company
1M USD in revenue is shockingly easy to cross. It also means that businesses in high cost of living areas will be excluded before ones in cheaper areas, even if they're otherwise identical.
It's an interesting idea, but I think it's a non-starter.
100 total individuals is huge (you have HR and lawyers), but you can do $1M revenue (imagine it sans profit!) with a team of one or two.
This doesn't allow for YoY inflation. $1M today won't be the same tomorrow. The license should expect to issue new versions frequently to keep up with the economic landscape.
It'd also be nice if authors could customize their thresholds, but I suppose that gets into the complexity of Creative Commons. (Remember that? Where the heck did that disappear to? - you never hear about it anymore.)
That's addressed at the bottom of the definition of a small business:
> Adjust these dollar figures for inflation according to the United States Bureau of Labor Statistics’ consumer price index for all urban consumers, United States city average, for all items, not seasonally adjusted, with 1982–1984=100 reference base.
> Adjust these dollar figures for inflation according to the United States Bureau of Labor Statistics’ consumer price index for all urban consumers, United States city average, for all items, not seasonally adjusted, with 1982–1984=100 reference base.
If you're in a country with hyperinflation, sucks to be you. And that still doesn't account for the massive COL differences between, say, Mississippi and Hawaii (which is about 2.2x, according to https://usabynumbers.com/states-ranked-by-cost-of-living/).
I didn't see if it says how to convert, as there are often multiple exchange rates, e.g., an official one that can't actually be used, a underground/black market one, and purchasing-power parity (PPP). I don't think use outside the rich, developed nations has really been considered.
Perhaps because you are paying for software that eats into your profit margins?
As someone from a third-world country, I don't know whether to laugh or cry. I suspect that other than the hyper-inflated salaries in silicon valley, these metrics will be more than fair everywhere else.
Those numbers are a bad match.
It is not so poor by global standards.
Edit: clarity
> had fewer than 100 total individuals working as employees and independent contractors at all times during the last tax year
Yes, a company with 100 employees each working full time for a year would blow way past the $1 million/year revenue limit, so it might seem that there is no case where the 100 total individuals term could ever matter.
But looking at it again, I think what it is saying is that at no time during the last tax year did you have 100 or more employees. Read that way it is easy to have a business that fails that term without going anywhere near $1 million/year in revenue.
For example a business that makes some sort of holiday item that people only buy for a very short time every year. Most of the year the business has just a handful of employees making the items to build up a year's worth of inventory, then near the holiday that is all sold and they hire 100+ minimum wage workers to deliver the items.
I have a different loophole in mind. If you are a Huge Corporation, you are free to hire a contractor with 10 employees who each get paid 99,000 per year who uses your software for free? Can this contractor be a former employee? What if Huge Corporation is the contractor's only source of income?
(not just a hypothetical; I have witnessed this business arrangement.)
And what's the purpose of this license? Is it to generate revenue for the developer? If so, you want your terms to invite more liberal use by larger companies, as they may start using your project in more and more of their products which will net you more and more revenue. If it's too expensive for one of their products, it's too expensive for all of them.
The best way to get a large company "hooked" on your project is to provide an initial term of free use, like 6 or 16 months, and to track use remotely via metrics gathering ("checking for upgradeable versions on start-up"). Once they've used it for free long enough, you go and ask (politely) for your money. If you price right, it'll be cheaper for them to pay you than to remove your project.
Also the need for these style of licenses is shown by what happens when, for instance, AWS decides to just copy an open source project (that was put on a permissive open source license with the best of intentions) and then AWS just directly compete with the original maintainers/authors company.
This license doesn't claim it's an open source license. Apples and oranges.
I guess that's up to discussion participants and moderators to decide, not you (or me) individually. If you're not interested, nobody is forcing you to participate in the discussion.
Interesting articles about yet another commercial license are per se on topic for HN.
GPL (and, often, AGPL) you can see as sort of the "other" major strategy to running a commercial business on open source: instead of a non-commercial license, you make the free version fastidiously GPL, and charge people to get out from under it.
It doesn't hurt to cover all bases. The author thought of three qualities that would define a large business and AND'ed their negations to define a small business. It doesn't really matter if #2 almost always implies #1.
Users of open software are making use of work of others frequently without payment or any similar contribution to that work. At a certain scale, and that point can be defined in arbitrarily, your ability to free ride on the work of others ends. I don't how that is a controversial point.
Ever since I read _Hackers_ by Steven Levy a few years ago, I've been much less sympathetic toward Stallman, and the MIT AI Lab hackers in general. If you've read _Hackers_, recall that Stallman also strenuously opposed passwords. Well, it's absolutely clear now that restricting access to computers with passwords (or something equivalent) is absolutely necessary to defend against bad actors. So we should be open to the possibility that, while widespread sharing of source code is good, some kind of restriction on the usage of that code is necessary to protect the developers from freeloaders. I'm sure we haven't arrived at the best way to do this yet, but we won't get there if we immediately reject all attempts because they don't meet a definition of freedom that's perhaps too absolute for the real world.
I don't think that absolutism, which for me carries a connotation of purity or dogma. For me, it's a pragmatic choice. For me, software using this license doesn't have an advantage over other proprietary licenses. I view it as regular, commercial software with an trial discount. Which is OK! That doesn't make it bad!
If I'm not mistaken, the intention with newer licenses such as this is that developers still release the source; they're just not allowing unrestricted free use. So if they go out of business or drop support for that code, user can still continue maintaining it, at least privately. Meanwhile, the fact that the authors are getting directly compensated for the software makes it less likely that they'll go out of business or drop support.
The availability of source makes a big difference, doesn't it?
It helps a lot, but it's not sufficient by itself. Am I still allowed to use the software if the company goes away? Can I distribute it to my customers? Can I deploy it on servers it's not already deployed to? With FOSS, the answers are clear. Some commercial software also has clauses like "if we cease to exist, your license reverts to the terms of the MIT license" or such.
That said, we can't make policy decisions based solely on what leaves one group (in this case, the users of abandoned software) better off in the hypothetical worst case. We need to balance that with what's fair for everyone (particularly upstream authors in this case), ideally avoiding that worst case if possible.
I agree. The label 'source only' is considered a dirty word among some open source advocates. But if you are building a B2B (Business-to-Business) software product, 'source only' is a perfectly viable option to succesfully make a living from your product - one that isn't completely closed source (but one that clearly isn't open source). The source code of the product cannot be shared, but it can be modified by the customer to suit their needs.
The idea of 'source only' is not new at all. Back in the late 90s when Delphi was popular, many developers created and sold components to other developers (e.g. UI widgets). These components came with full source code of the components but they were not open source.
Fast forward to today, what are examples of 'source only' products doing well? Two examples: 'Kirby CMS' and 'Craft CMS' (Content Management Systems). Both are popular and profitable. Their source code is even published publicly on GitHub. The product creators trust customers will pay for the product (presumably some do not, but enough customers do pay so it doesn't matter).
Other developers are happy to contribute to the eco-system of plugins. So, yes, it's perfectly possible to build a community of enthusiastic followers for a 'source only' product that isn't open source.
WordPress is another example. Although WordPress is open source, the plugin market is full of 'source only' plugins for sale that are successful and profitable.
But pretending to be open-source and accepting contributions from people who mistaken your project as open-source is problematic. Or, in another word, changing your license from open-source to something else because open-source made it popular in the first place is problematic too.
You have two limitations on a product: - "actual physical limitations": the fact that you have the source, and that it's not a brutally-difficult life/career-consuming endeavor to edit it. - "artificial legal limitations": what the license says you can do
Typically the capabilities afforded by the latter are a strict subset of the former (legal freedom to modify is useless without the practical freedom afforded by the actual source — I could release something with the full rights afforded by an open-source license, but if I fail to actually upload my code, even if you're legally free to edit the binary, it's a mostly useless freedom). At the same time, it's very common for the legal limitations to be utterly irrelevant, whether it's a case of you simply breaking a law that's not relevant to you (perhaps from another economic sphere of the world, or maybe you're just poor — or something is abandonware and there's nobody to even pay, not even a publisher). In all of these cases only the physical limitation dictates what you're able to do.
--
If someone makes a freeware game, and it's abandonware — but it's source available, people can patch it so it keeps running on modern computers. They can translate it to other languages People can even fix egregious bugs. They can analyze it, and tease out internal mechanics and secrets, and document them on a wiki. If it's source-unavailable, then they're basically screwed.
Far from being hypothetical, what I'm describing is more or less how the entire rom-hacking community works — thousands of games have undergone this, where they've received unofficial translations, balance and bug fixes, etc. (I have at least a couple of personal favorites, where I had an RPG with certain abilities that infamously did nothing in the release copy, even though they supposedly applied buffs to your heroes. In a modded version, that bug was fixed and they fully worked as intended.) All of this is possible in the modding scene because this stuff existed in a state where something "awfully close to" the platform's source code was available in a non-obfuscated, direct form.
It's all illegal. All of it. That entire scene can't exist, legally, and survives on this wonderful, cockroach-like survivorship mentality of simply not caring that it's illegal, dodging lawsuits, and trading copies of things in defiance of takedown requests — which in turn happen so incredibly rarely that it may as well, practically, be legal.
--
Unix, for another great example, basically exists because "actual physical limitations" didn't restrict it — the devs made the source available, tons of people copied it in what was probably a rather illegal/gray-area way, and sure, some people kicked up all sorts of legal fuss about it (c.f. some famous lawsuits involving SCO group), but in practice the only thing that matters was the fact that it had illegally achieved ubiquity. At that point the genie could no longer be put back in the bottle.
And I dispute your claim that in the rom hacking community something "awfully close" to source code was often available. Plenty of times, mods are done using disassembly from the binaries. Disassembly is nothing like source code. Yet software patches based only on disassembly are possible, maybe even common. Source availability of course makes things easier. Documentation makes things easier still. Public version control of source code makes things eaven easier.
As a user of software, what are the benefits of something that is "source available" but not open source? Why would this be important to you?
I guess I can think of a few reasons. To help you learn how to use the software better than just from vendor-provided documentation? To help you find bugs, instead of relying on the vendor to do that? (when you're paying for software, these are kind of things one hopes one is paying for the vendor to do for you so you don't have to do it yourself, but we all know that hope is not always bourne out...)
What are the actual reasons people are interested in this, over ordinary "source not available" software distribution/licensing? These above, other?
There are a lot of cases where "source available" expects you to modify the code and even share patches with others. A popular example nowadays would be Unreal Engine 4, but it isn't anything new - Borland's OWL was distributed as source code and you need a license to use it (it is part of C++ compilers so any of their compilers would provide a license), but over the decades there have been improvements made by its users in the form of OWLNext that is meant to be installed "on top" of OWL (ie. wont work by itself).
That's exactly the point of the (A)GPL! It prevents freeloading because you have to release your contributions back to the community.
The developers on this site just hate the GPL because the lawyers at their company won't let them use those libraries.
Having reread it more recently, much later in my career, I was not no smitten.
> In the most intuitive case, the fact that the maker of a product, service, or program needs to recoup costs or earn fair compensation becomes irrelevant, if not overtly despised.
The classic "Open source will never be popular, because people have to get paid" argument.
> Software people, and their progress, über alles. ... Utopian communalism on the supply side, among programmers
So free software developers are literally Commie-Nazis? Got it.
> Often these strike a borderline millenialist, free-in-the-promised-land tone.
Oh, and religious extremists too, I see.
> The usual rules about permission, compensation, respect, and so on don’t apply, insofar as they’d apply to those making software.
Also, people who use free software are all thieves and pirates, apparently.
Hard no. https://en.wikipedia.org/wiki/Focal_point_(game_theory)
Once that line is relaxed, even slightly, more licenses like this will start showing up and running battering rams against all the other parts of that line that prove inconvenient compared to proprietary licenses.
This license is proprietary. I don't care if there's source or not, it's still proprietary. It does not serve the interests of Open Source to compromise on its nature to obtain somewhat more quantity of a far lesser thing.
The unusual foibles and preferences of specific people who are firmly in the history of FOSS are not relevant factors here. The relevant factor is drawing and maintaining a strict definitional line, because if we let that line become even slightly porous, it won't hold up to the resulting assault that would invite.
> some kind of restriction on the usage of that code is necessary to protect the developers from freeloaders
Absolutely. For instance, requirements that others share changes they make under the same license.
There's been a massive push in recent decades towards permissive licenses, driven in large part by a combination of companies who find permissive licensing convenient and individual developers who project a certain counter-counterculture "do whatever you want, I don't want to think about licenses". We're now seeing the net result of that: many large companies actually using those permissive licenses as written, and not necessarily the ethos behind them.
(And I object to the concept that hosting FOSS as a service is "freeloading". FOSS has always and only ever asked for giving back code, not money. Freeloading would be refusing to give back code, and companies regularly do fail on that front as well.)
> If Free Software can't feed its developers, they will look for food elsewhere.
FOSS can feed developers quite well. Some developers are deciding they'd prefer to sell proprietary software because they resent other companies benefiting from their work, and they're welcome to do that. What's not welcome is trying to claim the popularity benefits of FOSS without actually being FOSS; it is a good thing on balance that such efforts have met with chilly receptions.
There are many, many conversations going on about additional ways to fund FOSS development. The ones that have a hope of succeeding aren't the ones that start by abandoning FOSS.
Which is one of the reasons of disillusionment from them. On one hand, FOSS licenses only benefits developers who can fix the software to their liking – a non-developer user would likely just pay for it to make sure that they can get reliable, professional support. On the other hand, it assumes that the labour of developers is worthless (or at the very least, it's value is completely dissociated from its real-world impact).
> There are many, many conversations going on about additional ways to fund FOSS development.
Are any of them non-reliant on either the altruism of their users (donations, patronage, etc.), or selling value-added services that can easily be undercut by a party with deeper pockets (e.g., MongoDB vs AWS)?
It benefits everyone because if the original developers stop supporting it anyone can pay some one else to support it.
It benefits all because we can decide to fork, or pay some one else to fork, the software and customize it to our needs.
[1]: https://twitter.com/yazicivo/status/1469349956880408583
There are also various log4j forks.
And that is just the one project you mentioned, the world of Open Source software is very vast, with many contributors, forks, and financial sponsors.
Free software isn't about giving back code. It's about giving forward code. It's about being allowed to share code with others - if you want to.
Freedom 2 at https://www.gnu.org/philosophy/free-sw.html "The freedom to redistribute copies so you can help others".
https://www.gnu.org/gnu/thegnuproject - "Computer users should be free to modify programs to fit their needs, and free to share software, because helping other people is the basis of society."
> Freeloading would be refusing to give back code
This is counter to the freedoms of free software. Again from https://www.gnu.org/philosophy/free-sw.html
] You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist. If you do publish your changes, you should not be required to notify anyone in particular, or in any particular way.
Its no different than Google using the Java APIs in Android. The Supreme Court of the USA clearly ruled in Google's favor. It did not matter that the APIs were closed source software.
Further, I would disagree with using the term "freeloading" for some one who uses an Open Source program under the terms of the license in which it is offered. (Again, not even the case for AWS as pertaining to MongoDB).
Yes, they did, when MongoDB was licensed under AGPL. After MongoDB relicensed under SSPL, they release the API-compatible DocumentDB which is proprietary itself.
If I understand the synopsis of that article correctly, I don't think that concept applies here. Unless I've got my history wrong, our dominant standard for what's considered free software or open source, the Debian Free Software Guidelines (later repackaged as the Open Source Definition, wasn't the result of some kind of broad consensus among developers, users, and/or distributors. As badsectoracula pointed out [1] [2], source-available licenses with restrictions used to be more common. But Debian was always strongly aligned with the FSF's ideology; if I'm not mistaken, it was originally funded by the FSF, and of course, the full name of the main Debian distro is Debian GNU/Linux.
> The unusual foibles and preferences of specific people who are firmly in the history of FOSS are not relevant factors here. The relevant factor is drawing and maintaining a strict definitional line
My point is that this strict definition reflects nothing more than the MIT AI Lab hackers' elevation of their freedom (even at the expense of others, as in chapter 5 of _Hackers_) to an ethical absolute. Of course, most of those hackers outgrew that, but Stallman didn't, and he successfully spread the idea that all generally useful technical information, including software, should be freely available. And, if I'm not mistaken, that's where the DFSG came from. Since I didn't spell out part of my logic in my original comment, I will here: given that his nearly-forgotten campaign against passwords was obviously hopelessly naive, we should be open to the possibility that the same holds for the idea that software should be free for everyone to use.
> There's been a massive push in recent decades towards permissive licenses
Fair point. And I admit that this has made me stop and think about my choice of license for my own primary open-source project, AccessKit [3]. I was quick to permissively license that project from the beginning, before I considered funding. As it turned out, most of my development on that project so far has been funded by Google, which also specifically requested the Apache license (I went with the Apache/MIT dual license common in the Rust world). But in any case, I think a permissive license is actually the best choice for my goal with this project, which is to encourage and help developers to make as many GUI applications as possible accessible to disabled users. So yes, I want frictionless adoption above all else, but I think it's for a good reason. If a massive company used my project without paying me, I think I would consider it a net positive, because at least more applications would be accessible. But then, it's possible that by choosing a permissive license, I'm further poisoning the well, because I'm making more software available to freeloaders who would otherwise be obligated to pay someone (not necessarily me). FWIW, I'm thinking about developing an AccessKit-based module that has more of a niche use case (a screen reader for platforms or embedded devices that don't already have accessibility support), and for that, I might go with a dual copyleft/commercial licensing scheme.
[1]: https://news.ycombinator.com/item?id=29928956
The OSI (and indeed the whole open source movement) was formed explicitly as a counter to the FSF from people with a different ideological position. They were by no means temperamentally inclined to follow Debian; they adopted a virtually identical definition of open-source because it's the only one that works.
I am not, for the record, arguing that the DSFG or OSD is perfect. Far from it. There's reasonably widespread agreement that the continued existence of DFSG/OSD clause 4 is a mistake and should be revoked, for instance. And it's not obvious that a strict reading of the DFSG or OSD would allow the AGPL, if it hadn't been taken as nearly a given that it must. I also don't necessarily think all aspects of the SSPL are wildly worse than the AGPL (I think it fails DFSG/OSD as written, but not necessarily in a way that the AGPL doesn't), and I personally wouldn't be opposed to seeing a more blanket "it's OK to have copyleft requirements that trigger through arbitrarily strict conditions, as long as those copyleft requirements may always be satisfied by distributing full sources including all dependencies".
There are careful evolutions that may make sense to our definitions, to better serve the goals of FOSS; I don't believe that it should be an un-amendable definition. But I don't believe the principle that anyone can use the software for any purpose is a point we should compromise on. Even if you don't believe in that principle for its own sake (which I personally do), that point in particular is an incredibly valuable Schelling point; the most probable alternatives to it (which have been attempted) would run the gamut of random "cannot use for X" restrictions. It's far easier to agree on allowing all possible uses, insofar as people who dislike any particular use can nonetheless come to a consensus on allowing all uses.
> should be freely available
> software should be free for everyone to use
While I don't think you're necessarily intending to use these terms in an ambiguous manner, I think it's important in light of the point of this discussion that "available at no cost" was never the goal; "anyone should be able to get the source and modify" was the goal. Some people argue that "available at no cost" follows as a necessary consequence from that, but I don't think that's the case.
In terms of failures of vision at the time, I think it's notable that that goal didn't take into account how many people actually have the practical ability to take advantage of Open Source (taking into account both people with software development skill and people with the ability to pay others for software development skill). Those principles were absolutely developed by people primarily concerned with the practical rights of fellow FOSS developers, which to a first approximation they idealistically treated as "everyone".
> > There's been a massive push in recent decades towards permissive licenses
> Fair point. And I admit that this has made me stop and think about my choice of license for my own primary open-source project, AccessKit [3]. I was quick to permissively license that project from the beginning, before I considered funding. As it turned out, most of my development on that project so far has been funded by Google, which also specifically requested the Apache license (I went with the Apache/MIT dual license common in the Rust world). But in any case, I think a permissive license is actually the best choice for my goal with this project, which is to encourage and help developers to make as many GUI applications as possible accessible to disabled users. So yes, I want frictionless adoption above all else, but I think it's for a good reason. If a massive company used my project without paying me, I think I would consider it a net positive, because at least more applications would be accessible.
I absolutely agree with this. I believe there are extremely good reasons to use permissive licenses sometimes. Promoting standards (e.g. PNG, zlib, zstd); getting the rapid popularity to displace a prominent proprietary product; promoting important principles that are more important than the specific software itself (e.g. accessibility); any time you value adoption of something far more than any value directly accrued back to you.
If a substantial number of projects all use copyleft licensing, that carries much more weight than when fewer projects do so; it creates an ecosystem that people buy into and then gain much from. One library in isolation doesn't create a tipping point. It's not obvious if we can escape the equilibrium and attendant social pressures of mostly permissive licenses to the equilibrium of mostly copyleft licenses.
But in general, I do think that many projects just automatically use a permissive license, or automatically listen when a large company says they'd prefer a permissive license. Any time a company tells you that they'd prefer that you use a more permissive license, they're placing value on the licensing of your software, and that's value they may be willing to pay for. How much they'd be willing to pay is another question, but if you want to be able to sell alternative licenses you have to start from the baseline of a license that a company does not prefer and is not as comfortable with.
(As a Rust developer, I am sad that the norms of the Rust community strongly and pervasively push for permissive licensing.)
I'm not sure permissive Open Source licensing is counter-cultural. It's just a way for developers to take from and contribute to the software commons as part of their commercial day jobs. It doesn't challenge the status quo any more than the journals in which other disciplines might share and grow expertise on new techniques which are not considered trade secrets.
More restrictive Free Software licenses can be counter-cultural since the virality of those licenses can prevent software being 'exploited' by commercial entities. But that counter-cultural label only really applies to communal Free Software. Open-core business models while valid aren't really of the same spirit.
The balance between permissive and restrictive Open Source and Free Software licenses in the software commons of an area ultimately ends up reflecting the developer time that each model provides. And whether a particular license is permissive or restrictive will depend on the company. GPL JavaScript libraries are pretty restrictive as using them would likely require you to share your commercial application code under a permissive license. GPL Linux is effectively permissive unless your business model involves selling operating systems.
Open-source has started to become a weapons in the arsenal of Goliath against the David who may want one-day challenge it. If your only agenda is being free to fix your printer'a drivers [1], that may not be a deal-breaker; but many others are looking at something that provides justice alongside freedom. [2]
[1]: https://www.oreilly.com/openbook/freedom/ch01.html
[2]: https://writing.kemitchell.com/2020/07/03/Programmer-Power.h...
Whether passwords are necessary depends on context. Many family computers don't have accounts or passwords, and it works fine for the same reasons most houses don't have bedroom doors which lock. People are trusted to not be bad actors.
The early AI Lab was super-open, and it worked fine. Everyone knew each other, and there weren't (m)any bad actors. Part of the reason MIT CSAIL doesn't work as well is that it closed itself off.
That's very different from a 2022-era computer facing the public internet with billions of potential attackers.
This does have varied ramifications for developers, but all designed to prevent a downstream removing rights for a user to access the code running. And that's great, irrespective of your or my views on the chap who instigated it all.
This of course completely disregards the notion of computers having owners.
Unfortunately, we are currently way way in the other direction, with owners being deprived of control over owned devices by manufacturers and vendors.
Functionally, each of the prongs of Big Time's definition works as an independent tripwire. Cross one, the license no longer covers your business and you need to reach out for a deal. This approach, based on revenue, headcount, and capital, isn't unique to Big Time. It comes up in laws and regulations, as well.
With all that in mind, I don't think it's important for the figures, read together, to add up to a single, consistent picture of any one hypothetical business. I don't think they need to be convincingly proportional. Rather, each needs to prevent "end runs" around the others. If you're running accounting losses but paying lots of people, you need to make a deal. If you're three founders in a garage who haven't even tried to charge any customers yet, but just raised $3m in venture capital, you need to do a deal.
Wouldn't you have to be running the entire company on debt for this to be possible? And if so, what is the point of trying to get money from them?
Like if I said "I will give you £100 if you either give me a high-five, or if you punch yourself in the face until you bleed", they are independent tripwires but you might ask why the second was included.
A convenience store sitting on Any Steet, USA does around $1,600,000 in revenue per year (https://www.statista.com/statistics/308780/in-store-sales-pe...).
But they have a 2% profit margin, much like grocery stores, so that $1.6M really means $32k.
The purpose of the small business definition in the license is to isolate and waive through truly fledgling businesses. The assumption is very much that the licensor will also offer paid terms. So falling outside the free license isn't the end. It's just a redirection to a negotiation, with assurances of fairness and nondiscrimination.
Just say that any corporation based in Delaware has to pay for a license, and everyone else can use it for free.
Why?
My general impression is, if you excuse my flippance, this license has holes so big I could drive the fully unfurled James Webb telescope through it. I don't mean to be dismissive, so here's an example:
> `... indefinitely, if the licensor or their legal successor does not offer a fair commercial license for the software within 32 days of written request'
This is the escape hatch condition inserted for the safety of big companies that stop qualifying for the small-business section of the license. Except ... what is fair? More importantly, are you willing to spend six years in court arguing what 'fair' means? Because that is how you end up arguing what is fair in court for six years.
To be fair (ha), the license tries to firm up the term somewhat by defining the term later on as:
> A fair price is a fair market price for a fair commercial license. If the licensor advertises a price or price structure for generally available fair commercial licenses, and more than one customer not affiliated with the licensor has paid that price in the past year, that is fair.
Great, but what happens if the software has not been purchased before? How is 'more than one customer not affiliated with the licensor' going to be resolved? What does 'affiliated' mean and how broad we are talking about here? Unknown, until there is a software product that uses this license, gets very popular, and then we get to see the answers in court, through the poor developer dragged through hell.
The article mentions FRAND. The wikipedia page on it[0] goes into more detail, and links to discussions of how to determine a fair price[1].
[0] https://en.wikipedia.org/wiki/Reasonable_and_non-discriminat...
[1] "Formulas for fair, reasonable and non-discriminatory royalty determination" https://mpra.ub.uni-muenchen.de/8569/
> ' If you need a big-company license, reach out for a big-company license, and either don’t get a response, or get a clearly unfair, unreasonable, or discriminatory proposal, this is your fallback.'
'Too expensive' far as I know is not a part of FRAND, the fair in FRAND means something that is subtly different — though I am not knowledgeable enough to conclusively say FRAND includes this author's particular meaning of fair. To my best reading, it seems like it does not.
The courts help to develop expectations about how it will play out in practice by rendering decisions. But those decisions are inevitably contextual. In the end, it's an interpretation question. What do the words mean? The words to interpret are "fair", "reasonable", and "nondiscriminatory".
If it's good enough for patent policies between multinational Fortune 500s...
For me, as the creator of the hypothetical software in question, I am vastly, vastly disadvantaged — not only am I not a lawyer, I do not want to hire one because if I hired one for every sale I would end up bankrupt. Not only that, it is possible that the software the big company uses might be the last one they would ever get from me, if they so choose, so they have no incentive to play nice.
I probably do not need to quote you the Athenians response to the Melians, you get the idea. I would recommend, if you like to get any real adoption of your licenses with the developer community, to think more like the Melians and less like the Athenians.
I see and appreciate your anxiety about lawyers---their cost, the pain they exact, the helpless feeling that comes from handing over fate and control to an alien professional. But I also think you vastly underestimate how much non-lawyers can and do for themselves. Just because a dispute relates to a license, and license is a law thing, does not mean that everyone has to hire lawyers. Not hardly. No more so than most debates about open license compliance or terms of service violations entail crease-and-desist letters amongst JDs. It's part of why it's so important to write licenses in language people who aren't lawyers can feel comfortable reading. (And criticizing!)
I find it really hard to imagine a developer or small company using Big Time hiring a lawyer for every sale. That isn't the case for companies that "sell exceptions" to noncommercial or copyleft terms, and I don't think it would be the case with Big Time terms. Lawyers often are involved in license negotiations, which Big Time requires in some cases. But companies starting out regularly do all their own procurement. I've published several guides and forms that solo and small-shop developers have used to make sales on their own. You don't need a license from the state to negotiate your own software deals.
I also rather doubt that the average firm choosing to release its software under Big Time would be a Fortune 500 Goliath with a phalanx of lawyers. If you see the legal landscape as unavoidably Goliath wins, David loses, I suppose all four permutation are plausible: big licensor small customer, small licensor big customer, and so on. But even when you are small and they are big, consider the amount of effort large companies put into complying with open software license terms. If small-fry open software maintainers had zero leverage, big firms wouldn't bother, and they'd get away with it. We see the opposite: the bigger they are, the more likely they are to have people and process for compliance. It can't just be down to the size of the fighter...
If you really want to have a concrete definition of fairness, you're ultimately going to need to hire a lawyer to make a specific license. That could simply be an add-on clause to this license that explicitly defines "fair" as a term, and I think that's exactly the kind of plug-and-play license language that Kyle has done some work on in other projects.
That all being said, Kyle is generally very welcoming of (respectful!) feedback, and I think given how much time he's spent thinking about how exactly one can define "fairness", he might enjoy some fresh thoughts about it.
[1] https://writing.kemitchell.com/2019/12/02/Correct-Intuitive-...
So if you can point to a few businesses who are benefitting from those commercial license terms, you might be well within your rights to consider any license asking you to pay much more than that ‘unreasonable’.
Big Time's definition of "fair commercial license" will matter most as read by two groups:
1. small companies using for free who wonder whether they'll get gouged by the developer when when they grow up
2. big companies who find the software and realize they have to do a deal
The definitions would start attracting strong legal attention if and only if the company reaches out to the developer, does hear back with a proposal, but can't negotiate from there to a deal.
Compared to what we usually see with FRAND, Big Time does a lot extra to add clarity. It's not just vague principles about bundling and pricing, which we sometimes see from court decisions about FRAND. Big Time specifically addresses perpetual versus time-limited, with or without updates. It also adds the price-paid shortcut, which can collapse "fair" down to "what other customers are paying"---rack rate---with a very objective standard of evidence.
As an open-source developer, I do not want to sue people. When I mean holes in your license, I do not mean actual loopholes, I mean soft, bruised spots in the flesh that a skilled lawyer (which any company qualifying for the big company section of this license will have) can softly press to incur excruciating pain. I understand that you are a lawyer thus are much more comfortable with ambiguity and with the legal process, I am not — and I suspect many of us OSS devs are not either.
I cannot talk for the developer ecosystem, but I can talk as myself, as a potential customer of your license and the primary person bringing value to the table as the developer of the aforesaid software: I value clarity — any sort of discovery process where I have to hire a lawyer and work through what is fair because the license did not define it well is just such a nonstarter I don't know what else to say.
If you consider negotiating commercial terms an undesirably adversarial process, I completely understand needing to stick to, say, permissive open terms. There's plenty of murk even in the popular permissive licenses these days. I've written on them in MIT, BSD, Apache, and the GPLs. But those issues are largely ignored by small-shop and solo maintainers, because in their minds, the point is making clear there isn't anything to enforce in the first place. Many choose licenses with attribution requirements and simply don't enforce those, either.
You mentioned not wanting to sue people. I can assure that you the vast majority of fully closed-proprietary software companies don't want to sue anyone, either. It's costly, time-consuming, and hardly their specialty. Which is also why, the vast majority of time they have an issue with a customer or would-be customer, it's handled between business people, as a negotiation, rather than by immediately calling in thousands of dollars worth of litigators. Some fear or lawyers is definitely justified. But please don't overestimate how much of all the "legal work" out there lawyers actually do. Self-help is the most popular kind.
On the user side, I was saddened to read your comment. We've done a lot of work on Big Time to make it a whole lot more readable for people who aren't lawyers than even terms like Apache 2 or MPLv2. But the issue here is what Big Time says that's new, not whether it expresses familiar terms more clearly.
As for "nonstarter", I'd stress that the whole defined concept of "fair commercial license" only matters in the case where you are or become a big company. I hope you'll agree that threshold is more "objective": revenue, headcount, and finance thresholds. The consequence of exceeding one of those limits is that you have to negotiate a separate commercial license.
So if there's unpredictability in "fair commercial license" as defined, it bruises only the clear obligation of the developer to offer commercial licenses and negotiate, without gouging. Using roughly the same terms---FRAND terms---that huge corporations accept from other huge corporations when engaged in standard setting. We could have taken another tack, also commonly found in contracts, of requiring the developer to negotiate "in good faith", "reasonably", or both. But that would arguably offer less predictability, if you guess how a court would rule, than the developing FRAND concept.
Whether it's OpenSSL, the recent PLC4X story, or Filippo Valsorda's recent posting, we are constantly reminded of how unsustainable it can be for the majority of FOSS developers.
It's clear that relying on purely voluntary contributions to these developers does not work. Some model needs to be found that makes compensating more developers compulsory if we want to enable them to write/maintain their code as anything other than a hobby. This needs to be through a legal mechanism rather than social/moral pressure, because businesses understand legal requirements and most fulfill their legal obligations.
I understand the pushback against calling this a Free/Open Source license, but the author never categorizes it as such.
There is a strong good-faith foundation in this license of keeping it zero cost for those least able to pay, or most deterred by cost. It preserves the benefits of everybody being able to see the code they're running, make their own fixes/changes, etc.
I get drawing some line around core OS components, etc., as needing to be GPL/BSD/MIT, but what alternative models to this kind of license are people proposing to deal with the sustainability gap? Nothing forces you as an author to use this type of license, nor are you forced to use products based on this license. I don't see a widespread way to address the sustainability gap while also religiously expecting all this code to be "no economic strings attached".
If we all agree not to call it FOSS, does that tamp down the loud objections?
That's all well and good. It's still a proprietary license that rejects the most basic principle of open source, which is the ability of anyone to use and modify the software. And there's nothing wrong with that, but it's silly to expect FOSS advocates to embrace it.
Anyone is able to to use and modify the software, it's just that if your entity is large enough, you don't get to use it at zero compensation to the licensor.
The reason I would expect more FOSS advocates to embrace it is that other than this or a limited few other models (e.g., open core, commercial licenses to relieve GPL copyleft terms), what other avenues do they propose to exploit to ensure developers/maintainers are able to fund continuing development and maintenance of the software commons?
It's not like typical proprietary licenses to binaries where even if you pay, most likely you won't get the code (the exceptions are a low proportion of all proprietary licenses). "Shared source" as MS seems to define it makes you prove you're in one of their qualifying groups before you get to see the code - i.e., it's not like it's up on GitHub. And there are likely penalties if you share the code.
Shareware was also rarely distributed in source form, often had nag mechanisms/crippling, and didn't tend to distinguish between personal or non-commercial users and large institutional users. So I don't think "shareware" is a great categorization of this either.
My off-the-cuff label for this is a "Source Openly Available" license.
Also, a company offering a source available license might, as it grows, want to raise the employee and revenue thresholds (when you’re making less than a million, a million-dollar company is more of a threat to your business’s survival than when you’re making 50 million).
Edit: one more thing that would be really cool is allowing a “default alternative free software license in case this software is abandoned” clause.
If the licensor can't be bothered to provide contact information, then they aren't upholding their side of the deal, considering the purpose of the license. The licensor could always use a different license, then.
ETA: It also makes the process for getting the license cut and dry. It's easy to determine if enough work was done by the big business to contact the licensor: did they use the contact information required to be present or not?
Certainly for 2022, we could look around at how software gets made and distributed and try to spell out something more specific. In package metadata. In README. In a COMMERCIAL file. In the repo on lines with a magic string stated in the license. But for better and worse, we've learned to stay humble making assumptions about how those things will continue to happen in software development and distribution. Everything's subject to unexpected change.
In the end, we had to be conservative with this, since "breakage" in the contact method could effectively make the software permissive. Once you put software out there with license terms attached, you can't go back five years later and hunt down all the copies people have made, on the Internet and privately.
I do wonder if it could be parameterized for customization, kind of like CC-etc-etc licensing, but a bit more detailed. IOW, let's say you cross the barrier from small to big, could the resulting license effects be more gradual in that transitional zone? Just curious.
In the end, for this license and others, I think the benefit in building recognition of and standardization on a fixed set of terms outweighs the cost of "one-size-fits-all" figures. The most important potential variable, what the paid license will cost if and when you need a paid license, isn't fixed in Big Time.
For what it's worth, I also advise startups. If you find a way to reliably force startup founders in high growth to stop, think, and remember a bunch of legal things they were supposed to do two rounds ago, please e-mail me immediately!
The Big Time License certainly hasn't solved that one yet. But we did consider the problem. It's part of the motive behind the extra-long, 128-day grace period that only applies to companies that start small and grow big. That's point 1 in the "Big Business" section.
This license isn't about restrictions on usage, it's about restrictions on identity. It's deeply weird. Even stranger, despite the insistence that "fair" is a meaningful term in this license, the definition "A fair price is a fair market price for a fair commercial license." tells on itself. The clarification that it means "more than one customer not affiliated with the licensor has paid that price in the past year" at first glance seems unsatisfiable (under the license), because somebody has to be the first to pay that price, and at that point it wouldn't be "fair."
edit: In trying to ape FOSS licensing, it has confused itself. You don't have to ape FOSS.
E.g. Consider a similar legal exclusion to only people called Nguyen or Mohammed or Singh.
I have no idea how that law would apply to this license though.
> All persons within the jurisdiction of this state are free and equal, and no matter what their sex, race, color, religion, ancestry, national origin, disability, medical condition, genetic information, marital status, sexual orientation, citizenship, primary language, or immigration status are entitled to the full and equal accommodations, advantages, facilities, privileges, or services in all business establishments of every kind whatsoever.
The important part is "All persons ... are free and equal ... and are entitled to ... equal accommodations".
When you read it this way (which is how the courts read the law), the list is just illustrating some classes that might be discriminated against. It does not limit the classes merely to those listed.
As you can see from links/quotes elsewhere in this thread, the caselaw agrees with me.
Corporate status is not one of these.
[1] https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml...
> (b) All persons within the jurisdiction of this state are free and equal, and no matter what their sex, race, color, religion, ancestry, national origin, disability, medical condition, genetic information, marital status, sexual orientation, citizenship, primary language, or immigration status are entitled to the full and equal accommodations, advantages, facilities, privileges, or services in all business establishments of every kind whatsoever.
In interpreting statute, a list of things is generally assumed to be exclusive unless there are specific words that indicate it is to be treated as nonexclusive--and those words are missing here.
> [3] The nature of the 1959 amendments, the past judicial interpretation of the act, and the history of legislative action that extended the statutes' scope, indicate that identification of particular bases of discrimination--color, race, religion, ancestry, and national origin--added by the 1959 amendment, is illustrative rather than restrictive. (Stats. 1959, ch. 1866, p. 4424, § 1.) Although the legislation has been invoked primarily by persons alleging discrimination on racial grounds, its language and its history compel the conclusion that the Legislature intended to prohibit all arbitrary discrimination by business establishments. Finally, in 1961 the Legislature substituted "all persons" for "all citizens" (Stats. 1961, ch. 1187, p. 2920, § 1) in order to broaden further the section and complete the consistent pattern of wide applicability of the section. [4]
This thing is weird enough to me that I'm not sure I'd have any idea, myself, and I've spent a good deal of time understanding and reading about copyright and licenses.
AFAIU that would be perfectly legal in the USA.
Excluding blondes has a disparate impact against race.
Excluding people with a brother named Mike can be argued to have a disparate impact based on ethnicity or national origin. Excluding people with a brother named Mike but with no restrictions on the names of their sisters might be discriminating based on sex. The condition is also more likely to exclude people with larger number of siblings, which could be argued to have a disparate impact based on religion.
Excluding blondes is prohibited due to the 'protected category', which is sweeping, covering most personal characteristics which are inherent. For a role, and this broadly includes things like waitressing, these limits can be imposed, but not in this sort of general contract.
The problem with some "brother named Mike" contracts is that they're trying to get around some requirement to be general while targeting someone in particular. For most contracts you can in fact say, "anyone can use this except Anish Kapoor, because screw that guy" and that's going to hold up since refusing service or commerce outright to an individual is completely legal.
If you want to throw shade on the basis of the law, please cite law.
Re: "fair" and similar terms, see https://en.wikipedia.org/wiki/Reasonable_and_non-discriminat....
All sorts of contracts and licenses treat commercial and noncommercial use differently. Look at game engines, graphics packs, etc. All sorts of software licensed to companies have discounts for certain sizes or types of business and per-user pricing.
> You may use the software for the benefit of your [big] company:
> 1. for 128 days after your company stops qualifying under Small Business
This functions as a grace period, both for realizing that you've grown out of the "Small Business" category and to reach out and do a deal.
> 2. indefinitely, if the licensor or their legal successor does not offer a fair commercial license for the software within 32 days of written request
The definitions of "fair commercial license" and "fair price" add accountability from there. In particular, "fair price" is defined so if the vendor advertises a rack rate, and customers have actually paid it in the past year, a "fair price" means rack rate.
All of this is meant to allay the fear you mentioned: I'm small now, but if I get big, they'll gouge me. The license commits the vendor to deal fairly when that time comes.
Commonly the trick is to do something like $200/month per employee. For a small business they'll pay it, they have 2 employees who use the software a ton. For the 2,000 employee business that makes no sense, because only 5 folks use it, but licensing is based on total employees (all you can eat model). That turns it into a $40M licensing deal.
Can't there just be an upper bound that any reasonable supporting software can't exceed? Ie, can never be licensed for more than $500K per year or whatever?
The hard part here is always leaving enough flexibility to serve a lot of potential products and business plays. When the software is mass market, bound to do a lot of self-serve online sales, that's going to overwhelm any benefit from "gaming" rack rate. I'm not concerned. The prickly case is relatively niche products licensed for big dollars to relatively few customers. If your market is six big firms, so your upper bound is six total deals, you're not losing much by gaming your published figure. With six you probably don't advertise a figure, since you can tell your whole market with six sales e-mails. There might be an unhappy medium between that tiny addressable market and a mass market where both advertising pricing and gaming advertised pricing makes sense.
A lot of software shops do state a fixed per-seat, per-code, or other incremental rates. Perhaps with volume discounts. I don't think that actually hurts the license, since that tends to bound negotiations, based on publicly available evidence. But it's just as common for those pricing pages to have, say, a one-user price, a ten-user price, a fifty-user price, and "call us" for anything above that, which might still be priced by user, but might be all-you-can-eat for a flat fee. There's market segmentation, and it may not be immediately obvious which segment corresponds to the company requesting an offer. If it falls in the "call us" segment, there won't be an advertised price, so the definition of "fair price" in the terms falls back to just "a fair market price for a fair commercial license".
I follow the logic of a stated upper bound. But I'd have no idea how to set one dollar figure for every project that might use the Big Time License to reach small businesses. The temptation would be to give a lot of headroom, which could make customers nervous. Why am I looking for comfort from a $500k/year figure for this library with competitors selling $3k perpetual licenses? And from the business side, I'd never tell a software company, especially one focused on a single product, to publicly cap how big its sales can be. That could be the effect, since a big company could ask for an offer under the license, receive one, point to the definitions of "fair", and cry foul. Big hassle.
As a customer, if your software is something that I can fairly easily replace, then sure this license is not scary. If it's critical to my business, this license is the same as a "trial period" and I need to have some idea what happens at the end of the trial period so I can compare it against the alternatives (competitors, build in-house, etc).
Examples: Some random image processing library - sure, I can probably find or make alternatives. Some exotic database - probably not, too much lock-in.
The defined term "fair commercial license" only matters if you fall outside the definition of "Small Business", reach out for a paid license proposal, and don't see receive proposal you think meets the definition within 32 days. In other words, if negotiations for the license totally fail.
At that point, if the developer is dead convinced they've made proposals meeting the requirements of Big Time, and your company continues to use the software, they can sue you for infringement. Which, in all likelihood, will just result in another round of license agreement negotiations, this time with lawyers.
If you get to the point where a piece of Big Time software is worth that much to your business, even if it still counts as a "Small Business" under the terms, there's nothing to stop you reaching out to negotiate paid terms ahead of time.
In sum, both the value of the software to your business and the extent to which you're even worth pursuing in the first place will affect the way things play out in practice. FRAND-like commitment aside, compared to the traditional, closed-and-proprietary approach, the difference with Big Time is that noncommercial and small-business users can have the software for free, and everyone can see the source code.
I see some people saying it's a source available license, but there isn't anything in the license that requires the source to be available. It also doesn't grant any permissions to modify or redistribute.
As for shareware, there are several use cases where the license makes usage free. Noncommerical use. Small business use.
I think you'll be hard pressed to find any free or open license that provides any guarantee of source availability. It's just expected that the license will be applied to source code. We do see binary releases with MIT, BSD, or Apache slapped on them, here and there.
As for modification and distribution, see the Copyright License section:
> The licensor grants you a copyright license to do everything with the software that would otherwise infringe the licensor's copyright in it for any purpose allowed by these terms.
https://casetext.com/case/gaylord-v-lawler-mobile-homes-inc
Why did you choose not to disclaim the big four implied warranties that nearly all open source licenses disclaim?
Even BSD (the worst drafted license ever) explicitly disclaims two of the four (MIT and some forms of ISC get all three that realistically would apply to non-tangible property, and Apache 2.0 disclaims all four just to be safe). So it's a bit of a head-scratcher why you'd draft a license that incurs that legal risk.
Copy-paste disclaimers have grown, drip by drip, like monster stalagmites in a damp cave. Successive, nervous lawyers deposit ever more warranties by name, some more or less made up by creative opposing counsel. Having attempted to list all conceivable warranties specifically, the language opens itself up to holdings that the drafters omitted the particular warranty the judge really wants to enforce, writing off any remnant general language of disclaimer.
Big Time (and Blue Oak, and the PolyForm licenses) don't stop with the magic words "AS IS". In full, conspicuous formatting omitted:
> As far as the law allows, the software comes as is, without any warranty or condition, and the licensor will not be liable to you for any damages arising out of these terms or the use or nature of the software, under any kind of legal claim.
We can't stop courts from rendering bad decisions when they really, really want a result. But reading through Gaylord, the case you cited---admittedly, for the first time---I don't think the conclusory statement that "as is" can't apply to new goods ends our UCC 2-316(3)(a) conversation. We also have "other language which in common understanding calls the buyer's attention to the exclusion of warranties and makes plain that there is no implied warranty". Can a court really hold that Big Time software comes "with warranty", and expect to survive appeal?
There was also a tort claim in Gaylord, which did stay dead on summary judgment. I think the Big Time license gets there, too, without having to specifically mention "tort". Again, by sticking to good general language, and not undermining it with a potentially incomplete list of specifics: "any kind of legal claim".
At a higher level, there's a similar approach at work in Big Time's copyright and patent grants. Why list out all the exclusive rights of rights holders? Why risk omitting one, or putting it slightly different than in the relevant statute?
While I agree with you that "everyone is doing it" doesn't mean it's right, it also doesn't mean it's wrong.
> Successive, nervous lawyers deposit ever more warranties by name, some more or less made up by creative opposing counsel.
There are four listed explicitly in the UCC: merchantability, fitness, non-infringement, and title. Since we're dealing solely in intellectual property (and it's a license, not a sale), I'd agree that title is superfluous to non-infringement. But the other three are well-grounded in both statute and fact.
> Can a court really hold that Big Time software comes "with warranty", and expect to survive appeal?
For most OSS developers, it isn't enough to win on appeal. They don't have the kind of money to go all Google v. Oracle. We want to shape the battlefield to win on summary judgment without a jury trial.
BREAK BREAK
Please don't take this disagreement as suggesting that I don't appreciate your contribution. I think it's great to see more lawyers who are active in this space, especially one who contributes as much as you do. To the extent you're open to suggestions, mine is solely to expressly disclaim the three applicable implied warranties. Everything else in what you've done, I absolutely love. Thank you for what you do.
That (3)(a) language stands in the UCC as an explicit alternative to (2), which is where the requirements to name "merchantability" and "fitness" live. Even (2) itself provides an out for general language, when it comes to fitness:
> Language to exclude all implied warranties of fitness is sufficient if it states, for example, that "There are no warranties which extend beyond the description on the face hereof."
So it's possible to exclude fitness with general language of (2) itself, without even falling back on (3).
The idea that the UCC requires the exact words "merchantability" and "fitness" to disclaim those implied warranties is a myth. Just like the idea that the UCC requires all capital letters to make disclaimers conspicuous. If every disclaimer you've got in your form file, cribbed from different drafters, lists out the implied warranties in all capital type, you tend to gather they have to. Even if you then read 2-316, it's hard not to end up telling yourself "there must be case law out there requiring this". But if you dig up case law, you'll find courts using words like "deluded" for lawyers who think Caps Lock magically satisfies 1-201(10).
Trial court judges tend to rule so as not to be reversed. Parties tend to litigate when judges will rule for their side. If someone gets burned by a bug in free Big Time software, wants compensation, and hires a lawyer to demand for it, they end up in a conversation like the one we're having now.
You cite Grayson---or near to it as you can find in the relevant jurisdiction---and stoke legal nihilism. Those wacky courts could do anything! I cite the UCC, the language, the primacy of intent in contract construction, and the absurdity of construing terms to mean the opposite of what they plainly say. Plus the whole overarching question of whether a free transfer online to a counterparty the publisher may be wholly unaware of counts as a "sale" under the UCC.
So, what defines "unreasonable"? Maybe to Amazon, you wanting $1 is unreasonable
“Fair commercial license”? Well fair is in the eye of the beholder isn’t it? Seems like the author would need a lawyer filing a C&D 33 days after negotiations started, as the initial license cost is going to immediately be dismissed as “unfair” just as a negotiating tactic.
Licensor should be able to list pricing for the large companies upfront. Fair pricing is a troublesome term.
Licensor should be able to remove clause about government organization and classify them as big business as well.
32 days for compliance is troublesome. It would be better if this was converted to an arbitration clause that is favourable for licensor. Big companies will abuse that clause real easily.
If you would like to add some customisation, please check this first: https://docontract.com/
As the wiki says, the LGPL offers even more, but the linking exception alone might be enough for some/most projects. IANAL.
1. Do whatever you want with this code. It'd be nice to get credit but oh well.
2. I'm keeping this restricted. You pay $X for Y rights to use the software, I'll charge you more to look at the source code and limit your ability to do anything with it.
Stuff like GPL isn't going to keep bad actors from abusing your software and it can only limit the willingness of others to use it if they actually care about the terms of the license.
The problem is that... they aren't, really at all. That's the actual problem that needs fixing.
I work from home, using my personal computer for work. (I do that because (1) I have a better computer than what my employer would issue, and (2) the best place to have a computer in my house doesn't really have room for another computer).
If I would like to edit some work files, it appears I need to buy a commercial license.
That seems kind of weird to me, because the license allows small businesses to use it commercially using the free license. I can't think of any good reason that it should be OK for a business making up to $1 million/year in revenue and having up to 99 employees to use it for free, but I (who is one person and makes way less than $1 million/year) need a commercial license to occasionally use the editor commercially.
If a license is going to be free for small businesses but not free for large businesses, I'd make it so individuals can use it under the small business terms if they wish.
So why should anyone use it, if the author doesn't like it?
The rule for all these things should instead be - the pricing terms MUST be disclosed UP FRONT and PUBLICALLY - then you can pay those if you exceed a threshold. If they are not available, you will NEVER have to pay as long as you started using software and they had hidden the pricing.
That would solve 90% of these scam issues (no gotchas).
BSD || MIT || FOAD
I'm pretty sure this doesn't qualify as an "open source" license. This is a commercial license that allows free usage for certain people / companies.
In the early aughts, Microsoft used to call this concept “shared source” – not open source.