I always interpret new licenses through the lens of Debian's Free Software Guidelines.[0] I don't think this would be accepted as it limits usage.
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.
I think we need to be much more willing to consider software that's released with source available, but under a license that doesn't comply with the DFSG. (And yes, such software should be called something other than "open source".) Those guidelines aren't sacred, and neither is Stallman's definition of free software.
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 think we need to be much more willing to consider software that's released with source available, but under a license that doesn't comply with the DFSG.
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.
MongoDB was licensed under AGPL – not a permissive license – when AWS started free loading on them. Copyleft licenses have shown themselves to be no panacea when it comes to exploitation from the multi-billion-dollar companies. If Free Software can't feed its developers, they will look for food elsewhere.
Copyleft licenses are an improvement. They do not universally force payment in every case where a proprietary license could, but on the other hand, would MongoDB have become as popular in the first place if it wasn't FOSS?
(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.
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."
] 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.
I agree entirely, and I do think it's important to only be required to give source to those you give binaries to. I just didn't want to nitpick that particular distinction here.
> FOSS has always and only ever asked for giving back code, not money.
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)?
Does that happen though? log4j developers were working overtime to fix the security bug [1], while corporation expected them to release the fix ASAP for free. Who was paying?
As far as I am aware, AWS never used any of MongoDBs source code. They implemented the MongoDB API. The license is thus irrelevant. AWS could have implemented the Mongo API no matter what sort of license it was under- it could have been entirely closed source.
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.
Sorry, I did some duck searching, maybe I am misremembering, but I can't find any evidence that AWS ever used MongoDB or offered it as a service directly?
> 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".
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.
I think we're mostly in agreement here. I was suggesting that FOSS itself was a counterculture (compared to proprietary software), and I was loosely describing the resentful "I don't want to think about licenses" (or moreso mocking people who care about licenses) as a conter-counterculture to that. I think that plays directly into the promotion of permissive licensing.
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.
> 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 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.
Something can be a Schelling point or a game-theoretic focal point even if it wasn't originally developed through widely collaborated-on consensus. The DFSG and the Open Source Definition are a Schelling point now, because there is now much more consensus on maintaining that specific line than there is on any particular approach to bending it; if we lose that focal point, we will have a hard time establishing a new one, especially if we haven't already established a specific standard or amendment beforehand.
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 think we need to be much more willing to consider software that's released with source available"
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.
Source-only / source-available is great way to make a living. It also makes whoever purchases your software life easier.
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.
In most cases - source available is _de facto_ open-source.
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.
I disagree. I consider practical limitations and legal limitations to be not be a subset of the other. They are separate, and the respective freedoms are both important.
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?
Source available doesn't mean that you can't do anything with the code, it usually means that there are limitations (e.g. sharing it) with what you can do with it.
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).
OK, so the reason you are interested in this is for the ability to write, share and use patches that can be used by those who pay for a license to the code, to be able to add features without having to rely/wait for the vendor to do so?
Yes, while it is certainly worse than full Free Software from a community perspective, it is still much better than closed source commercial software since you are at least in control - even if the developer shuts down or abandons the project, you are still able to fix bugs and improve the program (you or anyone else who decides to distribute patches - assuming the license doesn't explicitly forbid that, but it'd be pointless to do that IMO, not that some didn't try it). And if you ever decide to move somewhere else, you can still get your data out of the program (modify it to dump to another format or just use the code to make your own converter) so you're not locked in either.
"Source available" was also common in earlier Unix systems, e.g. an once popular image viewer called "xv" was basically a shareware program distributed as source code. People even wrote patches for it.
The problem with absolutism: it ignores how trivial it is to copy and deploy a lot of modern programs. Condemning licenses which protect against juggernauts like Amazon leaves no middle ground between free software and proprietary software.
Purely for practical reasons, I tend strongly toward using FOSS in all companies I've worked for. Ideology aside, if the authors go out of business or drop support, I can still support it myself (or pay someone too). From that position, I don't see a lot of middle ground between FOSS and proprietary: either it's FOSS or it's not. I don't mean that harshly, and it's not as though I flat-out wouldn't use proprietary software. I certainly wouldn't judge others who do. It's just that I see non-FOSS software as a significant risk that has to be mitigated, perhaps by limiting its use to cases where it'd be inconvenient if it went away, as opposed to a company-ending event.
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!
> Ideology aside, if the authors go out of business or drop support, I can still support it myself (or pay someone too).
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?
> 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.
Yeah, having the code become permissively licensed if the original developer goes out of business seems like a good compromise.
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 get it. I do. It's just that, for me personally, this isn't any better than say a Microsoft license. Years ago, I would've described it as shareware. In fact, I still might.
Steven Levy is writing what I would consider historical fiction, but let's pretend his story is true. Context matters.
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.
That post is a word salad of unsubstantiated vague name-calling.
> 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.
Many of the most useful open source projects are corporate driven. The only thing holding those companies to the usual set of licenses and provisions rather than something that would be much less open is the Schelling fence of the “open source” definition. Throw the door open to a thousand different idiosyncratic licenses and they too will abandon Apache, BSD, and MIT.
The reasons corporations lead open source projects is to undercut their (potential) competitors by commoditising their complements. OSI licenses are used in such projects because they allow the businesses to achieve the above.
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]
Seems like a strange attack against (eg) GPL. Stallman is completely odd, but GPL's aim has nothing to do with developers and everything to do with users: Let users know and control the software they're running on their computers. This is a real world issue, even if you don't think you need it.
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.
The way I see it, Stallman is an end user freedom maximalist with end user roughly meaning person sitting in front of a computer using software. Thinking like this, any obstacle blocking a user from complete control of the computation on the computer is evil.
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.
Are you claiming those lawyers are pulling problems out of their [..], or do you accept that there might be very real reasons for embargoing GPL, especially with many lawyers from many companies doing that?
I'm saying there's already a very obvious, decades-old established solution to the problem the parent commenter is raising. It's just an unpopular solution with devs on this board, because they actually want to be able to keep ~~freeloading~~ er, re-using community contributions at their well-paid jobs.
Although I know of many small businesses that would be very happy with $1M pa, there does seem to be an imbalance with the number of employees. You simply can't pay 100 people a salary and stay under $1M. Maybe 12 people, or $10M would be a better balance.
> You simply can't pay 100 people a salary and stay under $1M. Maybe 12 people, or $10M would be a better balance.
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.
Nope, one million is 10k a year per employee. That’s low even in Poland and definitely well, well below Polish IT, and Europe in general makes a fraction of SV salaries.
The license doesn't say 100 full-time employee positions throughout the year. It says anyone who's been an employee or contractor during any part of the year. Did I pay someone $200 for an hour of consulting? That counts. Did I have an unpaid intern for 120 hours of work? That counts. Did I hire a bunch of work done somewhere else in the world for $5 an hour? Each of those people count. Did I pay a receptionist to man an office 20 hours a week at minimum wage? That counts.
But the business will have other expenses besides salary (rent on a building, providing developers with machines, etc), so you would be down to 7k USD per year or lower for an 100-employee company to break even with only $1M/year revenue.
Employees cost more than just their salaries. I doubt there's any software-based business anywhere in the US with more than ~6-8 employees on $1m revenue.
$1M is $10k per employee, which is (in the USA) below the federal poverty line (i.e. not inflated SV numbers) of $12,880. Just working full time (≥35 hours a week) at the federal minimum wage ($7.25/hour) puts you over $13k.
I think all of us (including me) have been misreading that term. The term reads:
> 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.
In my eyes, this prevents you from hiring 1000 people on Fiverr to each write one function for $100.
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.)
You certainly can if you're taking VC money hand-over-fist (though that's captured in the $1MM investment clause). I see that provision in the license as preventing VC-backed startups from ducking paying for software while they're still achieving product-market fit.
Like most definitions in legal terms, the definition of "small business" in the license is functional and context-specific. It needn't be a good dictionary definition of "small business" for use elsewhere.
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.
People are just questioning it because it seems like one of the 'tripwires' is a significantly higher barrier.
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.
The choice between revenue and profit was well considered. Revenue does not account for expenses. But neither does it yield to Hollywood Accounting and the like.
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.
Perhaps, but what’s the point of discussing non-open source licenses here? Yet Another Commercial License isn’t interesting, even one that basically works out to be shareware.
Because lots of people here run commercial software businesses (our original name was "Startup News"). We discuss this for the same reason we discuss pricing pages and user metrics.
Interesting articles about yet another commercial license are per se on topic for HN.
Given that this is a website run by a startup accelerator, articles about commercial licenses are arguably more on topic than ones about open source licenses. Successful commercial products with GPLed code are few and far in between.
Linux, MariaDB, SourceFire, WordPress, Ansible, just off the top of my head.
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's not that I thought it was off-topic, just that it seemed unusual to me. What's more common is when an existing product changes its license, and then HN is all over discussing the implications.
> Perhaps, but what’s the point of discussing non-open source licenses here?
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.
You could have 100 part-time employees and contractors and be under $1M total revenue. Not common, but some kind of tutoring agency maybe.
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.
How's that my problem? I don't owe you a profit! More, we don't owe you anything, the obligation at best runs the other direction.
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.
Not to mention in companies that just acquire other companies, the parent company has a lot of revenue, but the sub-companies can be chronically cash-strapped. In big companies (and conglomerates) any given product does not draw from the total financial resources of the entire organization and its various revenue streams. A single megacorp product can have a 250K budget and generate 500K revenue, but they're not gonna get any more money for their product development just because the megacorp makes more money outside that product. And that revenue is probably just gonna get stolen by the megacorp to use somewhere else, the money doesn't go back into improving the first product.
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.
I think someone wanting to use this licence may take a view of "megacorps should pay for my work regardless of their sub-company internal wooden-dollars accounting, so they shouldn't get out of using my open source efforts to make their rich stakeholders richer, although I don't mind helping some small indie team kickstart their business (and if they end up growing big, they will pay me anyway!)."
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.
Interesting to contrast with this is the EU's definitions of small and medium enterprises.
https://ec.europa.eu/growth/smes/sme-definition_en
A headcount lower than 50, turnover or balance sheet under 10 million qualifies you as a small business.
I really like this license, but this stuck out to me too. The thresholds are wide apart, and like you say, easy to cross when still "poor".
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.)
It does actually account for inflation, at least for US users:
> 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/).
The amounts are in US dollars, so any local hyperinflation won't matter. Your local currency will be worth far fewer dollars.
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.
> 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.
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.
That's what jumped out at me as well. If you have 99 full time employees and $999,999.00 in total revenue, you are violating labor laws somewhere, guaranteed.
I like Mr Mitchell, and I am glad that he is attempting to do something that so many people shy away from for obvious reasons. As a developer of a fairly popular open-source tool (Aether), I have an interest in following the software licensing discussion in detail, though I am not a lawyer.
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.
"Fair" is the first part of "fair, reasonable, and nondiscriminatory", or "FRAND", a stock phrase lawyers reuse especially in policies about how companies contributing to standard setting will license any of their patents they manage to get into the standards. We have seen litigation about what FRAND means in context. You can read all about that on Wikipedia. But business has not stood still waiting on courts---or draftsmen---for perfect clarity. That's not how law works.
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.
Hi Kyle, thanks for responding to criticism. I think you might have slightly misunderstood my main objection and comment. Your machinery is all fine and well but it requires negotiation, murky legal definitions (even if it is clearer than the usual FRAND clauses) that potentially need an adversarial process to resolve.
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.
FRAND defines fair in a very specific way in terms of pricing. For example the definition of F (fair) in FRAND is exemplified as not requiring purchase of other, unwanted licenses as a condition to the purchase of the particular license the customer wants to buy. However that does not exactly seem to be the use in this license because here it seems like fair would also carry the meaning of 'not too expensive', as I interpret the author's explanation:
> ' 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.
FRAND isn't a definition. As far as I'm aware, it didn't even really begin as a concept from statute. It's a kind of catchphrase lawyers reuse in policies, bylaws, contracts, and other terms.
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...
I understand, however, consider that being good for patent policies between multinational Fortune 500s does not in any way imply that it is good for anything else. In the case of two F500s with their respective lawyer armies, they are evenly matched, they're equals. Thus a licence can work even if murky because either side can make it very painful for the other to make it not work. It's a repeated prisoner's dilemma case.
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...
Ah, my apologies, it wasn't obvious from the second site how to get to the actual paper. I think this is fair to say there are ways that attempt to be objective in defining what is fair licensing cost, but I'd have liked to see one of these methods explicitly mentioned in the license so as to not have this question left open as a landmine.
Kyle's a fried of mine, so I may be a bit biased. But I'm very sympathetic to this kind of license, and fairness is really hard to define, especially in advance. He's actually written separately [1] about exactly how difficult it is.
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.
There’s some self contradiction right there since by adopting this license the licensor is explicitly advertising a generally available commercial license for companies making < $1m priced at $0.00.
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’.
I'm struggling to understand the vitriol toward this. It is a thoughtfully-crafted license, eminently readable, written by a skilled legal practitioner in this domain. I have no affiliation with the author of the license, but do appreciate his writings and contributions to the community.
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?
I'm struggling to understand the vitriol toward this. It is a thoughtfully-crafted license, eminently readable, written by a skilled legal practitioner in this domain.
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.
> 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.
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.
But why the assumption that it is aimed at FOSS advocates? The license doesn't even mention source code, it has nothing to do with FOSS. Does FOSS has a monopoly on releasing software free of cost? Should no new interesting shareware-esque licenses be shared on a website dedicated to startups, lest the FOSS advocates be offended?
The pairing of 100 people and $1M revenue seems off by a factor of 10, unless the author intends that the latter limit will almost always be hit first? For example, in the US, a company with 100 people would be ~$2M in payroll+taxes alone if it paid federal minimum wage.
It doesn't say 100 full-time equivalent positions for the full year. It says any 100 individuals employed directly or as contractors at any point in the year. Pay someone on Fiverr or Craigslist $50 for a logo? That's a contractor. Have someone on commission-only outside sales for two weeks who didn't bring in any revenue? That's an employee or maybe a contractor.
I really like the concept behind this and the Polyform licenses, but wish there could be more modularization to allow, for example, permissiveness for small businesses but removing allowances for large “non-profit” orgs.
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.
One suggestion I have is to update the "How to Request" section, which lays out a procedure for asking for a commercial license. It'd be simpler if the license terms require the licensor to provide contact information for commercial licenses in a defined location. That would help "guarantee[] ... paid licenses for big business are available on fair terms"; there's some consideration in this license for the rights of the big business here.
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?
I appreciate this feedback. Maybe it won't surprise to read we definitely thought about this!
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.
That's a really cool idea in a lot of ways, thanks for sharing it.
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.
Kyle E. Mitchell (the author of this license) was also part of another team of lawyers who created the Polyform Licenses[1] which AFAIK is supposed to be the modular alternative[2].
Parameterization, modularization, and the like have big hacker appeal. As a coder, I feel that, too. But our lived experience applying them to license terms has been rough. The Fair Source License. Ongoing confusion about what "Creative Commons license" means, and the fact that there is more than one of them. The Cambrian explosion of small tweaks to MIT and BSD terms.
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.
seems like the springing requirement to negotiate a paid license after $1m in revenue is just destined to be forgotten. it will come up two rounds later in diligence and be a minor pain to deal with. I'd probably avoid using something licensed under this just to avoid the headache later. or would prefer to pay for a commercial license upfront even.
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.
I can't imagine that this would hold up in court. You might as well exclude blondes or people with a brother named "Mike." Just make it explicitly proprietary and give out free licenses to the people who meet your criteria. Or equivalently to this, include a promise in the licensing that you won't pursue license violations against people who meet X, Y, and Z criteria.
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.
I'm a bit uneasy about some things in this license (including the "fair" bit), but I doubt there's any legal problem with discriminating licensees based on revenue or head count. (Disclaimer: IANAL, etc.) Microsoft already does this with Visual Studio licensing -- the free "community" license explicitly restricts on both critiera:
Will courts enforce Creative Commons NonCommercial licenses? How about educational-use-only terms, often discounted? Software companies that sell downloads and licenses self-serve, with differential pricing for customers in poorer countries?
If you want to throw shade on the basis of the law, please cite law.
I'm a friend of the author, as well as friends with (former) employees at some of his clients. I can vouch not just that he's a lawyer, but also that he has experience in the space. _A lot_ of experience in the space.
Why would it be legally invalid to exclude blondes or people with a brother named "Mike"? (Obviously it would be immoral and stupid, but that doesn't make such an exclusion legally unenforceable.)
California has the Unruh Civil Rights Act that applies to all commercial public accommodations which basically says "categorical discrimination of any kind is illegal". Saying "I won't do business with anyone named Mike" or putting up a "No blondes" sign is categorical discrimination.
I have no idea how that law would apply to this license though.
I don't see a single word in the operative part that suggests that the list is an inclusive list:
> (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.
> The California Supreme Court has repeatedly "interpreted the [law] as protecting classes other than those listed on its face".[6] For example, even prior to the 2005 addition of sexual orientation to the law's list of covered classes, the Unruh Act had been "construed as protecting gays and lesbians from arbitrary discrimination",[6] such as in the case of Rolon v. Kulwitzky.[7]
> [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]
But I don't think people with a brother named Mike are a protected class according to the Unruh Civil Rights Act. Those are sex, race, color, religion, ancestry, national origin, disability, medical condition, genetic information, marital status, sexual orientation, citizenship, primary language, or immigration status.
> 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.
The alternative to my interpretation is "because there is a list, nothing not on that list is a protected class". That interpretation omits the parts of the sentence I highlighted as much as I omitted the list.
As you can see from links/quotes elsewhere in this thread, the caselaw agrees with me.
Both of those are bad analogies for different reasons. I will limit myself to US law out of familiarity.
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.
This question has been a) tried with some success against natural and locced hair in the US, and I wouldn't want to be a defendant in the no blondes case, and b) no. totally irrelevant. Hence I was saying it's a bad analogy, rather than a good one.
Are you a lawyer or have specific knowledge in this area?
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.
Usage in a commercial context is different from usage in a noncommercial context. This has nothing to do with indelible personal traits. It has to do with whether users can take advantage of certain terms of the license base on how they organize themselves and to what use they are putting the software.
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 can't discriminate based on membership of protected classes, and the doctrine of "disparate impact" means you can't have an imbalanced impact against a protected class (even if unintentional!), unless there's a reasonable business case.
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.
This is an interesting concept, but I'm not sure I would use software like this in my small business unless the software owner made some sort of price commitment up front. Otherwise, several years down the road, I'm hit with the bill - and the owner could charge me anything they want. I'm already dependent on the software.
> 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.
We see this type of deal in real estate financing. These terms often drive the
"rack rate" way up even if that is a net negative for licensor. They just need a few suckers to pay that rack rate, and that locks in something very high.
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?
Thanks so much for this comment. You've got me thinking. My mind certainly hadn't gone to real estate on this.
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.
I'm just saying that as a consumer of software, I am wary of subjective terms like "fair" that I can't afford to litigate. Yeah, pricing software is hard and of course the seller wants to tailor each deal to the customer... but if the customer is already dependent on the software, the power relationship is lopsided.
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.
"Fair" can express an intuition, in addition to objective standards. Which is why Big Time adds both context and definitions to flesh it out. A bitter dispute about those terms could result in litigation. But the overwhelming majority of contract disputes don't go to court. Sides figure things out based on estimates of their odds in court.
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.
So... it's a shareware license that doesn't require you to be a lawyer to understand.
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.
I'm glad you found it understandable! That is a major goal.
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.
The general consensus is that AS IS isn't enough to protect you against implied warranties, because - despite the language of the UCC - some courts are freaking idiots.
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.
I don't agree that view is conscious consensus. It's the track of the herd, perpetuated by copy-and-paste.
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?
> It's the track of the herd, perpetuated by copy-and-paste.
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.
Merchantability, fitness, non-infringement, and title are indeed creatures of the UCC. We've got them covered under 2-316(3)(a) by way of "as is", and if courts strain like Alabama, "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".
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.
"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."
So, what defines "unreasonable"? Maybe to Amazon, you wanting $1 is unreasonable
Everyone is jumping on the definition of a “small business”, but the thing that stood out to me was the clause “[license for commercial use is good] indefinitely, if the licensor or their legal successor does not offer a fair commercial license for the software within 32 days of written request”
“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.
I'm not aware that any of the words used in Big Time are legal terms of art with particularly specific, legal meanings. There is a developing body of case law around FRAND---fair, reasonable, and nondiscriminatory---which directly inspired Big Time. But it's not as though there is a separate dictionary of legal meanings for common words that courts use. Rather, they have rules for how to read to find the meaning two sides likely meant in context. Some of those rules involve looking at general dictionary definitions.
This license has things in common with the Unreal Engine license. It's a source available license that is free up until a certain revenue (or equity / headcount) amount
We see a lot more licensing practices between the extremes of permissive-open and completely locked down in video games. There is a lot more professional cross-pollination there with music, film, TV, books, and other "copyright industries" with much longer histories.
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/
Surely if you do advertise a price that goes to what the fair price is. If I advertise it's $5000 and decide I don't like your business so I'm going to charge you $50,000 that's not fair or nondiscriminatory.
I'd like to see a AGPL+linking exception (LGPL) license personally. Though I think license proliferation is generally good and people are free to choose the license they want for their particular works.
After decades of writing software, I've come to the conclusion there are pretty much only two useful licenses:
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.
I've got a source code copy of Kusari that says the GPL does work. We live in a society, most people aren't bad actors to the extent that they'll outright break the law.
Let's say there was a text editor available under this license, and I as an individual obtained a copy for my personal use on my hobby projects. That's free.
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.
I wonder if worker-owned cooperatives would be compatible with this, as the charter could be written so as to define no one as a worker, but rather as sharing ownership and receiving shares, rather than monetary payment.
Because summaries are hard, and it's perfectly reasonable to be happy with the actual terms and still think that the statement of purpose could be better along any of a number of axes (clarity, concision, etc)
With these not-very-open-source licenses I'm glad when they give them names that are easy to filter out. "Shared" and "Business" are good terms to filter on, but it seems "Public License" is one as well. If it says "Public License" I know I'm not going to like it, whether it's an OSI-approved ones like the GPL, EPL, MPL, LGPL, AGPL, or this one which isn't OSI-approved and doesn't meet the OSD.
The phrase "public license" generally means that it's a license for everyone, all comers, as distinct from a private license for a specific customer or counterparty. I would describe all the licenses on Blue Oak's permissive license list (https://blueoakcouncil.org/list) as "public licenses". Except perhaps for some of the truly defective ones rated "lead'.
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).
I shared this one since it was actually drafted by a lawyer, and they explain the various parts of the license and the though-process behind it which I found interesting.
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.
[0] https://people.debian.org/~bap/dfsg-faq.html