I recently tried to build .deb package and a PPA for Droidcam (turns phone camera into webcam), and mentioned it in a related GitHub issue for feedback.

The developer replied

I am going to ask that you NOT package and distribute a PPA. My stance in general is against 3rd party packages, all you're going to do is create more support emails for me down the line.

I know that in principle anyone can package it (due to its GPLv2 license) and it would save a lot of hassle for the users, but I also want to respect the developer's wish.

It is true that if not packaged correctly, there can indeed be issues with this program (the program requires certain kernel modules to be loaded in order to function), and I don't have much experience with packaging such complicated programs either. Right now, the PPA package works, but it has to be reinstalled after every kernel update. The developer provides a dkms installer to handle kernel updates, but the PPA package is not yet configured to use it. I asked the developer some questions about implementing the dkms installer in the .deb package, and got the above reply.

There used to be a PPA (whose code I modified to repackage it) in 2014-15, which soon died. I can see why the developer is frustrated with 3rd party packaging.

Of course, waiting for a more experienced person to package it is one option, but this software is there for almost 10 years, and the only way to get it is to download binaries from GitHub releases, and run ./install to load the kernel modules (the other way is to build the binaries from source and load the kernel modules). Many people (39) forked the debian source of the original PPA after it died, but it looks like no one made another PPA, or at least, provided a .deb package.

I wanted to know what is the standard practice for packaging useful free and open source softwares for Ubuntu or Debian in such cases, when the developer asks not to redistribute it in order to avoid hassle.

  • 26
    It sounds like this developer is politely asking you to consider alternatives that will help with his support workload.That's a legit request. But the license he granted does not compel you to comply with his request, and I suspect he knows it.
    – O. Jones
    Aug 14, 2020 at 16:12

6 Answers 6


This seems to happen again and again. Someone develops software, generously distributing it as free software, but doesn't fully understand the implications of giving their users the four freedoms.

There was a piece of free software that gathered data from various sleep apnea machines, the principal developer of which parted company with the entire community (warning: currently using an expired SSL certificate) after their desire for frequent, rough releases came into conflict with his desire for occasional, polished releases. The software forked, and development continues, but it's not a happy turn of events; the original developer finished his signoff with

Friends don’t let friends release full blown complex applications under the GPL

which suggests to me that he fundamentally didn't get what software freedom is all about.

The four freedoms are pretty well-known; I think it's wrong for anyone to release software that purports to give you those freedoms, and then to ask you to refrain from using them for their personal convenience.

In this case, I think the developer has a pretty good point about the support problems; I've run into similar problems with support for certain plugins for calibre, across the Python2/Python3 transition. But I think a more appropriate response to these concerns would be to have your package launch a dialogue on startup that makes it clear that the package they're using is unsupported by the app's principal developer, and that the user understands there is no point in troubling said developer about bugs in the packaged version. It's fine to have a check-box that prevents the dialogue from coming up any more, once the user has acknowledged their understanding.

Edit: some other answers and comments are reflecting on the perceived obligations of people who set out to release free software, some going so far as to suggest that you shouldn't do this if you can't commit to supporting it for a given period of time (possibly a long one). For what it's worth, I fundamentally disagree with them. If you feel moved to do something with free software, you should just do it, and release.

