I think it would be very difficult to produce the “collective.” Nice idea though.
I have been considering, in new books and new editions to books I have written, to change the license for the book examples to AGPL, but for people who purchase a book, they get a commercial use license. I make all my recent eBooks available as a free download, or people can pay. I use the statistics of which books more people pay for to guide how much writing effort I put into different topics. On average I get about 50 downloads for each paid for book. I have been happy with this process.
What is changing is that as I approach my 71 birthday, I am getting pressure from family and friends who retired a long time ago for more of my time, and as much as I love working, I will probably “retire” from paid work in the next year or two. I think that making writing my “job” again might be a good way to still enjoy staying current with deep learning and AI in general, and also earn a little money from doing so.
I do worry that the dual licensing approach might turn off some readers, so I think I will try out this plan with a new book and see how it works.
EDIT: might be of interest: by far my most paid for book is my Common Lisp book, followed by my Haskell and Hy (Python Lisp) books. Those books are scheduled to get new editions. Since almost all of my work in the last 7 years has been deep learning based, my next planned new book is a practitioners guide to DL, from my personal perspective.
> I do worry that the dual licensing approach might turn off some readers
I've not read any of your books (I tend to first look on O'Reilly Learning when I need a book on a given topic, and so far when I've needed a book on a topic you have written on I've found a satisfactory book there) so maybe it will be different for your readers, but that approach would definitely turn me off.
I buy (or read via a subscription service like O'Reilly) books to learn, not to obtain a code library. If I learn something from the book, even if that happens to be in the form of code, I want to be able to treat it the same way as I do things I learned from my college textbooks.
I don't want to have to be remembering that this thing I learned from that book can't be used on these projects because I don't have the right kind of license.
I'd be OK with it if the code that is actually in the text of the book is public domain or under a permissive license and the author includes a link to download more extensive code that is not under such a license, as long as the code in the text of the book is sufficient for learning the material the book purports to teach.
> I don't want to have to be remembering that this thing I learned from that book can't be used on these projects because I don't have the right kind of license.
You don't have to. "This thing you remember" is an idea, and ideas are not subject to copyright, only expressions. Unless you're copy-pasting something out of a book this is a literal non-issue... and if you are in fact copy-pasting then frankly you deserve it since copy-pasting is the nadir of engineering practice. It is literally you turning your brain off and ingesting someone else's mistakes. Don't do that. Textbooks are for learning ideas, not lifting code.
I have 3 colleagues in their early 70s, we develop silicons for AI and DL. One is the tech leader, another one is algorithm/compiler, the last one doing FPGA. I asked one of them about the retirement, the answer is: "tried that, too boring"
> change the license for the book examples to AGPL, but for people who purchase a book, they get a commercial use license
I love this idea.
Would you sell it as "Buy Book (includes bonus commercial use license)" or "Buy Commercial License (includes bonus printed book)" or both? Might make a difference for organizational programmers trying to expense the purchase.
Speak of organizational customers... how would you make that work? Each book grants a license to one dev, allowing derivative works to be relicensed once?
N.B.: IAAL but IANAIPL and IANYL. Please don't take anything I say as endorsing any particular course of action.
This sounds like a very viable option, especially if you make it easy for someone to expense the copy of the book. I don't see how adding an option can really annoy the existing readers too much; perhaps you could make it MIT licensed for purchasers?
You may also want to consider the legacy - many wonderful texts and code has been lost to time because the author passed on and the heirs didn't bother continuing to maintain/make it available, and without being able to contact someone, nothing can be done. Perhaps an "abandonware clause" that X years after publication the code can be considered BSD licensed?
I combine licenses in a weird manner to try and get some honest result:
- On the low level more generic tooling I use ALGPL, so a mix of AGLP and LGPL, you can think of it as LGPL but you cannot modify it without sharing the source if you make money off of hosting a service which uses the software (Amazon f.ex. would need to share source if they used it in a paying server product).
- On the higher level multiplayer layer I mix MIT and a flat out commercial license: So if you are using the system for fun you have MIT but if you want to charge for the product you need to pay monthly in proportion to your company stuctures yearly revenue.
I don't know if this is going to work eventually if anyone begins to care about the stack because of the MMO I'm trying to build to gather interest, but we'll see!
As for gathering the payments, I think github has a big role to play by adding optional global VAT (and paying it automatically) to the sponsorship tiers (just add a commercial license checkbox) so that programmers can focus on programming without too much bureaucratic distraction. Itch.io has that but they lack recurring payments, so this is a callout for a feature that today needs alot of cumbersome work: recurring payments with automatic VAT! (I have allready talked to both github and itch)
How can you ensure (say, legally) that people using the system for fun can use the MIT version, while people charging for the product must use the commercial one? I mean, the MIT license explicitly allows for people to take your code and use it for whatever purpose. Including repackaging it and charging money for it, without even needing to release the source code of any changes or the resulting work.
> Permission is hereby granted, *free of charge*, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software *without restriction*, including *without limitation* the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software
Emphasis mine.
I'm not a lawyer, but are you sure your words can contradict another right you specifically gave with that license?
That's why you use dual licensing; if you clearly state that you want the software to use MIT without money involved but something else if money is involved that is generally not a problem, never has been, and never will be: because it makes sense, it's fair and honest!
You want a MIT license (that is by definition without restrictions), but you want to add the "without money restriction". It doesn't work like that. Once you add a restriction of "without money involved" to the MIT license, it is not the MIT license anymore.
I'm pretty sure your text doesn't do what you think it does. Dual-licensing means that there are two licenses and the user can choose which one to use. The GPL + commercial combo works because there are reasons why commercial entities would want to avoid GPL licenses. Mainly, to not have to release whatever they are building as GPL too. So when you give a choice of GPL 'BUT also' commercial, there will be people who will opt for commercial to build their closed-source application.
However, if you give an MIT + commercial combo, there is no reason why one should opt for the commercial one. Unless your commercial license includes some SLA agreement or something as a carrot.
You seem to think that you can enforce use cases for the MIT license, which is not really the case. If you attach conditions to your MIT license, it is not MIT anymore. Neither is it open source.
Not everything has to be open source though. I think something like the Fair Source license [0] aligns with your intent better.
Sure this might be the case but still adopting a fair.io license is not going to improve things when the simplest way is just to write down in english words what you mean.
Courts will argue about the legality long after I'm dead but for me right now this is an agreement I propose, if you want to see it in your own way go ahead, I'm not going to sue you; but history will look at your existence in a bad way how ever you squirm from the fact that I'm saying: "Use this for free with MIT _OR_ if you want to make money, share some of it." - You can't get away from that...
This is my last answer to these "but MIT is free", "ALGPL does not exist" kind of comments, nothing exists except your conscience... do what you want!
What if I adapt your code under MIT and distribute it. Can someone else then use it commercially? Or do they pay you? Or me? The answer is your license either isn't open source or it is easy to bypass.
Dual license copy left on the other hand works because the stipulations and restrictions are compatible, i.e. not overlapping.
Is it obvious? court cases have a way of exposing the edge cases of 'plain english', as well as a general tendency to interpret ambiguity against whoever happens to benefit from it. Lawyers would tend to describe what you're doing as a 'crayon license', and it's often an apt description. I would not like to wind up in court over this license, on either side, and I will as a general rule avoid them.
I get your point. I get involved in these discussions because I am not really satisfied with the current status quo. I want OS creators to have their cake and eat it too. Well, at least have a cake to eat. And the problem with your consciousness driven approach is that it's not a real solution. Let's say I work at a company, and I push for us using your work under a commercial license because I'm a good person. Then five years later I move on and someone else takes my place. They notice that we're using a commercial license instead of an MIT one, and just switch to the MIT one. And by doing so they are fulfilling the fiduciary duty to their shareholders.
Software use should not depend on individual morals. Any usage restrictions should be written down in the license.
They can't switch because if they earn money they are obliged to pay as per my agreement. There is no more discussion to have if you don't understand that the law does not exist only people exist.
I don't have time or will to waste time trying to force people into common sense more than I have with this hybrid license (let's call it that to avoid the collision with dual license).
The #xkcd386 is strong in this one, but I'll bite.
It's true that people use words to describe things, and generally the court will give effect to what you write as long as you have the right to do/request it. But given your writing style in this comment and others, I seriously doubt what you think you wrote is what a court would interpret it as.
There's a reason why people hire lawyers to write legal documents, and even so they sometimes screw up.
By the way, nobody needs to "enforce that MIT in court against your text". At best, people ignore your work because the license terms are unclear and their lawyers advise them not to touch it with a 10 foot pole. At worst, people "steal" your work, and YOU end up going to court to try to convince the judge that what you mean is what you wrote, even though the terms apparently contradict themselves. (because if you don't go to court to sue people violating your copyright, nothing happens unless you have a couple billion revenue in which case you can call up the FBI to help you.)
I'm not saying you can't get it right, but man your attitude is annoying.
In practice (more #xkcd386), for a simple license like MIT, getting the words "right" would basically involve rewriting the whole license. Consider this case - you license your software (let's call it FooBarApp) to a party (let's call them Alice), and Alice doesn't use it to make money whatsoever, which fits the "free" part of your conditions, which means they are eligible for the "MIT license" part. The MIT license allows all licensees to redistribute and sublicense FooBarApp. Alice puts FooBarApp on github with an MIT license. Bob, a commercial company with 100M revenue, downloads FooBarApp and incorporates it into their own commercial solutions offering. From Bob's perspective, all they know is that they obtained a valid MIT license from Alice, who does have the right to sublicense FooBarApp due to the MIT license from you.
To avoid this situation, you'd have to modify the "MIT license" wording and strike out "sublicense", and probably have to add another condition stipulating that the licensee must not use it to $DO_MONEY_THINGS. You can do it two ways -- one is to edit the text, the other is to wrap the standard MIT license with big lines of text saying "I KNOW I AM INCLUDING THE MIT LICENSE HERE BUT THIS IS NOT REALLY WHAT I MEAN".
At this stage my personal opinion is that you'd be better off writing a new license from scratch.
And no, I'm not a lawyer, otherwise I'd known better than to offer advice to random people online when I could charge them a couple grand.
> - On the low level more generic tooling I use ALGPL, so a mix of AGLP and LGPL, you can think of it as LGPL but you cannot modify it without sharing the source if you make money off of hosting a service which uses the software (Amazon f.ex. would need to share source if they used it in a paying server product).
If you read what I wrote the purpose of the A in my LGPL is so big coorps can't use the source for profit without sharing something back if they improve it; avoiding the whole elastic search debacle, like the comment above about MIT use your common sense and morale to judge if this is unplesant or honest!?
It's not really a question of unplesantness or honesty, more that it's self-defeating: your intent to get the best of both worlds with participation in open source and getting some reward if your work is used commercially is reasonable, it's just that when you write your own license, especially by trying to combine two existing licenses, you're most likely going to wind up with neither (as in neither open source projects or contributers will be interested nor will commercial companies, and anyone who does will be more likely exposing themselves to legal risks).
A potentially nice idea with several things to think about to real-world proof it. Let's think about nodejs packages because of colors and faker. Some random toughts.
I found colors on my laptop in a project of a customer of mine. I downloaded it as part of a npm install or probably with yarn. It is a dependency of another dependency. My customer should pay for the license, but how?
Among the other things, that "how" means also having a way to know how much they're going to pay if random-developer-1 adds a new dependency to package.json. This leads to asking a manager before adding a dependency, some paperwork, etc. All that we were doing when we had to buy software coming on floppy disks and CD-ROMs (but also downloads from the internet.)
However I must be able to use colors for free if all I'm doing is getting it for a non commercial project of mine. The author and the collective should reasonably feel sure that I'm not cheating. How?
One of the possible outcomes is companies dropping entire FOSS ecosystems and going back to buy whatever web development system Microsoft will hack together, backend and frontend and Windows Server + SQL Server too. Or from Oracle.
Maybe Microsoft already thought about selling a monthly license to use everything that gets uploaded on GitHub or distributed via npm. You stop paying, you rewrite your webapp with other components.
So yes, nice idea, but I'm not sure that the outcome will be good. Maybe we should keep thinking that if a customer or employer pays us to write some of our code as open source, than we'll write a lot of it. If we have to write FOSS instead of going out, maybe we'll write not much of it and we'll make money out of something else.
> However I must be able to use colors for free if all I'm doing is getting it for a non commercial project of mine.
Nope. IMO it's safe (from the floss side) to assume companies won't be cheating.
Don't get me wrong. They will most definitely cheat. Maybe 95% of them will cheat. That should still make tangible revenues for FLOSS maintainers. (though IME most companies really do care about the licenses they use, and they don't mind paying, like I know actual companies who bought Qt licenses)
In my understanding, the goal from the article is not really to force companies to pay for FOSS, but rather to simplify it. You could say that putting everything under AGPL forces them to pay. That's technically true, but really, it's more of a way for people who want to pay FOSS inside the company to push to actually pay FOSS. Donations from a company to a someone isn't really a thing an engineer can push down to the finance department.
Don't get me wrong, with the same wording, there is a fine line between "companies are stealing from us, they need to give money back" and "we know companies would like to help us, but it's hard for them, so let's make it easier for them" which is very easy to cross. For the moment, FOSS financing has no plausible solution (nor incentives), assuming companies are lawful neutral. Even for lawful good companies it's pretty hard. So let's start by making systems to give those companies way to help FOSS, before thinking about potential cheaters.
> IMO it's safe (from the floss side) to assume companies won't be cheating.
Agreed, plus you now have a collective motivated to enforce license compliance.
And "license compliance" is easy, because the collective has a list price. No need for a complicated law suit, it's always cheaper to pay the collective.
I use a similar model for EmailEngine (https://emailengine.app/). The code is dual-licensed under AGPL and a commercial license. The app has limited functionality by default - you can either buy a license key to activate it and use the app under the commercial license. Or fork the code, remove limitations (really easy to do, one or two lines of changes), and use it as AGPL. At first, I did not have that artificial limitation and no one was interested in buying the commercial license. Once I added that extra step, I got some customers.
Did you try to enforce the AGPL somehow? In the sense that the user that puts it on a (web)server must provide the end user the source code? (The 'A' in AGPL).
Not really. It's an application you install to your internal network and most probably do not make it accessible publicly. I have no way to know who and where has installed it. I assume that the app is forked in Github and the changes to disable license key check are also committed to that fork, so this would make it valid in terms of AGPL.
> It's an application you install to your internal network and most probably do not make it accessible publicly.
If people don't make it accessible publicly, then the AGPL isn't really imposing any obligations on them, even if they modify the code. It's unclear to me exactly when what you did would lead to someone paying when they otherwise wouldn't.
A lot of people do not care about licenses at all. No matter what you list as the license, they will do so if they can download and run it. Over the years, I have tried this multiple times where I provide the same code under a copyleft (free) license and commercial or permissive license (paid). Not a single time I've had anyone come to me and pay me to make it around the copyleft license. Any time someone has purchased the other option, it has been because of potential support options, etc.
So in EmailEngine, I added a license check. The code is always the same, but if you do not provide the license key (you need to pay to get that key), EmailEngine does not work correctly. Specifically, it stops processing email accounts after 15 minutes of runtime. You have to restart the application to get it functioning again. You would have to modify the source code to overcome this, but EmailEngine is distributed as a binary. To edit that code, you have to download it from Github, modify it and figure out how to run it. It's all straightforward, so it's not an obstacle for anyone with enough dedication. For others, it is easier to pay for the license key than to figure out how to circumvent it.
An interesting idea, sounds good, but the details would matter. For example resolving how payments work for developers / contributors on a particular project so that the cut was fair and consistent with input value (not just line / commit counts)will be challenging. Would also suggest that each collective would likely have a different governance model. Could you have your project in more than one collective? Why not I guess, but lots to details to resolve, and, knowing the FOSS community could get contentious quickly ... But best of luck with the basic idea, I like where they're thinking
I'm working on a solution where the "FOSS collective" aspect can be decentralized and represented as a protocol. I think it simplifies a lot of things.
People still have to work and pay the bills and have to negotiate salaries. If anything, an organization representing a large fraction of the FOSS community would be less contentious.
I think these collectives would end up behaving much like the music industry in terms of chasing licence fees, suing orgs for infringement, and having too much power on what cut was handed down to developers.
Personally I would rather software be Free than have a unavoidable middle man taking a % cut.
While I appreciate that you've released a new source-available license to the public, the OpenFare License as described in the README is not free or open source.
FOSS software can be sold, but if the software license requires the user to pay to continue using it, the software is not free because it does not unconditionally grant the user the freedom to run it:
> The freedom to run the program as you wish means that you are not forbidden or stopped from making it run.
That restriction also means the software is no longer open source, since it discriminates against commercial users who do not pay:
> The license must not discriminate against any person or group of persons.
> 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.
Source-available licenses are a middle ground between proprietary and FOSS licenses, and they certainly serve a purpose. But, they're not FOSS licenses unless they allow the user to use, modify, and redistribute the software without exception.
How do you fit AGPL in with the freedom to run the program as you wish, which is explained in the gnu.org link you gave as:
> The freedom to run the program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job and purpose, without being required to communicate about it with the developer or any other specific entity. In this freedom, it is the user's purpose that matters, not the developer's purpose; you as a user are free to run the program for your purposes, and if you distribute it to someone else, she is then free to run it for her purposes, but you are not entitled to impose your purposes on her.
Suppose I find an AGPL program that takes a photo on standard input and does interesting transforms (like the effects Apple Booth and many chat programs support), I tweak the code a bit, and I hook it up to a camera and write some glue scripts that take a photo with the camera, apply a transform selected by pressing a button, and print the results which I put in a nice frame. I build this all into a booth and put it an a mall and use it to sell fancy framed goofy transforms of people.
All fine under AGPL. I don't have to tell the people who come to my booth that I'm using AGPL software or tell them where to download it.
But then I make it so if your mobile device is using the mall WiFi hotspot, you can upload a photo from your device to have my system make your goofy framed transform photo. Now AGPL requires me to tell them I'm using AGPL code and make the download available.
So...the requirements change depending on how the inputs are supplied?
If the inputs come from the camera hooked directly to the computer, I can use the tweaked AGPL program for my purpose (making goofy framed photos) "without being required to communicate about it with the developer or any other specific entity", but if the inputs come through the mall WiFi I do now have to communicate about it with a specific entity (whoever supplied the inputs)?
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
In the mall example, this requirement can be fulfilled by having a link to or an attachment of the source code on the interface that facilitates the photo upload. The developer does not have to communicate with the user, since the requirement applies to the software ("your modified version") and not to the developer.
When a software license requires the source code of the licensed software to be released, that does not make the software unfree. This is because allowing users to access source code is one of the goals of the free software movement, as well as a prerequisite for freedoms 1 and 3:
> The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
> The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Note though that if I don't provide the WiFi access option the person using my goofy photo service does not have to be given access to the code.
The document you cite on the four freedoms says "A program is free software if it gives users adequately all of these freedoms. Otherwise, it is nonfree". Does that mean GPLv2 is not a free software license, because it only gives users all of those freedoms when someone is distributing the program?
The issue is how to define "user". GPL (and pretty much everything else before AGPL) keyed everything off of distribution. The user was someone who had a copy of the program. Mere interaction with a running copy of a program did not make the interacting person a user.
With user defined thusly, GPLv2 is a free software license. If I do something to make you a user (i.e., I distribute the code to you) GPLv2 ensures that you get all four freedoms.
If we expand user to include people who are interacting with someone else's running copy, which it seems we have to do to make AGPL fall under freedom 0, then (1) it becomes hard to argue that licenses that trigger only on distribution can satisfy the four freedoms, and (2) it doesn't even do a good job with AGPL because AGPL only ensures the four freedoms to those who are users by interaction when that interaction is remote and through a computer network. It completely drops the ball for users by interaction who aren't interacting in that specific way.
AGPLv3 refers to "all users interacting with it remotely through a computer network", not "people who are interacting with someone else's running copy". If someone adapted AGPLv3 into a new license that requires all "people who are interacting with someone else's running copy" to be able to access a copy of the source code regardless of whether the interaction takes place over a computer network, that new license would still be free and open source. The FSF has not bothered to write such a license yet, but anyone can do it.
This part of the FSF's page on free software endorses this type of rule:
> Rules that “if you make your version available in this way, you must make it available in that way also” can be acceptable too, on the same condition. An example of such an acceptable rule is one saying that if you have distributed a modified version and a previous developer asks for a copy of it, you must send one. (Note that such a rule still leaves you the choice of whether to distribute your version at all.) Rules that require release of source code to the users for versions that you put into public use are also acceptable.
I don't claim that this is a free or open source license. The OpenFare license is about monetizing software in the most convenient way possible. I agree with the open source definition as given here:
> But if your license isn't open source, then what good is it for monetizing open source programs?
The OpenFare License is the commercial license that I believe should be used in the dual licensing circumstance described in the article. Thereby helping to monetizing open source programs.
The OpenFare License intends to provide that commercial aspect whilst being equivalent to the MIT License where possible.
Sponsorship and donations are the popularity driven funding mechanisms. I want to fund the unpopular long tail of software maintainers (like the log4j guys who were not well known before the incident).
I want to fund maintainers based on whether the software is *used* commercially or not. Not on whether it's popular or not.
OpenFare doesn't lead to extreme individualism. It aims to fund collaborative software development. The OpenFare scheme is flexible enough to reflect how the collective wants to manage funding.
The OpenFare is *equivalent* to the MIT License in non-commercial settings. It isn't even close to a closed source license.
> The OpenFare License is a lot like the MIT License. The code can be modified, forked, reproduced, executed, and compiled without restriction by anyone. With two exceptions:
>
> Commercial users are subject to payment plans defined in code.
> The license and payment plans can only be modified by the license copyright holder.
I like this idea in principle! Of course, enforcing it is another question altogether, but ... a step in the right direction, nonetheless.
Question, why does the payment plan appearing in the code rather than in the license make a difference? Assuming you're not allowed to distribute/modify etc without also including the license, does it matter where the payment plan is coded? Or am I missing the point here?
There are many advantages to defining the payment plan in code. Whether it's defined in the OPENFARE.lock file or the LICENSE file only matters for the sake of simplicity. The LICENSE needs to be the same across many packages so that it can be approved by lawyers once.
The idea is to put (very narrow) customizations of the terms in the OPENFARE.lock file.
What evidence do you have that these collectives would behave like the music industry? Generally the music industry does not go after the large companies, but instead after small individuals.
In contrast the collectives would go after large corporations which profit in the billions from volunteer work without giving significantly back. In fact the argument that situation is that currently you're paying the middle man (those corporations) without the actual creators getting anything.
Thats what Trademark, Copyright, DRM, WhatsApp ToS and all claim. “We want to protect creators/snail businesses ”, but they end up as tools to go after little guys.
One one hand, given human nature and evidence thus far, I would agree with your worry.
On the other hand, the music thing is a mess partly because of ambiguity of what constitutes use (e.g. is a coffee shop video infringing because a piece of music was heard in the background?)
I would hope that things are not as ambiguous with code libraries. They are either used or they are not.
Having said that I can see shit hitting the fan with arguing over what constitutes a fork vs derivative work etc.
Writing open-source software to get rich is a bit paradoxical to me.
Would Linux be as popular now if it was dual licensed from the beginning?
Everyone who wanted to install Linux in a company had to pay $99 per CPU?
(or whatever), or PostgreSQL, GNU tools and so on.
If you dual license it, can you legally enforce who can use which?
Can you take a company to court if they are using the tool that is
open source as well as dual license?
Opensource is a fad now. Everyone wants to make their software "open source",
make the world better, while at the same time making billions., and getting
really mad if someone else is making money off it.
Though the term open source is not so worn out and tired that it is nearly meaningless since people use it in all sorts of ways.
When I use the term, I mean classic GNU and Linux open source.
For people who get angry about the inability to make enough $$$
on a GPL license should also ensure that they are not using
GLP licensed tools/apps/code in their work.
I have no problem with people making proprietary software and selling it.
I dont have a problem with people making GPL software and offering to sell it.
I dont like the duality in wanting to be "cool and open source saving whales"
and at the same time expecting billions off the product.
I don't see how anyone would have been required to pay for Linux under this proposal. The idea is that everything would still be available freely to everyone under a copyleft FOSS license, but companies that don't like copyleft could pay for a permissive license instead.
For a while, people in the open source community kept bashing proprietary software in a way that for many devs, writing such software is/was considered unethical. Something unique to software development.
Yes, Linux won on the web and we're freer than if Microsoft had won, but the corporations learnt a way to keep using the open-source tag, and Android is a great example, while cornering our freedoms more and more.
Then, the true mantainer with the open-source spirit, has to live for scraps, while seeing everyone else making the big buck.
To me, the current situation is a consequence of the ethics of the early open-source community, that left the average small propietary software developer unable to make money, but of course, could do nothing against the megacorps. Did they really think they could win?
That is a good point.
I had not thought about that before.
FreeBSB was released Novembet1993
Linux had its first release
Linux was initially released on September 1991
Per Wiki, I am not sure if this is accurate.
He did announce it then, but it was not open source.
Yggdrasil had their first December 8, 1992
Slackware had its first release July 17 1993
I knew about Yggdrasil because I was using it back then.
In February 1993.
All to say that Linx appears to have just barely makde it to market
ahead of FreeBSD but that may not relevant at all.
Why did Linux get such a huge following and FreeBSD not.
This is a decent idea. On the commercial model to use for a licensing body, in the UK you'd probably want this to be a Community Interest Company, either limited by guarantee or limited by shares (which could be owned by licensors). This is a company that acts in most respects like a limited liability company (i.e. it is profit making and is limited liability) BUT it has to reinvest a proportion of its profits in the community it serves (contributing devs in this case) and has various other restrictions on the disposal of assets.
If its guaranteed by shares then it can pay out dividends and it can even be publicly traded. But there's a hard cap on the amount that can be paid out in dividends (35% off the top of my head in the UK). Its' a nice model for this type of endeavour because you don't have to deal with the limitations put on charities / non profits, but you also have a series of guarantees against it going full evil.
In the USA I believe the nearest is a Benefit Corp or an L3C.
> 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.
Just one question. How would you handle transitive dependencies?
Let's say I want to license package A which depends on package B (which is, let's say, licensed under AGPL). Package A enters the Collective, package B doesn't. What now?
Not OP, but presumably company C which desires to buy a licence to A will have to ensure they can provide their own B equivalent, or reach out to the author and ask them to enter the collective / enter into a private licencing agreement with them.
Not saying it's not a pain, but it's not prohibitive.
That _would_ mean, however, that this kind of dependencies should be explicit to C at the point of purchase on the Collective's website, so that an informed decision can be made to buy or not.
I've been working on a solution along the lines described in the article: OpenFare.
With OpenFare, payment plans are defined in code. Which means that the dependency tree can be priced by direct inspection. I've got a working example for NPM dependencies.
> > What if commercial users neglect to pay? Who will stand up for the project maintainers?
> Software developers who work for commercial entities want to pay for well maintained source available software. They understand that the situation is precarious because open source developers largely go unpaid. They also can't easily justify donations or charitable sponsorship when they work at for-profit companies.
I think this misses the issue. The issue isn't the will to pay/donate to people it's the bureaucracy of the pay companies pay for things.
If I took the output in your example in the repo (even nicely formatted in a csv with `Bob,$20,bob@paypal`) to my finance team they'd laugh me out of the room. They need Invoices/POs, they don't just send money to people's Paypal, and they definitely won't be paying anyone in BTC.
Don't get me wrong, I like the idea. It just isn't going to work for 99.99% of companies. Perhaps some combination of OpenFare and something like the article mentions could work but that's a lot of plumbing and kind of kingmakes whoever is in charge of generating those invoices and processes the payments.
Ironically I could see someone like MS/AWS being able to have the resources, if not the will to do this.
Honestly, your comment is the most useful I've had so far.
I agree with what you've said. I don't expect any company to pay anyone with PayPal, BTC (or even lightning, can you imagine!), but I want to leave the door open for that.
Proper invoicing is key. And I think I can avoid the "kingmakes" problem you've mentioned.
The longer term view that I have includes a payment portal service. A company would submit a report (via the openfare tool) of the OpenFare licensed dependencies that they use. The service will then invoice them and facilitate a single lump sum charge via Stripe (credit card) or similar. Then forward to the developers or refund.
I think I can avoid the "kingmakes" problem because of the following: anyone could start a OpenFare payment portal. The OpenFare licensed dependencies report could be sent to anyone.
This is awesome! I just wrote a blog post along the same lines (https://staktrace.com/spout/entry.php?id=883) and I would like to join forces with you. Let me know if there's anything concrete I can do at the moment, otherwise I'll just keep an eye on your work and help where I can.
That's great to hear! Yes, we've wondered across the same sort of idea with your "DONATIONS.txt" file. I post updates when I can to the Matrix chatroom:
From now on the Collective can license it to commercial organizations that don't want to touch AGPL stuff, and pay you a cut!
A "collective" is really just a benevolent dictator with multiple personality disorder.
They start out as reasonable and efficient entities in theory. Expecting they will remain such once they have control is a flawed assumption that ignores human nature.
But kudos for addressing this at the end of the article.
Charge money to write software. Charge money to maintain software. Don't charge money for making copies of software.
- - - -
> the pragmatic reality is that FOSS developers live in a material world, a market economy, and need to make money somehow.
That's the point of leverage right there: Let's transform the economy so that machines do the scut work and no one has to "earn" a living.
To me that is the whole point of computers. The obvious thing to do with them is create a kind of secular, pragmatic, realistic utopia. Of course you can't cure the human condition with machines, but you can eliminate most of the nitty-gritty problems that people have, like acquiring food, shelter, clothing, transportation, education, health, and so on.
That's where the "extraordinary and even spiritual ... idea of a global, voluntary, collaborative yet competitive network of people sharing their knowledge and work and building together something that can challenge even the largest commercial organizations." should be headed. (Otherwise you're just automating the existing stuff, which, frankly, doesn't seem all that well thought out.)
Rather than trying to embed in the existing economy, computer programmers should seek to transform it. The invention of the transistor and the Turing Machine together has unlocked a flood of resources (not unlike how oil unlocked a similar flood) and we can direct that flood to "lift all boats".
> Charge money to write software, Charge money to maintain software.
charge whom if you don't work in a company? If it was the case nobody would be writing open source code to begin with. Do you think students writing and maintaining open source libraries are being compensated by their university or something?
This is an interesting idea, I need to think on it, so just a few thoughts:
* I could get behind this if the open license is something like MIT or Apache, ideally WTFPL or public domain even. I worry that AGPL would lead to corruption in ways that I don't see yet, probably through copyright and IP, so someone like the RIAA/MPAA would end up owning the collective somehow.
* Open source was/is compelling to me because I thought that freedom through free software could be a model for humanity. I'd prefer that society went toll-free, rather than adding a toll to free software. So stuff like UBI, expanding the commons by making internet free like public land, roads and bridges, etc etc etc. Coming at this from an abundance (rather than scarcity) mindset.
* Along those lines, I thought that maybe something like a lien could work (not sure if that's the right word). For example, say a company uses 100 pieces of open source software. That would show on an open source "ledger" as a debt of 100. If a developer wrote 1 of those, the company would have a "debt" to them of 1%. So if the company nets $1 million per year in profit, it's kind of like 1% of that is owed to the developer, or $10,000. Some companies owe billions of dollars in open source debt. Until they pay that, maybe there should be limits in how they can exercise their power. Perhaps they could be banned from lobbying the government, for example, or risk losing the use of any open source license for profit until they pay their debt. So I guess the real power of the Collective would be to blacklist companies that abuse their power.
> I could get behind this if the open license is something like MIT or Apache, ideally WTFPL or public domain even.
That would defeat the purpose. If the license freely given to everyone were permissive, then companies would have no reason to pay for a different one.
> I worry that AGPL would lead to corruption in ways that I don't see yet, probably through copyright and IP
We actually have something like that in Germany for musicians: GEMA.
Unsurprisingly, it is a failed experiment. Among other things, every time you buy storage media that could be used to store music (burnable CD, DVD, ...), you are forced to pay a GEMA fee because you could use the medium for piracy (which, of course, remains illegal nevertheless). Everyone publicly playing music has to pay GEMA fees, because he might play something from the GEMA portfolio. As a musician you more or less need to join their club and pay membership fees. All the money, GEMA collects is then (minus a generously large administrative overhead) distributed among all members, depending on how big they are in the business. This means, small time musicians may actually subsidize the big names.
TideLift is sort of like this? No dual licensing, but they do consolidate having to manage all the subscriptions into one subscription by working with all the maintainers.
No idea if they're successful or not. Or if they're successful on behalf of their maintainers either.
I re-read the author's essay multiple times and I finally realized his proposal rests on a (probably incorrect) assumption of corporate motives and rationale. He believes the only reason companies avoid AGPL is the extra paperwork burden it causes.
In other words, he thinks companies avoiding potential license infection of their closed-source code is not the main reason. To be clear, the author believes in the promise of AGPL and thinks the real issue is the payment structure. Excerpt:
>So we're going to build on the idea of dual licensing. You know – licensing under both AGPL, which is rather unfriendly to commercial applications and another separate commercial license. In my opinion, it is a very promising funding model for many projects, with one problem: it does not scale.
Thus, using author's framework, we'd interpret Google's ban as merely avoiding too much licensing paperwork (too many software contracts are not scalable) and that they actually have no intellectual property problem with AGPL.
Basically, it seems like he's proposing "AGPL"-collective rather than AGPL-multiple-custom-contracts. The philosophy of AGPL is still a crucial part of his proposal. In his view, once the AGPL-collective is in place, the main reason for the Google AGPL ban would no longer be there. Excerpt:
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
He's saying programmers don't have to compromise on ideals of AGPL -- just give commercial companies an easier way to pay for it with a one-stop-shopping experience for the license.
> He believes the only reason companies avoid AGPL is the extra paperwork burden it causes.
Maybe I’m the one misreading it, but isn’t the author saying that the reason to avoid dual-licensed (e.g. AGPL and commercial) software is the paperwork burden for the commercial license?
Going with your Google example, I think there would be no issue as Google would not be using the software under AGPL, but under a commercial license instead.
> I re-read the author's essay multiple times and I finally realized his proposal rests on a (probably incorrect) assumption of corporate motives and rationale. He believes the only reason companies avoid AGPL is the extra paperwork burden it causes.
I read this very differently (or I'm misunderstanding you), the reason why companies avoid AGPL is because they do not want to open up their closed source code that they run together with (unmodified) GPL/MIT code on their servers. If they were using AGPL they would have to open source their closed code as well.
Now companies would likely be willing to pay for a commercial licence of an AGPL library they use, to avoid having to open source their closed code. However, many packages don't even have the possibility for dual-licencing (possibly partly due to the paperwork involved for the maintainers), and also having to track commercial licencing (contracts) for many small packages would put corporations off. Instead he proposes that there are "package deals" which lightens the buerocratic burden on both maintainers and "customers".
Yeah, the flaw in his assumption is that an enterprise will use anything other than completely open licenses. Most companies ban AGPL, and really anything other than FreeBSD or MIT licenses. Primarily because they don't want to built anything with a non-free licenses as otherwise amounts to a permanent tax for the software infrastructure going forward.
The second flaw is assuming open source developers should get paid. If they want to do that they can start a company and sell commercial software, or they can join a big company(Faang, RH, IBM, etc) that outputs open source as a matter of business. But anything else is wishful thinking.
Couldn't we mash something like [flattr](https://flattr.com/) into the package managers ( npm, pip, cpan etc.)?
That would give the companies/users an option of regularly contributing a fixed budget to x FOSS projects without having to track down who/where/how for each dependency. The org collecting the micro payments distributes once a month to project maintainers with commit privileges.
For static libs, the project maintainers recursively use the same mechanism, the money trickles all the way down the dependency tree.
Many people aren't "copyleft hardliners" like sfconservancy here, but I do think the fundamental point is valid in this case. If you want to make money by selling software licenses, then by all means go ahead and do that, but don't pretend it's also FOSS.
Strange that the Conservancy is against selling exceptions when the FSF is okay with it.
> If you want to make money by selling software licenses, then by all means go ahead and do that, but don't pretend it's also FOSS.
But it is also FOSS. If something is available to everyone under a free license, the fact that you have the choice of another license too doesn't make it stop being free.
I think messing with licenses just won't work, people want to choose libs that are uncomplicated and free to use and can be used to build commercial products without paying.
I have doubts this proposed Open Source Licensing Collectives idea would actually lead to FOSS programmers receiving significantly more income.
This proposal shares a similar limitation with other licensing ideas that try to shift the money from rich corporations: The enthusiastic essays on "better" licenses such as GPLv3, AGPL, SSPL, etc always leave out game theory behavior of potential users to _not_ use the code at all. Examples:
(It doesn't matter if those corporate decisions are based on misunderstanding licenses and FUD. Their decisions are still a reality.)
Thinking in terms of predicting chess moves. Let's say a programmer's chess move is to release the code with GPLv3/AGPL/Collective. The other side's response chess move is to choose BSD/MIT or write their own. They may choose to not play your game at all.
If the type of license causes the code to be not be widely adopted, there won't be any programmer income so it will be a moot point. This probably depends on a case-by-case basis ... i.e. whether it's a library -vs- application -vs- infrastructure component, etc.
Will influential companies choose to "ban software from License Collectives"? This seems like a very realistic outcome. Why would it not?
EDIT reply to: >The license collective described in the article is just another way of selling commercial licenses in addition to offering a FOSS license
Are you the author of the article? If not, I disagree on your interpretation based on what the text says. It is not clear that he's proposing a purely voluntary payment to the Collective such that corporations can use FOSS for free and only pay the Collective if they feel nice about funding projects.
Look at representative excerpt:
>From a perspective of a commercial organization like a corporation or a startup, things become much easier now. They can go to one or more collectives, sign one bigger license and get a license to use thousands of FOSS projects aggregated by a given collective (there could be tiers).
There is no need for all that machinery above of "tiers" or even "dual" in dual-licensing if payment to Collective was optional.
>I'm not sure why a company would ban software from license collectives,
Because alternative software licenses still have to compete in the marketplace with other licenses like BSD/MIT that don't require payment to the Collective. Therefore, it's easier for corporate counsel to issue a blanket rule to avoid all software from the Collective unless the CTO approves. This adds enough friction for adoption that the hoped-for extra income to the FOSS programmer doesn't materialize.
So yes, game theory still applies to corporations that would ban their staff programmers from using any software that requires them to sign a license agreement with a Collective.
The license collective described in the article is just another way of selling commercial licenses in addition to offering a FOSS license to keep the software free and open source.
I'm not sure why a company would ban software from license collectives, unless they a) have a policy against paying for any software licenses at all, and b) have a policy against using copyleft-licensed software. A company that implements these policies is probably not going to benefit the software developer financially regardless of how the software is licensed.
Edit: Replying to your edit, no, I'm not the author of the article. In the proposed arrangement, the user can choose to comply with the FOSS license, pay for a commercial license (via the collective), or not use the software. If the user is unable or unwilling to comply with a copyleft license, the ability to use the software is an incentive for the user to pay for the commercial license. On the other hand, if the software were under the BSD/MIT License, the user would have no incentive to pay any money to the developer (unless they felt like making a donation). Companies that ban software from license collectives were, in all likelihood, never going to pay the developer even if the software were BSD/MIT-licensed, so they are financially irrelevant to the developer. It's the users who don't have such policies that are going to make the difference.
> As an Open Source developer, you build a new cool library or a tool and license it under AGPL.
Please don't do this, and don't advocate for this. (A/L)GPL is poorly understood by most, poorly worded, and the FSF refuses to clarify basic points regarding it and are openly hostile to people who sell software for money.
One example of the lack of clarity is what constitute linking, and where the boundaries of the covered software is. The like to play a game here where the on one hand suggest it is not linking to make network calls, but then in their own documentation say it is open ended and for court to decide where the boundaries are, which basically makes it completely pointless and a massive landmine. Just use a sane license by less zealous people.
> and are openly hostile to people who sell software for money
That's not true. The FSF endorses selling software for money, as long as the source code for the software is made available under a free license:
> Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible—just enough to cover the cost. This is a misunderstanding.
> Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license.
Copyleft licenses can be inconvenient for developers who want to integrate copyleft-licensed software into their own incompatibly licensed software. The proposed arrangement in the article turns this inconvenience into an incentive to pay the developer. With dual licensing, developers of proprietary software can purchase a compatible commercial license to fulfill their product needs and fund development of the copyleft-licensed software at the same time.
>The proposed arrangement in the article turns this inconvenience into an incentive to pay the developer.
An incentive to pay the developer that completely undermines the point of free software (that proprietary software is evil and should be opposed, undermined and eliminated.) Dual licensing legitimizes proprietary software and contributes to its spread.
Richard Stallman of the FSF has a rebuttal to that opinion:
> When I first heard of the practice of selling exceptions, I asked myself whether the practice is ethical. If someone buys an exception to embed a program in a larger proprietary program, he's doing something wrong (namely, making proprietary software). Does it follow that the developer that sold the exception is doing something wrong too?
> If that implication is valid, it would also apply to releasing the same program under a noncopyleft free software license, such as the X11 license. That also permits such embedding. So either we have to conclude that it's wrong to release anything under the X11 license -- a conclusion I find unacceptably extreme -- or reject this implication. Using a noncopyleft license is weak, and usually an inferior choice, but it's not wrong.
> In other words, selling exceptions permits some embedding in proprietary software, and the X11 license permits even more embedding. If this doesn't make the X11 license unacceptable, it doesn't make selling exceptions unacceptable.
With all due respect to RMS, having read the linked page, that's a weak rebuttal. He seems to reject the premise on the grounds that it's sometimes inconvenient, but accepts it entirely on philosophical grounds when explaining why the FSF doesn't dual-license.
So I think he agrees with my general argument that dual licensing does undermine the principles of free software, but accepts that not everyone can afford to be a zealot.
I'm just suggesting that more appropriate licensing schemes already exist if a developer wants to be paid.
> He seems to reject the premise on the grounds that it's sometimes inconvenient
His argument is that if you consider dual licensing to be immoral because it enables the development of proprietary software, then to be logically consistent, you must also consider non-copyleft FOSS licenses such as BSD/MIT to be immoral because they do the same to an even greater extent. Stallman does not say that dual licensing undermines free software, he only says that it does not support free software as much as copyleft licensing does.
The FSF only uses copyleft licenses for software instead of non-copyleft FOSS licenses or dual licensing, sidestepping this issue entirely. They don't have a problem if people use BSD/MIT, so they also don't have a problem if people use dual licensing.
They can't be clear, because the law is manifestly unclear.
The theory they give for disallowing non-GPL code to link to GPL libs is that the linking process involves copyrighted code and materials in the header files and interface (API).
This is, of course, what the Oracle v Google case was all about. The code in question is even (dual) licensed under GPL! If the US Supreme Court can't give a straight answer to whether APIs are copyrightable, the FSF is wise not to give any advice that would potentially put their proverbial foot in their mouth.
Of course, the legal uncertainty doesn't stop RMS and his friends from spreading FUD about GPL "virality" because that theory helps making everything GPL.
That said, I think GPLv2 is generally OK if you believe in ideas of "Copyleft". In retrospect I think it's kind of sad that GPL slowly fell out of favor by devs because of all the complications of the GPL (of which some you mentioned). I remember in the early 2000s almost everything was GPLv2 by default. The world swung to permissive licenses after GPLv3 became too ambitious and made the licensing issues too complicated for the average software dev to care about. I suspect a lot of resentment that OSS devs don't get compensated is partially due to the ecosystem giving a lot of peer pressure for devs to use a permissive license by default (where they might actually have intended something like copyleft or non-commercial use licenses).
I know a significant part of my salary is paid for by the productivity of permissive licensed OSS (i.e. my employer doesn't have to pay OSS, so presumably part of the saving goes to paying me), but still these "what ifs" are still worth thinking about, and maybe there's still a chance that some issues could be addressed.
I wouldn't say that they don't necessarily understand some of the original principles behind the open source movement or even maybe what the adjacent free software movement advocates for.
It's just that they realize the realities of living in our society, financial pressures and how they impact one's ability to contribute to projects long term.
Keeping things open for other FOSS projects and maybe non-commercial use cases while charging companies seems like a good compromise in regards to sustainability!
How would this idea be against the spirit of open source?
> 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.
This is the part that earns my support. I see some B2B software use dual licensing arrangements that offer a proprietary commercial license alongside a source-available license that is not a free software or open source software license. While having the source available is better than not having it (since it can be publicly audited), being able to use, modify, and redistribute the software for any purpose is an essential part of FOSS. But as long as the AGPL or another FOSS license is offered as an option, the software is still free and open source.
I have been considering, in new books and new editions to books I have written, to change the license for the book examples to AGPL, but for people who purchase a book, they get a commercial use license. I make all my recent eBooks available as a free download, or people can pay. I use the statistics of which books more people pay for to guide how much writing effort I put into different topics. On average I get about 50 downloads for each paid for book. I have been happy with this process.
What is changing is that as I approach my 71 birthday, I am getting pressure from family and friends who retired a long time ago for more of my time, and as much as I love working, I will probably “retire” from paid work in the next year or two. I think that making writing my “job” again might be a good way to still enjoy staying current with deep learning and AI in general, and also earn a little money from doing so.
I do worry that the dual licensing approach might turn off some readers, so I think I will try out this plan with a new book and see how it works.
EDIT: might be of interest: by far my most paid for book is my Common Lisp book, followed by my Haskell and Hy (Python Lisp) books. Those books are scheduled to get new editions. Since almost all of my work in the last 7 years has been deep learning based, my next planned new book is a practitioners guide to DL, from my personal perspective.