> As an Open Source developer, you build a new cool library or a tool and license it under AGPL. This preserves all the Free Software freedoms for all the non-commercial users out there. You don't have to compromise on it. Debian and Brew can still ship them. Then you go to one or more FOSS Collectives and sign a licensing deal (if they find your project worthwhile). From now on the Collective can license it to commercial organizations that don't want to touch AGPL stuff, and pay you a cut!
Isn't dual licensing already somewhat popular? To me it seems like what's being proposed is a lot like a SaaS solution for handling the unpleasant legalese-heavy aspects of licensing software, but with some sort of a community weight behind it, or maybe i'm misreading this?
If nothing else, it's curious to see all sorts of attempts at new licensing schemes show up, even though some (like SSPL https://en.wikipedia.org/wiki/Server_Side_Public_License) are really controversial. I guess eventually we'll see what works and what doesn't, i just hope that the people who need to be compensated for their work to keep contributing will find ways to do that, with it hopefully being normalized enough by then.
I'm not sure whether that's open source, though - more like conditional open source, that only applies to other open source or non-commercial projects, but requires investment for commercial entities. A bit like "source available" for them, in this case - you can still view the code and maybe try it out in an internal prototype, but will have to get a license to actually use it.
As someone who receives about 20-30k euros a year (dayjob as a dev in Eastern Europe, though it's been pointed out to me that i should strive for more), additional income in any form, be it freelancing, bug bounties or even something like this seems like a nice idea!
> Isn't dual licensing already somewhat popular? To me it seems like what's being proposed is a lot like a SaaS solution for handling the unpleasant legalese-heavy aspects of licensing software, but with some sort of a community weight behind it, or maybe i'm misreading this?
It's more than that. No sane company would pay for `colors` node package, because it would be such a burden compared to how such a ridiculously small part of their project. For the company to go through that legalese would cost more than recreating that package themselves.
The idea is that this company simply pays the NPM Foundation, and gets commercial licensing access to all packages in NPM with one single contract, and then NPM Foundation redistribute. (I'm saying NPM just as an example)
Though why couldn't we have something like "npm fund", maybe "npm license --commercial", which would just give a summary of everything that you have to pay for in the list of current project dependencies, if you want to use the packages for commercial use?
Just curious about the pros and cons of solving this at the package manager level, since handling licensing there would probably be easier, than creating external orgs for that? Who knows, maybe just a Stripe integration with the particular company behind distributing the funds down the line would be sufficient, maybe with package.license that could be the equivalent for package.lock within the projects being generated then?
For example, if you look at the Unity game engine, they have their own Unity Asset Store, which is tightly integrated with the rest of the platform and actually makes commercial packages viable, since everything is so easy to do! So much so, that in the game development community, "asset flip" has become a term to describe a surprisingly common (yet detrimental) approach to development, where someone makes a game almost entirely out of these packages and tries to sell it.
With how most of the web development (and other types too) projects, both front end (Angular, Vue, React, Svelte etc.) and back end (Spring, Django, Rails, Laravel, ASP.NET Core etc.) rely on bunches of external dependencies, i fail to see why things should be any different there.
I'm working on a solution that is along the lines of the "package.lock" method that you've mentioned. My solution involves defining payment plans in code:
To be clear, the SSPL and similar fauxpen source licenses are unambiguously not free or open source. The controversy comes from some people not considering that to be a problem.
> The controversy comes from some people not considering that to be a problem.
I can't find the link to conversations I had both here and on reddit about this, but it comes also from people that think that the Free Software Foundation and the Open Source Initiative should have no say in the definitions of Free Software and Open Source respectively.
Open source licenses aren't entirely viable when you're a company that wants to exist and not have your product and market be stolen by giants that have no problem throwing their weight around like that.
> The controversy comes from some people not considering that to be a problem.
I disagree with this way of framing it, however. In my eyes, the controversy is from the fact that the license itself is essentially "the nuclear option":
> 13. Offering the Program as a Service.
> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
If there is a company out there that offered MongoDB as a service, new versions suddenly become non viable, thus killing the entire company unless they pivot to something else, in lieu of them being forced to publish almost ALL of their source code, which may or may not lead to their competitors just stealing it, unless it would be licensed under SSPL as well (then again, who's to say that they wouldn't ignore it, since the small company probably wouldn't have the resources to pursue all that much litigation).
I doubt people care much about what is or isn't truly free or open source software as far as fitting some definition or set of ideals goes, much like very few people care what codecs are used to record videos that they might end up in, short of Mr Stallman himself. Hence, in my eyes, the actual controversy lies elsewhere, how this license goes way beyond what GPL forces you to do to comply with it.
I'm not sure whether MongoDB or Elastic Search will be around in 10 years, since this severely limits how competitive hosting providers can be out there, unless they build their stuff with the intent of publishing all of their source (and possibly getting breached numerous times due to all of their flaws being openly on display now) from day 1.
Isn't dual licensing already somewhat popular? To me it seems like what's being proposed is a lot like a SaaS solution for handling the unpleasant legalese-heavy aspects of licensing software, but with some sort of a community weight behind it, or maybe i'm misreading this?
If nothing else, it's curious to see all sorts of attempts at new licensing schemes show up, even though some (like SSPL https://en.wikipedia.org/wiki/Server_Side_Public_License) are really controversial. I guess eventually we'll see what works and what doesn't, i just hope that the people who need to be compensated for their work to keep contributing will find ways to do that, with it hopefully being normalized enough by then.
I'm not sure whether that's open source, though - more like conditional open source, that only applies to other open source or non-commercial projects, but requires investment for commercial entities. A bit like "source available" for them, in this case - you can still view the code and maybe try it out in an internal prototype, but will have to get a license to actually use it.
Then again, i don't really think of it as a bad thing and it might be a decent solution to the problem of "Software below the poverty line": https://staltz.com/software-below-the-poverty-line.html
As someone who receives about 20-30k euros a year (dayjob as a dev in Eastern Europe, though it's been pointed out to me that i should strive for more), additional income in any form, be it freelancing, bug bounties or even something like this seems like a nice idea!