This allows monetizing those, and does it targeted to large companies who can easily afford it and would happily pay a few bucks to use the software (they would likely burn more money in a meeting discussing whether to adopt the said software or to switch to a free alternative) and I think it's a good trade-off if it allows indie open source developers to pay their bills.
On the long term those developers will generate much more open source output than when working as employees somewhere and creating only proprietary software all day and struggling to create open source only when they have some spare time a couple of hours a month.
In addition, all this licensezero software will be developed in the open, which brings many of the practical benefits of open source to a vast majority of the users, and the open source ecosystem will grow as a side effect that the developers will also create other software distributed under ordinary open source licenses. Even if just a fraction of their time would be spent on those other open source projects, that can make a huge difference to the ecosystem.
As someone who's been active in a Linux distributions license team I see such activity with a lot of skepticism. There are already FOSS licenses for pretty much every wish and many of them are redundant. License proliferation causes more incompatibilities and more work for people who have to decide whether or not something is acceptable in a FOSS environment.
If people ask me what license they should choose the number one advice I give is that they should take something more or less ordinary (Apache, MIT, GPL, CC0), avoid obscure or unclear licenses and absolutely avoid writing up new licenses.
L0-R is being revised, partly as a result of the OSI license-review process. But in general, speaking as of today, it differs from existing copyleft licenses in a few significant ways:
Reciprocity requirements trigger in even more situations than under AGPL. Use with non-OSS modifications, as a component of non-OSS, or to develop non-OSS (the most controversial) falls outside L0-R's license conditions, after a grace period. This is a big extension of AGPL's leap to triggering source provision conditions on use for remote network interaction.
Redistribution, on the other hand, is still permitted with retention or reproduction of terms and notices, a la BSD. So L0-R copyleft "hooks" into aggregated or modified _use_, instead of aggregated or modified _distribution_.
Once copyleft is triggered, L0-R is both more permissive and more strict than existing OSI-approved copyleft licensing.
On the license-terms side, L0-R permits any Open Source license terms, not just the terms of its own license, for follow-on code. That should significantly reduce intractable compatibility blocks. Essentially, it's (A)GPL-3.0 section 13 for the whole OSD roster.
On the source side, L0-R is in flux in its specific language, but aims to require source availability. Originally it was phrased in terms of "publication" of source. Current drafts fall back on the Open Source Definition, which despite itself speaks to source availability, and not just license terms.
If another license is "proliferation" in and of itself, L0-R is proliferation. But I think L0-R proliferates new ideas.
I do not agree that the current OSI-approved roster covers all bases. There is a happy collective medium somewhere between everyone having an OSD-conformant license tailored to their precise needs and preferences, and restricting the community to a very limited palette of approved forms, which is easiest on the receiving end. Open data and tooling---which I've been involved in---make it easier to identify and handle license diversity, make it a software problem. Meanwhile, licenses have fallen down addressing legal, community, and community challenges. MIT, BSD, and ISC aren't good patent licenses. Apache-2.0 isn't hacker friendly, and has its own gotchas. AGPL didn't put so much as a dent in closed-source service.
I'm trying to understand your "controversial" clause. I have doubts this is compatible with any existing definition of FOSS, but maybe I'm misunderstanding.
Does that mean everything I create with a software under that license is under the same license? To put this into a concrete example: If I have a text processor under that license - does that mean if I use it to write my emails I have to disclose my emails to anyone who is asking, because they're now under a copyleft license?
Copyright law does not work that way, even if the license says otherwise.
I'm working on Noctacam (http://noctacam.com), a camera app that uses computational photography algorithms to take better photos. I would like everyone to be able to reuse my work, without having to reinvent the wheel. But while paying me. Imagine if I released the source code, with a clause saying that its use requires a payment of money to me. Say $3 per user with a cap of $1M.
I don't want to distinguish between commercial and non, because most users of a camera app will be non-commercial, and in any case, I want everyone who benefits from my effort to pay me. Is it part of the plan to make L0 more flexible so that people who adopt it choose whether to make an exception for non-commercial use?
You should explain this. As far as I can tell from a 1st reading, so long as I'm non-commercial, I can just treat it as BSD 2 clause.
See https://opensource.org/definition :
"6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research."
"Non-commercial" clauses by definition make something not open source.
You also can't distribute it along with GPL code, at all, whereas combining BSD and GPL code is totally fine (the result is GPL).
When used appropriately (i.e. dynamic linking to unmodified Qt, or, offering source for a modified dynamically-linked Qt), the commercial company is not forced to open source anything.
Qt has an optional alternative license with a cost attached, that gives you (A) a support contract, and (B) additional rights (static linking without invoking GPL virality, private modifications, ...).
No, you can't, because if it was BSD 2-clause, you could relicense it rather freely. But you can't with this, because the commercial use limitation makes it incompatible with many licenses with which BSD 2-clause is compatible. (Including GPLv3)
Also, because you have to include the full license terms (including the requirement to secure a commercial license from the agent of the original licensor) with derived versions, well, if AD ever gets competition as a licensing agent (even from someone using a compatible pseudo-open license), downstream commercial users of software which has modules with different licensing agents face the prospect of having to secure multiple commercial license from different licensing agents to see the software.
For a non-commercial end user of only the “root” software, it similar to BSD 2-clause. For developers (even non-commercial), it's much more restrictive.
I just see the terms as creating too many unknowns about the future. Maybe I missed it, but do you have to constantly monitor all your dependencies for whether they may have just released a commercial license?
The effects of the license shouldn't vary depending on some outside input (the existence or not of a commercial license).
And the 90-day "trial" period seems both too long and too short at the same time. It's long enough to make tracking a little more difficult and too short to even make it into production from testing for many uses. (I assume the 90-days starts as soon as an org begins testing the product, not necessarily starting upon shipping.)
Free software is in the interest of the users - not in anyone else's interest. So, if you need software and if that software isn't your competitive edge, you have an incentive to cooperate with other users (as a developer or as a client of developers) and a free software license is a way to regulate that cooperation.
Criticizing free software licenses for not providing a business model is missing the point entirely.
I totally see the problems. But it's not that nothing is happening and no solutions exist. OpenSSL moved from "mostly one overworked guy with little funding" to "stable funding from multiple parties". It did so by convincing some major internet players that they need to increase the funding of software important for running the Internet. That is one way that can work. It's not the only one.
How about this for a metric for whether the system is broken or not: What's a good estimate for the monetary cost of the "convincing"? Just revoking all of the keys cost millions. I wonder what the cost of the malicious activity was?
For example?
Is that a serious question? Ok...
I heard Google pays its employers quite well. Plenty of FOSS is developed by Google, for example large parts of Chrome. I think Linus Torvalds gets a reasonable salary. So do many other kernel hackers - payed by all kinds of companies. Red Hat seems to be doing well, they have plenty of people working in all kinds of FOSS projects. I already mentioned OpenSSL. React is developed mostly by Facebook employers. I guess Facebook pays good salaries.
That doesn't scale…
No.
You might be interested in looking at "Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure" study from 2016 [1], which basically shows, that this is a very common misconception and not true at all (and why it's dangerous to continue assuming this way).
[1] https://www.fordfoundation.org/library/reports-and-studies/r...
So in order to not really be able to sustainably survive, took a decade of successful work in the commercial sphere. I fully intend to go open source with my life work, hardcore, but I am also fully aware that doing so rules out my own survival as an economic actor, and I'm trying to sort of develop an existence as a 'youtube/media personality' that'll support a poverty-level Patreon in a consistent way. That mechanism ought to keep me from actually starving or being homeless, but it's about 'being seen making or explaining stuff', not the code, no matter how brilliant or important the code is.
FOSS is NOT about making even the poorest living, and never will be. FOSS is about the vocabulary of thought. Broadening the vocabulary of thought is crucially important to the world, and completely orthoganal to being an economic actor. To devote yourself to it means starving or burning through your resources until you're starving, and being left with nothing.
This is important to understand, because it's solvable. If creativity and FOSS is anti-money but hugely beneficial to the world, we simply need to unlink survival from money, and conclude that whatever money represents, it's not merit.
You'd be surprised. Even extremely popular projects are severely underfunded, to the point of begging for money, while being used left and right by huge enterprises...
>I totally see the problems. But it's not that nothing is happening and no solutions exist. OpenSSL moved from "mostly one overworked guy with little funding" to "stable funding from multiple parties". It did so by convincing some major internet players that they need to increase the funding of software important for running the Internet.
If it has to come to that -- convincing Facebook, Google, IBM, whoever etc --, surely there's something problematic?