Author here. The experiments actually ran BorgBackup 1.1.0b6 as you can see from the Setup section. We liked to call it Attic out of the respect to the original Attic author.
I noticed that, but didn't know if Borg has another meaning. I can understand why they forked the project, but in my opinion a name that makes the origin more obvious would have been better.
The FSF's definition of "Free Software" doesn't necessarily match the English language's definition of "free software". Since we're speaking English, I think it's reasonable to assume the latter meaning, like most reasonable people who haven't encountered the FSF would.
I really wish people would capitalize things like this. "This is not Free Software" would make the sentence unambiguous. You can't just go around redefining the English language willy nilly and expect people to play along.
Languages do evolve naturally but this isn't natural. This is an organization trying to influence the language to advance an agenda (though I believe it to be a worthy agenda, it's still an agenda).
If the commenter meant no cost it's more reasonable they'd have said "It's a shame Duplicacy is not free". Or "It's a shame Duplicacy costs money".
Capitalising would have made it clearer yes, but I think given the language and the context (hacker news) I was justified. But the author, @acrosync, was also justified in assuming it meant no cost.
Free or not free aside, my question is, does it matter to personal users between this free-for-personal-use license and any of those more permissive licenses like MIT, BSD, or GPL?
It matters to me as a personal user because my use of duplicacy might change at some point and suddenly I'd lose rights to use it (unless I pay). I'd lose rights to any development contributions I might have made unless I pay.
And as a personal user, I can't use any code from Duplicacy in any other project. I can't even, say, create a package for it and get it included in Debian.
And aside from some of these practical issues, I'm a personal user who supports software freedom so I don't want to use something encumbered in this way.
And as a commercial user, any development contributions I make are no longer my own and I have to pay to make use of them.
But the worst part of it is, your license isn't very well defined. As it stands, you may at any point stop accepting license payments from a commercial user and they'd lose the right to use it entirely - they'd lose access to their backups (unless they used the software without a license).
You of course have the right to choose any license you like! I just wouldn't use duplicacy myself under the terms of that license.
Thanks for your feedback. The reason I don't like open-source licenses is that I don't want for-profit companies to use my software without paying. The ideal license would be the one that requires them to pay while being appealing to personal users like you. I don't think these two goals are irreconcilable, but unfortunately such a license doesn't exist yet.
I did wonder if being fully free might encourage more users who might fund you in other ways but Borg backup isn't making very much like that, so perhaps not: https://www.bountysource.com/teams/borgbackup
The AGPL license might be a step in the right direction (for your requirements). It aims to at least ensure that if companies use the code to provide a service to other users, they have to release their changes. You can sell those companies a different license if they don't want to accept the AGPL (you'd have to have a contributor agreement to assign copyright to you though, to allow you to relicense code at your discretion like that).
Or there is the open core model (like nginx-plus), where you provide the code under an open source license but provide some additional "enterprise" features (like your vmware stuff) to only those that pay. I'm not a fan but it seems to work for some.
Anyway, duplicacy sounds a great design. All the best with it!
From a practical standpoint, it makes it more difficult for me to trust that it will be maintained in the long-term, or that I can extend its functionality if I see a need.
Ideologically, I'm somewhat uncomfortable using duplicacy when fully-free alternatives exist. I'm not a free software purist by any definition (I use steam. I have a Netflix subscription. My android has google apps on it.), but this is an area where compelling free software solutions do exist.
The license also keeps it from being packaged in most Linux distributions, which makes it a nuisance.
I hate switching backup software, and with your current license, you become a single point of failure--will you be supporting this thing in 10 years when I need to back my FireflyBSD 128-bit RiscV machine up to the walmart cloud (or whatever random os/hardware/cloud is common in a decade)?
If this were BSL licensed, the community could fork it if that became an issue:
I'm curious to see whether any BSL software manages to build a third party dev community (inclusion in debian non-free, third party patches and bug reports, etc)
While I have your attention: It'd be great to measure how many bytes the solutions read and write, as well as I/O counts. There are tools for this in Linux, and probably MacOS. Alternatively, network bandwidth would be a good proxy for these measurements.
We use a pack-and-split approach -- files are packed first (as if it is building a big tar file first, although this is only conceptual) and then split into chunks using a variable-sized chunking algorithm. You can customize the chunk size but by default the average chunk size is 4MB so you won't be uploading too much small files.
I agree the name is confusing, however this is not intentional. As I explained in the other comment, I chose duplicacy because the domain name was available and this is a very good name for a backup tool (even better than duplicity).
I chose this fair source license because this is basically the only free-for-personal-use license. Many people here ask why I didn't go with a free license like GPL. Here is why. I believe software should be free for personal users, but I don't like for-profit companies using it for free. This software can potentially help companies solve a painful everyday problem (and therefore make more money) and yet there isn't a license to require them to pay if they don't distribute the software. In my opinion, this is extremely unfair to independent developers like me.
Naming chunks by their hashes is not a new idea, but this technique along does not give you a practical backup tool. The deletion of unreferenced chunks becomes a hard problem, and the center piece of lock-free deduplication is the two-step fossil collection algorithm that solves this hard problem.
I might be wrong but I want to hear more from you if you're a Borg developer. My understanding is that you may be able to have multiple clients uploading chunks at the same time, but you won't be able to exploit cross-client deduplication if different clients have a similar set of files (OS files or a large code base for instance). Moreover, if your implementation require locks then it would be very hard to extend to cloud services.
Yes, that's right, concurrent addition of the same chunks would generally mean that some work is wasted; so concurrent long running jobs would not synchronize well in this model, and lock-free performs clearly better there.
The only operation which inherently has to be guarded by a lock in Borg is inserting the archive pointer into the manifest (root object, see https://borgbackup.readthedocs.io/en/latest/internals/data-s...). I suppose it would be possible to work around that without locking or to use the usual hacks around EC, put/get/check/get/check?put/get/check?put etc. until it's "probably there".
Deleting / pruning archives would still require a full lock due to the same conceptual issues that your two-phase GC avoids. The same goes for "check".
I think Amazon only blocked rclone's application key for Amazon Drive. There is no way for Amazon to prevent a third-party application from accessing S3, since users provide their own S3 credentials and Amazon doesn't know who is on the other side.
I didn't want to sound like duplicity intentionally, but duplicacy.com was still available at that time and I thought it was a perfect name for a backup tool...
For what it's worth, I thought this was Duplicity until I read the comment even after I did a quick glance at the github repo. Since you're both in backup, this is going to be very confusing to people.
Edit: Come to think of it, it seems quite funny how many backup solutions are named akin to this, while, under the hood, they actually go through great lengths to actually get rid of duplicates. Maybe a name deriving from "condensing" or "shelving" would be more accurate? ;-)