Users aren't entitled to support for any particular period of time, or with any particular combination of distro/toolchain/etc., or indeed at all. If your work proves useful to enough people, a community will likely arise to assist with the work, or to inherit it if you decide not to pursue it, and if it doesn't, it's not your fault. If one other person is helped by the work you've done, you may consider that work justified. No obligation to help that person for longer than pleases you, nor to help a second person, attaches to you as a result.

  • 2
    Yes, it's quite common to say that each distribution of software should support its own users, and that if you can't get adequate help from whoever you got your software from, that you reacquire or reinstall it from the official method in order to get help from the original authors. Aug 14, 2020 at 15:17
  • 18
    I'd argue the problem isn't so much that these software developers don't understand the Four Freedoms, but the users don't. Specifically, the software being free (~speech) doesn't in any way imply the maintenance being free (~beer). Aug 14, 2020 at 18:07
  • 9
    "I think a more appropriate response to these concerns would be to have your package launch a dialogue on startup" - ewwwww Aug 14, 2020 at 18:40
  • 15
    Unfortunately, the sad reality is that if OP releases this PPA, supports it for a year or two, then quietly vanishes (perhaps because they underestimated the amount of work required, because of a lifestyle change, or just because they don't want to do this anymore), then users will necessarily be going to the original upstream for support because they will have no other channels left. Third party packaging should only be done if you're really sure you can continue to support your release indefinitely, or provide a clear transition plan when you stop offering support.
    – Kevin
    Aug 15, 2020 at 2:49
  • 3
    "Users aren't entitled to support for any particular period of time, or with any particular combination of distro/toolchain/etc., or indeed at all." This should be set in 72pt size on every GitHub / Launchpad / Bitbucket project. :D Aug 17, 2020 at 13:47

I'm going to take a contrary position to some of the other answers here. To be clear: You have the legal right to make a PPA, with or without the developer's permission. But it might not be a good idea, based on what you have told us in your question.

Packaging and distribution is not easy to do. At an absolute minimum, you will be responsible for all of the following tasks:

  • Identify all dependencies and correctly list them in a format understood by the package manager.
  • Compile binaries in a format which is compatible with every architecture you intend to support (possibly just x86_64, but Debian at least supports many other architectures, and users will expect them to work).
  • Make point releases for security vulnerabilities.
    • Some upstreams don't provide a "stable" version, so you might need to backport these fixes yourself.
    • If the upstream is hostile to your package, they may not give you any advance notice that they are about to drop a security fix, and nobody else will tell you either, since security vulnerabilities are traditionally embargoed until a fix is available. Your users will be vulnerable until you find out about the vulnerability and do a point release.
  • Test your packages and ensure that they work correctly under a wide variety of conditions.
  • Handle incoming bug reports, determine whether they can be reproduced, and if appropriate, forward them upstream.
  • Continue to support the PPA for an extended period of time. Suddenly dropping support after a year or two will potentially inconvenience a large number of people.

Based on some of the wording of your question, I am not totally convinced that you are prepared to do all of these things:

  • You admit that you "don't have much experience with packaging such complicated programs".
  • You needed to ask the upstream for advice on how to package their software.

Under the circumstances, I would advise that you should not proceed with making a publicly-available PPA, unless it is clearly marked as "no support, use at your own risk" or similar. If there really is a downstream community that wants to use this software on Ubuntu, I would suggest you try to get it added to the universe repository instead, so that the whole community can be collectively responsible for it. To do this, of course, someone will need to become the maintainer, and that person might end up being you, but there will at least be a reasonable process for someone else to take over maintainership if you leave the community.

  • 4
    This. From a Debian Developer's perspective, the packaging itself is the easy part, but if the package ever goes into a stable release, this means supporting users who stay on that particular upstream version for three years. The Debian bug tracker used to be the first point of interaction, but nowadays users seek out original authors and contact them directly, so the author needs to be at least aware that Debian is likely to be shipping an older version. With PPAs you get variable quality, and their introduction in Ubuntu was controversial at that time. Aug 15, 2020 at 7:34
  • "You have the legal right to make a PPA, with or without the developer's permission" -- well no, you don't have that at all without the developer's permission. Not specifically permission to make a PPA, but permission to create and distribute a derivative of the developer's copyrighted work. And that's the rub. Licenses accepted as "free and open source" convey permission to do those things to the licensee, so it's not that they don't need permission but rather that they already have it. Aug 15, 2020 at 18:21
  • 13
    @JohnBollinger: The OP has already said the software was under GPLv2. I do not see the point in repeating that fact in my answer, so I will not be changing that sentence.
    – Kevin
    Aug 15, 2020 at 18:33
  • Worth noting that trying to get the package added to the universe repository is not a substitute for finding a dedicated maintainer, and indeed it will likely not be accepted into the universe repository without one. Of course if what you meant by this was "identify a dedicated maintainer, or a small team of people willing to dedicate some time to its maintenance, and get them to spearhead the effort to get the package into universe", then this is a good approach.
    – James_pic
    Aug 17, 2020 at 13:41
  • 1
    @James_pic: Thanks, added a brief note about that.
    – Kevin
    Aug 17, 2020 at 15:34

There probably is no generally accepted way to handle a situation like you describe; the best answer and course of action always depends on the individual case.

On the one hand it's good to have a package available as easily as possible - but as a maintainer it's very much desirable to have them on a reliable basis which will last some time and create the least friction and work possible.

As such my recommendation is: in your fork of the repo, create a way to automatically update the PPA from the sources. As the repository lives - by your question - on GitHub: Make use of GitHub Actions as a CI tool which creates artifacts for each push and each tag (release) - or however the workflow of that project works in detail. And make this work available to the maintainer of the original repo as a pull request. Offer him to do the necessary setup work for the CI which cannot be done by the PR alone. I'm not familiar with PPAs themselves - if they need a specific deployment method to allow distribution, that can be integrated in the GitHub Actions, too.

Additionally or alternatively you could want to look at "real" package building, thus provide the necessary files to allow building a *.deb and/or *.rpm from the repo. That means you actually have to look through building a first-class debian or rpm package which can henceforth be natively built and distributed by the linux distributions themselves.

Such course of action has some advantages:

  • it makes the actual work to create the PPA for subsequent releases a piece of cake
  • it shows the maintainer that you care about his/her time and ressources. It's an approach which might even work for him/her sustainably, even in case you lost interest after 6 months. And exactly that might be one of his fears in starting support for another distribution method - a support s/he has to provide for every transient distribution channels whenever and whereever it pops up. Take and remove that fear, offer real and lasting value for no additional work to the mainainer.

There is a lot of ressources to setup this kind of thing. The one I'm somewhat yet still only remotely familiar with is the OpenTTD CI/CD pipeline which lives completely in our GitHub repositories and builds packages from the main repo for different OS and OS versions automatically. It might offer you some reference how such task can be addressed (see also its repos for hooks, actions and workflows).

  • Not having much experience with packaging, I was shipping the release tarball containing the prebilt binaries in the deb package, and provided the source along with it (in principle, one can generate .deb package from source without providing binaries, but this program has build dependencies which are not available in debian repositories, so that will be complicated). This way, to provide an update, I will have to change the release tarball in the debian source, change version number, and upload it to Launchpad. I am not sure if GitHub actions can do something like this. Aug 14, 2020 at 6:58
  • They can. They are a full ci/CD solution (see my last paragraph). At least when combined with azure pipelines, but might be without meanwhile Aug 14, 2020 at 7:01
  • 5
    I believe it's poor debian packaging practice to package things which have not been built yourself - you have even less idea what's in them.
    – pjc50
    Aug 14, 2020 at 14:09
  • Not sure what statement you try to counter. Nowehere anyone said to distribute builds from 3rd-party sources and build services. Yet, it's good practise to have you CI build the packages and thus quickly detect problems - on build service you control. This way it easy for the actual debian maintainer to maintain the package - not much work then needed anymore. It's not like debian doesn't build them on their own CI, too. Aug 14, 2020 at 15:09
  • planetmaker I believe pjc50 was responding to this bit from ArchismanPanigrahi: "I was shipping the release tarball containing the prebilt binaries in the deb package". Even if the original developer provides binaries, it's usually expected that Debian packages are built from source.
    – muru
    Aug 16, 2020 at 3:47

One way to deal with such a request is to treat is as a "please respect my trademark" request. You create a fork of the complete project, give it a new name and you make it clear that you are the maintainer of this fork and not the person maintaining the original project.

After having done that, you can take your fork in any direction you (and the community that might build around it) want. You can also continue pulling improvements from the original project into your fork.

All of this is fully allowed by the GPL license and should alleviate the fear of the original maintainer for additional support emails as those should all come to you instead.

  • 4
    That seems like taking too much credit when all you're doing is packaging, not really maintaining a true fork of the project and working on its non-packaging code. You'd still want users to know it was just packaging for the same program they can get a different way, otherwise it may create more confusion about whether this version is different. In the general case where you do want to take over fully maintaining a fork, this is good, though. Aug 14, 2020 at 17:54

This is a great question because it comes up a lot and might seem like a bit of a free for all, but there are ways to be a bit objective in answering! I will try to do this by sharing with you approaches that I have seen to be successful, and basing what I say on documentation and policy where it exists.

I don't know that there is a "standard" practice here. You're fundamentally asking about cultural norms, not legal interpretation (which you already know).

So it helps to think about responsibilities. This is where many open source developers experience conflict and express defensiveness. They want to help people, and have their package be used. But if they get burnt out or overwhelmed (PDF), they can't achieve that.

You have a responsibility to the users of the package (Ubuntu and probably Debian users) not to mess up their system, to provide useful software, and to respect their rights. You have a responsibility to Ubuntu and Debian not to decrease the quality and perception of their distribution. You have a very similar responsibility to the developer of the source package, plus to respect their time and effort. (The latter is what they've explicitly warned you about.)

(How did I come up with this list? Partly by reflecting on projects I've participated in, packages I've created, operating systems I've used... but also by repeated reading of the documents I link to, research on open source communities, and developer articles/blogs.)

The developer in question might be more likely to accept your offer and provide help if you can demonstrate that you are aware of these responsibilities. (They might not be, I don't know them.) You don't have to fulfill them all! But if you think about your actions in terms of them, you will probably have better luck.

So how can you, or others in a similar position, proceed? Well, let's work backwards.

How do you demonstrate that you respect the developer's time and effort?

  1. Make it clear that you're a regular user of the software, and that you're "dogfooding" it ie. installing your own packages, from your own PPA, using it regularly — then they know you'll be the first to notice the most prominent issues. See below.

  2. Contribute to the project! File issues, provide detail, do a bit of debugging yourself. Fix bugs if you can, small ones at first. Improve documentation. Help out with issue tracking and user support if you're able.

  3. Document what you do! If, for whatever reason, you have to stop then good documentation means that there's a much better chance of someone else picking up the PPA maintenance. Here's a sample of what I mean, from when I left RabbitVCS. Share your config files. Your tips. Your bookmarks. Everything. As you go.

  4. Hey, now that you've documented it... you could maybe document it in code form! That is, automate it!

Seriously, there is a world of difference between some random person asking for help with a PPA, and a regular helpful contributor proposing one. Random person: could increase a developer's workload. Regular: shares workload, improves quality, attracts more contributors into the project.

How do you demonstrate that you respect your distribution and their community?

  1. Read the packaging docs! Ubuntu is closely based on Debian, so start with the Debian Policy Manual and the Debian Developer's Reference. Yes, they're dense reading material. You don't have to memorise the whole thing, skim it, skip to the parts you need at first, and become familiar with it.

  2. Search the web for other packaging guides eg. this series on Debian/Ubuntu packaging with Docker. It's important that you take in the underlying philosophy: build packages from source, in a clean environment so that you (a) know for sure the package is open source and buildable from scratch! and (b) you know you have all the dependencies, requirements, etc. Another tool for this is PBuilder (see also Ubuntu's PBuilder HowTo although I think that's gone by the wayside a bit.

    In particular, this comment of yours is somewhat contrary to that philosophy:

    I was shipping the release tarball containing the prebuilt binaries in the deb package, and provided the source along with it

  3. Build some simple "hello world" style packages first. One that's just a single file C program. Look at how other packages are done, especially DKMS packages. Make changes to them yourself. Use them as a starting point.

How do you respect your users?

  1. Be one. It sounds like you are, great! But do you use every feature? Do you test installation on all the systems you distribute for? Use VMs, even for kernel packages you can at least test that your package installs properly!

  2. Make it clear how to get help, and who from. Users don't want an annoyed response from a developer any more than the developer wants to deal with bug reports for something that's not their problem. Make sure the Launchpad site for your PPA has the relevant features disabled if you're not going to use them. (Seriously, I have lost count of the number of times I've asked a question on Launchpad for a PPA package only to have it ignored for years.)

This might seem like a lot. But don't despair! As I said above, you don't have to do everything, but you should (a) do and commit to at least some of these things, (b) be aware of them (or, if you disagree with them, your own set).

Finally, remember your responsibility to yourself as well! You are a developer too — set your own boundaries, be realistic about what you can commit to, and watch yourself for burnout. Be kind to yourself, and if you can't work on a project in a way that makes you happy, maybe it's time to move on.


If it's purely open-source software "the developer" has no rights.

If "the developer" has built upon free or open-source software, the builder/developer has rights to what was built/developed but nothing else.

  • This is not true - as the owner of the intellectual property, he is free to set up the limits, how his product will be used. For example, he can simply forbid the redistribution. Although it is another story, how could that software be called "free".
    – peterh
    Aug 15, 2020 at 7:07
  • 1
    @peterh - Reinstate Monica Doesn't Asking how that software could be "free" show you're not talking about "free and open-source software"? Of course the owner of any intellectual property is free to set limits, most obviously forbidding redistribution. Which are you talking about: the developer of the original, now open-source SW, or the developer of something new, based on that OS SW? The OQ seems to confuse itself the same way, so at least you're not alone. Aug 15, 2020 at 22:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.