I wrote a medium size program for chip design and released it under the #AGPL. In this field the world is moving towards cloud services.
Now a research group wants to contribute. Google promises to pay them - but only if I change the licence to something else. Google does not like the APGL. If I don't change the licence a group of students will rewrite the tool. (Likely under a permissive licence.)
What would you do?
Something else: adopt the #HackingLicense http://www.tesio.it/documents/HACK.txt
As an alternative, stay with #AGPLv3.
The choice is:
- let #Google exploit your work as #FreeLabour, or
- force Google to pay to compete with you but starting from scratch
Never let the bully get what they want.
@Shamar Background of the story is: The chip design ecosystem has a long tradition of aggressive closeness, extremely restrictive licences, non-disclosure agreements and the like. Main players are the silicon fabs and vendors of design automation software.
In 2020 another big player appeared: Google. They more or less bought a factory and stripped got rid of everything which makes open-source impossible. On top, they offer free fabrication runs. This puts them into the center of attention. ...
@Shamar Many people who wanted to create integrated circuits but could not because of licence costs and fabrication costs suddenly can do it. With the help of Google. And that is what Google wants. They want to cultivate a new open-hardware ecosystem. They have the first-mover advantage and they can easily shape the open-hardware movement to their needs. I heard a Google employee saying that they want to increase the production of own silicon by a factor of 1000. ...
@Shamar The open-source community will play an important role to reach this productivity. Googles open-source fabrication process is a big motivator to get hackers and academics around the globe to work for this ecosystem. The impact is already big.
One missing part seems to be the tool I wrote. I've chosen the AGPL for a reason. I've seen enough proprietary tools and also SaaS.
...
@Shamar However, what if Google just replaces the AGPL tool? They have the financial means, no doubt, but they also have the platform to find people. And they have a big influence on what tools will be used. The replacement likely won't be libre, yet put into the shade its libre alternative. Changing to GPL could at least preserve some of the initial motivation behind the program.
That's the dilemma :)
If you change the license, they will capture your tool and use it against the hacking community without any risk.
They won't try to impose a closed source alternative because they care for their #OSS narrative.
They will try to build a MIT alternative from scratch under their full control.
BUT by doing so, they might have legal issues with #antitrust as, given the existance of a copyleft alternative, their replacement will makes it clear that #Google is trying to build yet another #monopoly.
Instead if you surrender to their pressure and weaken the license of your tool, you make their OSS-based propaganda stronger and harder the antitrust case against them, because they will argue "hey, we just contributed to the ecosystem", while they got control of it.
So my suggestion in your case is to stick to the #AGPLv3.
Don't trust neither Google nor Google's engineers.
I did this error before, and it didn't end well:
http://www.tesio.it/2018/02/14/what-i-wish-i-knew-before-contributing-to-open-source.html
@Shamar I wrote quite some code under AGPL, but mostly things that only few cared about. G probably knows how to make people unsure. One argument against the AGPL in this context is: "The tool will be part of a larger tool-chain. (For chip design such tool-chains can get quite complex.). The tool-chain might be containerized. It is very complicated and tedious to be compatible with the AGPL. Especially if the AGPL parts are deeply nested. (The tool might be called by other tools, etc.)" ...
@Shamar To me seems easy to be compliant with the AGPL. You put somewhere a link to the source code, visible to people who use the program/service.
But the above argument is also scary. Basically saying that the AGPL makes our all lives very complicated such that also others than Google will not like it.
This raises the question if AGPL is suited for tools like for example a compiler. Mostly its not used as a service. But it might.
Feels like you gave that some thoughts. What is your opinion?
Basically #FUD.
As you said, #Google does whatever it can to build ecosystems that depends on it, technically and culturally.
They did so in 2010 with #GoogleChrome through #Mozilla. It did so with #Android. And #QUIC. And #HTTP3.
#AGPLv3 has several limits (that I tried to address with the #HackingLicense) but the strongest the #copyleft the better.
Sticking with #AGPL and resisting to Google's pressure won't save your ecosystem alone.
BUT it might make their capture weaker and their abuse of their dominant position more evident.
As for AGPLv3 be harder to use, that's plain bullshit. As long as they use your software unmodified, they do not even need to host a copy of the code. They just need to provide users a link to your repository.
It's pretty easy.
But they do not want to.
In the long run, an AGPL alternative out of Google's control might enable the creation of an alternative ecosystem, and they want to minimize this risk as much as they can.
Without looking evil, obviously.
But if you look at Google from outside the USA, it's slowly becoming a huge geopolitical liability.
Europe is realizing that depending on #GAFAM means becoming an US colony.
And alternatives like your might get much more support from here.
So my suggestion is to ignore the FUD and resist Google.
