Missing licence (and possibility of proposing it to upstream?)
PriceChild opened this issue · 4 comments
I can't find a LICENCE for this project - would it be possible to arrange this to clarify the status of reuse & contributions? (May require agreement from all contributors?)
Slightly relatedly, I would love to see this functionality merged into the upstream project and perhaps a PPA maintained for it's Ubuntu users. I suspect it would be preferable to maintaining a separate project and is definitely a goal I would like to contribute effort to.
I haven't approached upstream yet as to whether they'd be interested in accepting this work, or the idea of a ppa in addition to docker etc. Given their GPL v3 status, approaching the licence question in this project first is likely the important first step if it wouldn't be starting from scratch.
I agree with you that it would be a good thing to have a licence for this project.
As far as your idea of bringing this upstream is going, don't get your hopes up too high.
They are not really intereseted in platformspecific packaging, thats why projects like this exist in the first place.
However, it would be indeed a good thing to have repositories for bitwarden packages.
The best solution would be to use SUSE-OBS since it can build packages and publish repos for every distro.
But thats a lot of work since most people use docker anyway.
Thanks for bringing this up @PriceChild , indeed a clear license is necessary. I'll open a PR and try to get every contributor's approval.
As for the upstream thing, this is another issue, but here are some details:
When I first needed a Debian package, I found it easier to leverage docker to build a deb package since Debian is not my primary OS.
But I'm not satisfied with this hackish bash & patch thing, which is why I never proposed it upstream.
Now, we have to distinguish between providing a tool to build Debian packages and providing packages themselves.
This very repository aims to provide an easy way to build packages for yourself.
Until now, I attached packages to each release, but that's a mistake: you should never trust a random binary from the Internet.
Building and distributing packages should be done properly, that means a proper chain of trust (package signature, etc).
I don't have enough resources to build and maintain such a system.
My understanding is that upstream neither, since the kinda official way to run the app is through docker, and every other packages are 3rd parties.
@Masgalor do you have experience with OBS? I understand this can help automate package building for both RPM & Deb distributions.
I also had some success with cargo deb (and I guess there is cargo-rpm too). That would help but requires upstream modification (the tool rely on cargo.toml metadata).
@greizgh I have very little knowledge about OBS.
I did never maintain a project there myself, but I contributed to some projects using it.
Building and distributing packages should be done properly, that means a proper chain of trust (package signature, etc).
This is definitly true, and also the reason why I think OBS is a good fit, it simply takes care about anything from building to publishing. But I have neither the time nor the knowledge to get this done.
Project is now properly licensed, so I'm closing this issue.
Regarding OBS and package distribution, feel free to open a dedicated issue or propose a PR.