What is the standard practice when the developer does not want third party redistribution of a certain free and open source software?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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).

Answer 4

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.

Answer 5

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.

Answer 6

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.