Comment by eastbayjake
4 years ago
Love open source projects in the eCommerce domain, especially ones that are JavaScript instead of PHP! Two pieces of feedback:
- Using a copyleft license like AGPL makes this an automatic non-starter for most businesses, no matter how impressive your tech might be. You'll have a lot more luck with mid-size and enterprise adoption with an MIT license.
- You've really built an Order Management System for marketplace use cases, which is in industry typically a distinct domain from a Warehouse Management System (WMS) or a Transportation Management System (TMS) which at large-scale tend to handle how orders actually get fulfilled and shipped to customers. Your naming is a bit misleading - at the very least I'd emphasize somewhere on your landing page that this is an open source Order Management System if you want eCommerce domain folks to grok quickly what you've built and how it plugs into a broader architecture.
> - Using a copyleft license like AGPL makes this an automatic non-starter for most businesses, no matter how impressive your tech might be. You'll have a lot more luck with mid-size and enterprise adoption with an MIT license.
What makes the AGPL unattractive? I thought it was basically just the GPL with a limitation on using the software to provide a SaaS product. You don't even have to contribute unpublished changes, right?
Before reading your comment I actually checked the licensing in the repo because I was thinking the exact opposite; using MIT would be a mistake because it's too easy to undermine the turnkey offering by selling a competing service without the cost of development.
Here's Google's stance on why they ban AGPL software: https://opensource.google/documentation/reference/using/agpl...
> The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license.
> This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed.
> Because Google's core products are services that users interact with over a remote network interface (Search, Gmail, Maps, YouTube), the consequences of an engineer accidentally depending on AGPL for one of these services are so great that we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner.
FWIW, every company I've ever worked at bans AGPL products / code.
> This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed..
This is the entire point. The goal is to stop the SAAS loophole.
2 replies →
I always cackle a bit when someone points out that GPL-family licenses are incompatible with large-scale enterprise heavily relying on proprietary technology for value extracting. Obviously GPL is incompatible and that's a feature and not a bug.
If Google truly had to be competitive, they surely could figure out ways to make AGPL work. But they don't have to because for now they're just taking everyone's data practically for free.
that really give one a sad state on the reality of business.
the fact that google is against AGPL, makes it even more important to use it! Whatever is good for google, it is not good for humanity, and whatever google doesn't like is beneficial for humanity. Support AGPL!
> FWIW, every company I've ever worked at bans AGPL products / code.
Is every company you've ever worked for a software vendor? Because those are the only companies that would be impacted at all by using AGPL products/code.
4 replies →
> The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code ... _may be_ subject to the virality of the AGPL license.
This is aggressive scare tactics. It's very straightforward when this is triggered.
When you're using code unmodified as a library (whether source or binary) it's not triggered at all.
When you _do_ make upstream modifications, it's triggered. That is the specific risk, and it is easily satisfied by open-sourcing the full modified version.
The whole "if a remote user uses it" argument is FUD. It closes a loophole in GPL where remote use != distribution.
Google is hostile to copyleft full stop. So are other bigcos and cargo-culting smallcos/startups. That doesn't make it right.
There is no such thing as virality, you always retain your own copyright over the code if you don't publish it under the AGPL. If you use AGPL code in a non AGPL codebase you are merely violating copyright and must remove the AGPL code from your codebase.
In this case, there is nothing at all wrong with a GPL license. Everyone is answering from the perspective of a software company. That isn't who this product seems to be targeting. It's targeting businesses that sell physical goods and need a virtual storefront to do that. They aren't looking to fork this and repackage it as a different product. The purpose of it being open source at all is so they can more easily self-host it. If you self-host an application you don't fork and modify, there is nothing for you to publish. The source was already published by the person you got the code from in the first place.
Thank you for adding practical sanity to this thread.
This ignores the fact that AGPL has no strict definition of “forking/modifying”.
So, adding text/marketing copy (see user comment on a restaurant app use case) can be seen as a modification.
1 reply →
There's a lot of FUD out there about GPL licenses and they've become pretty unpopular over the last decade. There are trade-offs, but there's nothing wrong with using the AGPL if that aligns with your own goals and values.
> What makes the AGPL unattractive? I thought it was basically just the GPL with a limitation on using the software to provide a SaaS product. You don't even have to contribute unpublished changes, right?
The things AGPL adds to GPL don't just affect people trying to do a SaaS offering of the program. If you modify it and users interact with it over a computer network you have to make source for your modified version available to them.
For example suppose it was software to add online ordering to restaurants. A restaurant modifies its copy so that it can be given the recipes of the items they sell and the modified software uses that information to allow customers to easily exclude items they might be allergic to or that violate their religious or ethical eating rules.
If that restaurant wants to use that as a competitive advantage over other restaurants they aren't going to want to have to give away their modifications, so aren't going to want to use AGPL software. They'd probably be fine with GPL software.
The kind of arguments you raise here have always, to me, basically looked like:
"I want something for nothing"
Or in more detail:
"I want to take something you created and agreed to share with me (on the proviso I like-wise share any changes as an exchange of value). I deem your software valuable to me but I won't be paying you money for it. I'll add something else to it so it fits my use-case. But, I refuse/object to sharing my changes because they're valuable."
1 reply →
> If that restaurant wants to use that as a competitive advantage over other restaurants they aren't going to want to have to give away their modifications, so aren't going to want to use AGPL software.
That's exactly the kinds of scenario the AGPL was written to avoid, right? The free software movement doesn't see software as a competitive advantage worth protecting; software is information that should be free.
To put it another way, if somebody releases software under a license that says "You may use and modify this for free, but you must contribute your changes back to the world," then your scenario seems perfectly fair.
As someone working on a product that uses open source, GPL makes development more complex.
With a permissive license, I can make a decision, with my manager, to use a technology based on its merit.
Office bureaucrats get weird when you talk about the GPL. When using it, I have to involve lawyers in the company, they don’t understand why the technology is important, but they have a bunch of questions, and to answer them it takes up time from my team. Upper management is involved and wants to know if we can use anything else, or they’ll phrase it as a question like: why can’t you use anything else? You have to deal with a lot more office politics when you use GPL instead of doing development work. So I’d say that’s the biggest downside for developers is that it wastes their time.
AGPL is banned from every corporation I have ever seen.
Because it's viral even when it is used internally, you might end up having to release things you never expected and that are very sensitive.
It would be insane to allow anyone to use AGPL code in any corporate environment.
MongoDB is effectively licensed under the AGPL and seems to have no problem being used by corporations of all sizes.
9 replies →
My 2 cents :
In an ecosystem like this you may want to have businesses build extensions or plugins that they'd sell. GPL has this reputation of spreading to everything it touches, and as such would scare them away.
like wordpress plugin marketplace?
1 reply →
Exposing the API/Web pages is considered distribution.
>What makes the AGPL unattractive?
My two cents: it juts isn't in business culture to contribute to public good.
"What makes the AGPL unattractive?"
I won't pretend to be a lawyer, but I do know that when we were acquired we had to list ever piece of software we used and which licence it was under. They were very concerned about copy left. We didn't have any, so I don't know how that would have changed things. MIT was what they were hoping to see.
>Using a copyleft license like AGPL makes this an automatic non-starter for most businesses, no matter how impressive your tech might be.
Maybe some (but certainly not most!) tech businesses, but what makes you think that vendors of real-world products give a shit about AGPL?
https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
> Using a copyleft license like AGPL makes this an automatic non-starter
Completely disagree. It protects the end user, and if another license is absolutely necessary, they can negotiate for it or create a different service tier.
AGPL with paid alternative licensing is strictly superior to MIT for start-ups.
js has come a long way but i'm skeptical that it's maturing fast enough for this to be the right medium- to long-term language/platform choice for something that's meant to be more infrastructure than just web app. and while php[0] is long past the hype cycle, it's more proven in this role than js, but even that is usually superceded, or at least augmented, by more "industrial" languages when approaching amazon's scale. for instance even mid-market WMS systems are often written in compiled languages like C# because of the need for speed and robustness.
[0]: nowadays i prefer ruby/rails, which can also get you pretty far before needing extra help.
Isn't this project mostly about interfaces for businesses to connect their guts? The language used to implement services behind common interfaces shouldn't matter all that much. It's just the reference implementation in js, no?
i didn't examine deeply but it seemed to me the backend is running on node, and that it was meant to be the implementation, not just a reference.
Akin to saying: "You should not ask businesses for money for your work, because they do not like it."
Greedy businesses not wanting to contribute back can buy another license and have their way, at least paying the maker(s) of this project.
AGPL by default with a paid, non-copyleft license would be a good business model.
> especially ones that are JavaScript instead of PHP why?