Google can afford to re-implement software. It is questionable if they even get hurt much by release delays, especially if the new product is within their eco system. Thats the benefit of having monopoly or monopoly-like position in a market.
If you are on the other hand in a highly competitive market then re-implementing code and delaying launches can result in being replaced by some with more flexible approach. My go-to example is the gaming industry. As an example, if you have a webbased ticket system it might not matter much if there is a download button, and developer time is much better spent on finishing the actually game than writing one more ticket system.
Game studios in general seems to have very flexible approach to licenses. To my knowledge they will apply all methods if it means saving time, as long as they can keep the game itself proprietary and sell copies. They will any software directly if they can, buy if it makes economical sense, or even just ask the author for an exception (with attribution in the credits).
If you work in a startup, it will bite you during due diligence when a potential acquirer is evaluating your intellectual property. I would give the AGPL a wide berth.
If you're the owner of the code, all the past versions of the project are and will be AGPL forever (or MIT, or BSD) but all the new versions will be whatever you want. You can also dual license. If someone forks the old AGPL version (or MIT, or BSD) they can keep that license on the fork, but they can't use your new code.
This! I am quite sure that most projects, in exchange for some negligible part of Google's money, would be more than happy to offer the software under a different license. My guess is that it's the difficulty of ensuring that the new license terms are not breached (the license would need to be checked by lawyers, approved,...) that is the real deal breaker.
Not that I sympathise with Google here, they can afford to give something back to FOSS (not just when it advances their agenda).
IMO, the goal of open source licenses is to encourage more usage of open source. If AGPL is preventing companies from using it, then it is accomplishing the opposite.
A license is a legal document that specific under what conditions that the author allow others to use their software. Nothing more, nothing less. Open source licenses and free software licenses are standardization of common goals and conditions, and encourage usage is one such goal, but its not the only goal. Some authors want more like share-alike, attribution, and fair competition.
I agree with you. I am pretty sure the AGPL exists so that you get the "warm fuzzies" of "open source", but the company that wrote the software can still profit from it as though the source wasn't available. It is also administratively easier than making a "hobbyist edition" for people that want to screw around with the software in their free time in the hopes that they someday make money with it and buy the full version. (Also, in the event that you do license the software and need to make a small customization, it's administratively easier. Just edit the code and you're done, as opposed to the company having to set up a meeting with your team, looping in the sales engineer to see how much to charge you, then having a year of weekly status update meetings to see how your feature is proceeding.)
The problem I have is that I think truly free software is relatively unsustainable. Look at Docker's financials after basically revolutionizing how software is distributed and deployed. Look at big projects like Kubernetes; do you think you would convince investors to fund a project with a pitch like "we're going to give it all away for free with no encumbrances". Nope. It only works when you already made money from writing proprietary software. The AGPL attempts to be a middle ground, which I do respect. I am personally afraid to touch it. So are many other people.
No, this is not wrong (but you're not wrong either).
When discussing the goals behind AGPL, it definitely shouldn't be described as Open Source license (although it technically is one), but a Free Software one, since the whole difference between those two terms (highlighting the political issue as opposed to technical one) is actually relevant to the intention behind the license.
The goal behind licenses written by FSF is to ensure that distributors of your code do not restrict freedoms of the users that the license guarantees them. If you think it's about "encouraging more usage of open source", you clearly miss the point of copyleft licenses.
It makes a lot of sense. If a lick of AGPL hits any of their web services, they have to make the source available. I imagine they use plenty of FLOSS on their back-end servers, and I imagine quite a bit is GPL, BSD, MIT, Apache and so on.
A lot of other companies have the same policy. Google is unusual in being publicly open about it. Most companies, internal policies on what open source licenses are allowed are maintained by the legal department and as such are company confidential by default.
Seems shortsighted. There are categories of software where even corporate drones shouldn't worry about AGPL. The ThoughtWorks tech radar is a decent example: https://github.com/thoughtworks/build-your-own-radar
Maybe you modified it to use some new data source, and to display it for internal use. Say O365 as a custom data source. You aren't giving away any real secret sauce by sharing your modifications. Anything sensitive is probably the actual data, not the code.
The license warrants caution. But not an outright ban.
> Seems shortsighted. There are categories of software where even corporate drones shouldn't worry about AGPL... The license warrants caution. But not an outright ban.
The problem with a policy of "AGPL is allowed sometimes but not others" is who makes the judgement call on when it is appropriate and when it isn't? Can you trust the engineer implementing/consuming the component – and the average engineer isn't very familiar with licensing issues – to make that judgement call, especially when there could be significant legal and financial risks of getting it wrong? Probably not. So then the policy has to be "you can use AGPL but you have to ask for approval".
But, that's not too different from an AGPL ban – most bans have a process to ask for an exception. And, in practice, it de facto amounts to a ban, because most people will probably decide to just use some non-AGPL alternative instead of asking for formal approval (which probably has to go via legal and relatively senior management).
If you are on the other hand in a highly competitive market then re-implementing code and delaying launches can result in being replaced by some with more flexible approach. My go-to example is the gaming industry. As an example, if you have a webbased ticket system it might not matter much if there is a download button, and developer time is much better spent on finishing the actually game than writing one more ticket system.
Game studios in general seems to have very flexible approach to licenses. To my knowledge they will apply all methods if it means saving time, as long as they can keep the game itself proprietary and sell copies. They will any software directly if they can, buy if it makes economical sense, or even just ask the author for an exception (with attribution in the credits).