SFTPGo needs your help

[drakkan]

Hi all,

I'm really happy with how SFTPGo is evolving and I enjoy working on it, but as the user base grows, maintaining and evolving it becomes more and more challenging and time consuming.

I don't use SFTPGo in production myself, this is a totally hobby project.

I love doing this work and I'd like to spend more time doing it, but I need your support to make it possible.

I've turned down some paid jobs over the past few months to have enough time to work on SFTPGo, honestly it can't go on forever.

To keep SFTPGo development sustainable in the long run I need your sponsorships.

Monthly donations are the preferred option. A small amount every month is much better than a one off donation as it allows planning for the future.

You can support the project through GitHub sponsorships or Paypal donations.

https://github.com/sponsors/drakkan
https://www.paypal.com/donate?hosted_button_id=JQL6GBT8GXRKC

Based on your level of sponsorship, I will prioritize your issues and provide you direct support via email/Slack and optionally I can help you to customize your installations to suite your needs.

You can also support the project by purchasing a pre-installed instance from the AWS or Azure marketplace.

https://aws.amazon.com/marketplace/seller-profile?id=6e849ab8-70a6-47de-9a43-13c3fa849335
https://azuremarketplace.microsoft.com/en-us/marketplace/apps/eliamarzia1667381463185.sftpgo_linux

Thank you for your support!

[tiswo]

Can AGPL-3.0 be adjusted to GPL or other more lenient licenses?

[drakkan]

Can AGPL-3.0 be adjusted to GPL or other more lenient licenses?

This is unlikely, sorry. Please take a look here for a more detailed discussion

[the-maldridge]

I'd love to sponsor the project, but on personal grounds I do not support the AGPL-3.0 license. My employer also has a hard time with this, so we're having to grapple with if we're going to rewrite a lot of open source policy to be able to back this project.

[drakkan]

I'd love to sponsor the project, but on personal grounds I do not support the AGPL-3.0 license. My employer also has a hard time with this, so we're having to grapple with if we're going to rewrite a lot of open source policy to be able to back this project.

