Launchpad wiki contains zero information regarding running launchpad on your own domain

Bug #786212 reported by Sorin Sbarnea on 2011-05-21
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Launchpad itself

Bug Description

Currently the launchpad wiki does not provide any information regarding how to install a public launchpad instance.

Even the page that is supposed to provide guidance regarding this only describes how to move host files from one machine to another and not even mention how to change the domains used by launchpad.

I do not ask for a detailed guide but at least some basic information regarding where to change the tons of `*` domains.

Sorin Sbarnea (ssbarnea) on 2011-05-21
description: updated
Curtis Hovey (sinzui) wrote :

Launchpad's code was opened to permit the Launchpad community to contributor to the project. The information provided is the same information used by Launchpad developers. Artwork in the project may only be used for development, so instructions to run a public instance of would put the contributor in violation of the license.

The launchpad team dos not maintain the production configurations of Launchpad, they do not know exactly how to setup an other instance.

Changed in launchpad:
status: New → Won't Fix
Karl Fogel (kfogel) wrote :

Instructions on running a public instance would not put anyone in violation of a license -- those instructions would simply need to include instructions for replacing the images. But I see no reason why Canonical should provide those instructions: helping other people run public instances is not Canonical's goal, and Canonical has always been very clear about that as far as I can tell.

Open source means "you can fork it". It doesn't mean "other people are obligated to share your goals" :-).

By the way, I'm personally in no way opposed to public instances of Launchpad going live. I just don't think Canonical should be faulted for not supporting that -- there's no reason they should, and it's entirely consistent to open source the code and yet still not make any effort to support other instances. It may be an unusual approach, but it's still open source.

-Karl (speaking only for myself)

It's not a matter of license, but a matter of whether it feels like they care about your freedom. Take for example these parts taken from the Free Software Definition:

"The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1)."

"Freedom 1 includes the freedom to use your changed version in place of the original. If the program is delivered in a product designed to run someone else's modified versions but refuse to run yours — a practice known as “tivoization” or “lockdown”, or (in its practitioners' perverse terminology) as “secure boot” — freedom 1 becomes a theoretical fiction rather than a practical freedom. This is not sufficient. In other words, these binaries are not free software even if the source code they are compiled from is free. "

LaunchPad is clearly a dirty corner case: The wording doesn't clearly say it breaks the rules, but in practice you can't run your own instance. It's not WONTFIX, it is WONTCARE. LaunchPad team could easily make it easy to run, just like so many other services- but clearly they don't want you to run an instance, and their decisions make it so difficult nobody does it in practice.

If you're fine with Canonical not caring about decentralization and true in-practice software freedom, that's fine. But I do care, and I want to work with people who are real friends, not ones who pretend to be. How can someone call their distro UBUNTU and still provide the code in a way *intentionally* making it practically impossible to run an instance?

(By the way, Karl, aren't you the writer of Producing Open Source Software? Great book.)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions