Development is not public about keepassium HOT 11 CLOSED

I can understand the intention but does the Apple Appstore not forbid these kind of forks?
So even if people would take your code, if you have already published your app in the AppStore, in theory Apple would decline the clones so they can not monetize it.

Yes, they forbid GPL forks on AppStore. Discovering this in October 2018 was exactly the nudge I needed to open-source the app.

But this is just theory. In practice, I will have to monitor the AppStore for copycats and try to recognize them behind the modified UI. Even worse, I would have to prove to Apple that a vaguely similar proprietary app contains my GPL-licensed code. Lawyer fees, stress... A closed-source project would have been much, much easier to protect and commercialize.

I think it would have been enough if iOS would allow to restrict Internet access for apps, like it is possible for Android, so there is no way your or any other app can leak data without the user noticing.

Yes, this would have made things so much easier: the app cannot leak anything, so you don't have to trust the developer. Unfortunately, this is not a magic bullet:

• If an app can open URLs, it can leak data via GET requests. For example, the app can open its changelog in the system browser. This is a bad user experience (need to switch back), but nothing too suspicious for most users.
• If an app can write files to shared storage/container, these files can be leaked by a companion app that has internet access.

In this case your app would have been much more credible then parts of it being open-source.

I would disagree with the "parts" part of your sentence. There are no missing assets or precompiled binary blobs. Even third-party modules are directly included in the code. As it is, this repository compiles into a fully-functional KeePassium app.

As for credibility, many people are perfectly happy with the "open source" badge. A few experts will actually audit and compile the code. The remaining few will not be happy with the badge nor willing to read the code. I don't really want to convince them — I would rather focus on building an incredible app (pun intended).

At the same time this is a one man project so if your priorities change KeePassium is gone.

Yeah, this is a frequent argument... against Bitwarden. But there is one important difference: KeePassium does not need servers. (MiniKeePass still runs just fine, right?)

I can see why MiniKeePass' priorities changed: the app was free-as-in-beer. For KeePassium, being a paid app is the best guarantee that it will be maintained. If the app is profitable and my priorities change, it seems fairly simple to hire someone else to work on the project. Otherwise, one just cancels their subscription and stops supporting a dead app.

If I get run over by a bus, there will be nobody to complain about eventual forks. (Only the copyright holder can file a DMCA takedown request.)

Of course this can happen to a publicly developed open-source tool like MiniKeePass too since the developers do not seem to have passed the access over to other interested parties but at least there is the option to take the code and release it under a new name.

Not really. Nobody may publish MiniKeePass fork on AppStore without their explict permission (see the first paragraph, about GPL forks).

You could add a policy though that if you do not want to continue working on this project anymore, that you publish the whole source code or something like this.

Well, the last time my priorities changed, I did exactly that: released a proprietary app under the MIT license. However, there is not much point in making this a commitment: people who need convincing are not my target auditory.

There are plenty of people who are stuck with an ugly or outdated app. They know exactly what they need and how KeePassium delivers that. I make KeePassium for them.

Anyway I wish you good luck with the project and will check it out as soon as it is released in the appstore.

Thanks!

from keepassium.

You are absolutely right: the development is not public.

KeePassium is a personal project. I am personally responsible for 100% of its development and prefer to keep it that way. The motivation behind this is stated in the first lines of the readme:

KeePassium is a commercial open source app. The "commercial" part gives you a well-maintained app with premium support. The "open source" part gives you the transparency expected from a password manager: you can personally audit the code and build the app you can trust.

Initially, KeePassium was planned as a proprietary app. I did not want to invest months of my life only to see somebody grabbing the code and publishing the app for free (this almost happened with KeePassB). However, releasing the source code was the only possible way to demonstrate clean intentions and make the app credible.

Eventually, I had to choose between transparency and commercial safety. That was not easy and evolved through most bizarre stages. In the end, I took the risk and chose transparency.