AGPL does not allow to prey SFTPGo and to include it in proprietary/commercial products.
Companies using SFTPGo code in their proprietary/closed products are violating the license (I'm aware of at least one company that is doing this).
I'm dedicating a lot of my free time (basically all) to SFTPGo and I want to keep it a free software for everyone, I don't want to see its code in a proprietary product.

I want to see any changes to SFTPGo itself and include them in this repository if I think they are useful.

Several companies contacted me privately asking for an alternative licensing option. I always refused (giving up the money).

If I would accept their offers, these companies expect that I maintain custom SFTPGo branches and they don't want to make public their changes. SFTPGo would lose its freedom: I might end up with someone asking for a feature and I can't add it because there is something similar in a private branch.

I think AGPLv3 protects well SFTPGo code and my work and it does not apply to REST API and custom hooks.

I'm very sorry if you cannot sponsor the project for licensing reasons but my current main goal is to keep SFTPGo a free software, for everyone, possibly competitive with commercial products, not their base. I'm not a lawyer but for what I can understand AGPLv3 is the right choice.

Maybe I'm just a dreamer and SFTPGo will never be financially sustainable as I'm turning down several offers to keep it free and available for everyone and only very few users are sponsoring the project.

For now I will answer you the same way I answered the companies that contacted me: I will change the SFTPGo license if I lose interest and want to monetize.

[the-maldridge]

I certainly don't expect you to compromise your position, you believe that the AGPL-3.0 is the best option for the project and as its founder that's a decision only you can make. I merely wished to share my position. Lest any finger pointing start, my company does not even use sftpgo, we have a flat ban on all AGPL-3.0 projects for exactly this reason, and were evaluating sftpgo to replace another component, but this is unlikely to be approved by our legal team.

As I wish to any author on github, I wish you the best of luck and success with your endeavors. The whole VFS concept that sftpgo introduced is a really interesting idea that I'll have to remember as a design trick for later.

[drakkan]

Can you please better elaborate what is wrong for you with AGPL? You can use SFTPGo with no restrictions, you can build your own hooks or any integrations using the exposed REST API and keep them private.

You cannot copy the SFTPGo code in your proprietary product or build a closed source product based on the SFTPGo code. If you change SFTPGo itself you have to make your changes available (for example on a public GitHub repo).

[ledmirage]

just hijacking this thread a bit to clarify on AGPL, my understanding is the restriction is only at the source code level, we cannot integrate or modify the code into proprietary code base and release it as a single product. But if we are integrating it at BINARY level (the compiled code) then it shall be okay, correct?

[drakkan]

just hijacking this thread a bit to clarify on AGPL, my understanding is the restriction is only at the source code level, we cannot integrate or modify the code into proprietary code base and release it as a single product. But if we are integrating it at BINARY level (the compiled code) then it shall be okay, correct?

Yes, that's fine. You can use the unmodified sftpgo binary in your commercial product. I think you only have to give attributions as for any other GPL software. I chose AGPLv3 to protect the source code

[the-maldridge]

I'm not a lawyer so I won't pretend to understand the reasoning handed down from corporate legal, but my personal preference is for licenses that I don't need to be a lawyer to interpret, which is why I always advocate for very short licenses such as MIT, ISC, or the BSD 2-Clause license.

My personal preference as well is to make my code as widely available as possible, as I'm more interested in people using it than anything else. Some might argue this opens me up to some group like AWS productizing my open source projects, and honestly that would be a pretty impressive achievement in my career if that were to happen. I realistically think though that they'd take the IDL files and create something interface compatible that scales in tandem with their infrastructure; this of course assumes that the recent developments in the Oracle v. Google case hold and that interfaces cannot be copyrighted.

I definitely get the drive to protect the source code, its just not what drives me and I have a hard time backing a license that I can't fully understand on the first read-through. Add to that that the AGPL has never been tested and what it does and does not promise is murky enough that I don't really want to deal with it.

[drakkan]

I want to make SFTPGo as widely used as possible but as binary. I don't want that companies use SFTPGo within their commercial products maintaining their custom, private, branches. This will not help the project to grow and make new features available to all the users.

As you can see if you have ever installed SFTPGo, I'm a very bad web developer, the web interfaces are really ugly. With this license I have the remote hope that someone can improve the web UI (at least the web client UI) and contribute it back. With a different license this will never happen. Alternatively, if I ever get enough sponsorships, I could pay good web developers to improve the web client UI.

Some companies have contacted me privately and asked me to help them develop a better web interface which they want to keep private for their use: this is only allowed if you are using the exposed REST APIs. Instead, they want the web UI included directly in SFTPGo and so they asked for a dual licensing option. By accepting their offers I could earn some money (much more than current sponsorships) but this will not help the project:

1. The awesome new web UI will remain private.
2. I will have less time to work on the SFTPGo public project.

Many other projects use AGPLv3, for example NextCloud and MinIO. The Nextcloud licensing FAQ is quite clear.

As stated above I may be wrong and may change my mind in the future, but currently I think AGPLv3 is the right license.

I'm sorry that your company does not allow the use of AGPLv3 software, your lawyers will have good reasons that I cannot understand.
As long as you don't modify the SFTPGo source code or include it in your commercial products you have no strong obligations. SFTPGo is an external application, not a library to use in your code, maybe this is not clear to your lawyers.

I hope my motivations/explanations are clear enough also for others who have the same doubts about the SFTPGo licensing

[the-maldridge]

FWIW I do think that SFTPGo is the best solution on the market today for providing legacy transport protocols on top of a more modern object store. With this in mind I'm slowly winning the fight to get it approved for use at work. Whether I'll win the fight to sponsor it or not is another matter, but I will be trying for that.

[matthewlenz]

FYI, you could dual license this and charge for it to make money. AGPL has specifically clauses with regards to web applications. I'm guessing about 99% of web application companies are probably in violation of using AGPL software. From what I understand let's say you have a closed source web application and have customers who pay to use that software. You want your customers to be able to upload files for use in that application and decide to use SFTPGo. There is a grey area to whether or not that is legal. This is my interpretation. And that's another issue with the AGPL because everyone who says that scenario doesn't apply will also say that is their interpretation (aka grey area).

[drakkan]

FYI, you could dual license this and charge for it to make money. AGPL has specifically clauses with regards to web applications. I'm guessing about 99% of web application companies are probably in violation of using AGPL software. From what I understand let's say you have a closed source web application and have customers who pay to use that software. You want your customers to be able to upload files for use in that application and decide to use SFTPGo. There is a grey area to whether or not that is legal. This is my interpretation. And that's another issue with the AGPL because everyone who says that scenario doesn't apply will also say that is their interpretation (aka grey area).

I think you are wrong, interacting over a protocol such as SFTP/FTP/HTTP never makes anything a derivative work. However if someone is concerned about this usage I explictly allow it.

As explained above, my main goal is to make SFTPGo a great product available to everyone. I won't be offering a dual license option, at least for now. I hope that development will be sustainable sooner or later with donations

[sagikazarmark]

Licensing is certainly a difficult topic, especially because it involves lawyers who often don't understand the whole situation and as a result they tend to just deny requests.

Here is my understanding of GPL vs AGPL:

When you fork a software that's GPL licensed and make changes, but never distribute that software (ie. as a binary), you are technically not required to send back the patches/share your fork with the world.

This is the loophole that a bunch of large companies use, because technically hosting software as a service doesn't count as distribution.

AGPL tries to close that loophole by saying that if the software is used by users over the network then it has to be licensed under AGPL.

I think you are wrong, interacting over a protocol such as SFTP/FTP/HTTP never makes anything a derivative work. However if someone is concerned about this usage I explictly allow it.

No, I think based on the above, accessing SFTPGo over SFTP/FTP/HTTP means the source code will have to be licensed under AGPL and shared with the users. So basically anyone who makes changes to the code and hosts the forked version as a service violates the license, unless they publish the code under AGPL as well.

There is nothing wrong with this. As you pointed out a bunch of other companies also took this road to avoid big companies making money out of their projects. Grafana might be the most recent example.

However, it's also a risky position to be in. Let's say a company integrates SFTPGo into their application (as an independently running component). They find a bug and decide to quickly fix it with the intention to send the patch upstream later. They fork the project in a private repo, make some changes and deploy the modified version. As soon as it hits their servers, they are in violation of the AGPL license, even if they intend to send the patches to the upstream repo.

The above scenario is not unrealistic IMHO (bug needs quick fixing, otherwise the company is losing money), but it shows how easy it is to get into a legally risky situation.

However if someone is concerned about this usage I explictly allow it.

Unfortunately, that's probably not enough. Even if you want to, AGPL requires any forks of SFTPGo to be licensed under AGPL. Once a company is in violation, anyone can sue them. It doesn't have to be you. That's also why lawyers don't want the risks of AGPL.

I agree with @matthewlenz that at the very least it's often a gray area which is also not a very good position from a legal standpoint.

I'm not trying to argue against AGPL, merely trying to share my experience/understanding why it poses risks and why companies generally don't like it (again, even if they have every intention to give back).

I'm also not trying to argue for dual licensing, but it's usually an accepted solution for the problem. It doesn't mean they can't contribute to your software anymore, but companies are protected from a legal perspective. And it's also a good source of income, probably more substantial than what sponsors would pay which is good for you and the project as well.

Hope that helps!

[drakkan]

@sagikazarmark what you say is correct. In summary:

• if you use unmodified SFTPGo even in a proprietary closed source product you have nothing to worry about but it would be nice if you could give something back to the project. This is a social expectation, not a legal requirement
• if you modify SFTPGo and use it in your closed source product you have to make your changes to SFTPGo public. The easiest way to do this is to fork SFTPGo and make your changes in a public repo

I'm not ready for a dual licensing option, SFTPGo is a project I work on, as individual, in my spare time and I want to stay away from legal issues. A poorly written commercial license could expose me to the risk of not being able to make public even trivial changes made for a company in a private branch and this does not have to happen, I prefer to give up some money (as I already did in the past).

[sagikazarmark]

if you modify SFTPGo and use it in your closed source product you have to make your changes to SFTPGo public. The easiest way to do this is to fork SFTPGo and make your changes in a public repo

The important thing here IMO is that you can get into a legally risky situation even if you don't intend to. Keeping a public fork from day one might not always be feasible.

I'm not ready for a dual licensing option, SFTPGo is a project I work on, as individual, in my spare time and I want to stay away from legal issues.

Yeah, I absolutely understand. I wish lawyers would contribute to open source sometimes to help projects with things like this.

[Simon818]

Licensing aside, I came here to look for an issue I was having and found this, so am now sponsoring. Not much, but it's something. I hope you get enough to make this project worthwhile; I find it really useful and haven't found anything else quite like it.

[drakkan]

Licensing aside, I came here to look for an issue I was having and found this, so am now sponsoring. Not much, but it's something. I hope you get enough to make this project worthwhile; I find it really useful and haven't found anything else quite like it.

Thanks, much appreciated, if each user donated a small amount like you did, there would be no long-term sustainability issues for the project ❤️