So, the purpose of this repository is to provide transparency. It is not intended to facilitate contributions or derivative work. That's why the commits are squashed, and comments and unit tests are scrubbed — all these factors do not affect the transparency, but improve project's chances of staying afloat in five years.

P.S. As a side note, I would be happy to make commits more fine-grained. But that would require applying a bunch of fork-deterring steps (mentioned above) to every single commit in dev before merging it to master. If anyone can explain how to do that, I will be happy to oblige.

from keepassium.

Initially, KeePassium was planned as a proprietary app. I did not want to invest months of my life only to see somebody grabbing the code and publishing the app for free (this almost happened with KeePassB).

I can understand the intention but does the Apple Appstore not forbid these kind of forks?
So even if people would take your code, if you have already published your app in the AppStore, in theory Apple would decline the clones so they can not monetize it.
Unless of course they change a lot of things but I am not sure how strict Apple is there.

However, releasing the source code was the only possible way to demonstrate clean intentions and make the app credible.

This is a general issue with the Apple Appstore because the builds are not reproducible or verifiable. I think it would have been enough if iOS would allow to restrict Internet access for apps, like it is possible for Android, so there is no way your or any other app can leak data without the user noticing.

In this case your app would have been much more credible then parts of it being open-source.

So, the purpose of this repository is to provide transparency. It is not intended to facilitate contributions or derivative work. That's why the commits are squashed, and comments and unit tests are scrubbed — all these factors do not affect the transparency, but improve project's chances of staying afloat in five years.

At the same time this is a one man project so if your priorities change KeePassium is gone.

Of course this can happen to a publicly developed open-source tool like MiniKeePass too since the developers do not seem to have passed the access over to other interested parties but at least there is the option to take the code and release it under a new name.

And do not get me wrong, it is not about money. I have donated 12 Euros to MiniKeePass in the past - because it was a great tool for my use case and I would have also bought it - but sadly the app seems to be gone for good.

You could add a policy though that if you do not want to continue working on this project anymore, that you publish the whole source code or something like this. This would make it easier to buy the app I think, especially if it is more expensive.

Anyway I wish you good luck with the project and will check it out as soon as it is released in the appstore.

from keepassium.

Thanks for the explanation.

from keepassium.

By coincidence, this morning I needed to reference a few lines in KeePass source code, but... could not find its repository.

A quick search discovered that KeePass — a one-man project, by the way — does not have a repository: Dominik simply publishes snapshots of stable versions. So, there's that.

from keepassium.

https://github.com/keepassxreboot/keepassxc :)

from keepassium.

@rdxmb , when someone asks about KeePass implementation details, it would be odd to cite KeePassXC instead :)
(Especially if they behave differently)

from keepassium.

BTW, starting from Feb 2021 commits are no longer squashed, for the sake of transparency.

from keepassium.

I see. I do only use KeePassXC - I did not know KeePass is still a project which is maintained.

from keepassium.

By coincidence, this morning I needed to reference a few lines in KeePass source code, but... could not find its repository.

A quick search discovered that KeePass — a one-man project, by the way — does not have a repository: Dominik simply publishes snapshots of stable versions. So, there's that.

I and several other people have resorted to maintaining our own repos based on the snapshot. I have a few customizations and getting the guy a patch is a pain since he doesn't have a public repository for some reason. I read his response and reasoning which isn't really a reason other than "I don't want to do it" and he also seems to think that doing so would impose some great burden of maintenance. I'm guessing he has never used github.

from keepassium.

he also seems to think that doing so would impose some great burden of maintenance.

Well, I kinda understand the "burden" part. Keeping a pristine public repo does take some time, especially for someone with mainly solo experience (speaking from my solo experience here :)

Merging a PR can easily take a couple of days. After all, a non-trivial PR is more of a suggestion, a shortest-path solution. The maintainer is still responsible for review, refactoring, considering edge cases, code style and testing. Plus, there is time pressure:

• either merge the incoming PR quickly (dropping whatever I was working on),
• or postpone, finish my stuff, and spend some time resolving merge conflicts later.

So the burden of maintenance is real...

from keepassium.