Migration from Launchpad

Asked by Dr E on 2020-12-05

We are interested in migrating a project away from launchpad to another publicly available site. Migration of the code repository has already been completed, but we have some doubts about the migration of the rest of the content we have in launchpad. We would like to preserve some of the content that was produced in launchpad, but we don't want to leave the launchpad project open to prevent users (and search engines) from landing in a page where our project is no longer active.

1) Is there a tool that we can use to extract all the contents of our project (mainly Bugs, Blueprints and Answers) as csv or xml (or another format for structured information)? How would that work?

2) Would it be OK for us to host elsewhere contents first provided by our users on launchpad? What is the license under which such contents are published on launchpad? It's not clear on the legal page of launchpad (in contrast with, e.g., StackExchange, where it is easy to find in https://stackoverflow.com/help/licensing that contents are distributed under a CC BY-SA).

3) What are the options for having individual sections of the project (Bugs, Blueprints, Answers, etc.) or the whole project blocked (to prevent further contributions)? The only way we seem to find is to change back section settings to "Unknown" or "External", instead of "Launchpad.

4) If we disable a section (say, Answers), are each of the question threads deleted from launchpad, or does that only remove the index from our project site, with all the Q&A contents remaining accessible indefinitely via their direct URLs?

5) Is it possible to completely delete sections or the whole project? How could we accomplish that?

Thank you very much for your help.

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Colin Watson
Solved:
Last query:
Last reply:
Revision history for this message
Dr E (ilikedebs) said :
#1

These questions have gone unanswered for over a week. Would it be possible for somebody from the Community or from Canonical to answer any of them, please? Thank you.

Revision history for this message
Best Colin Watson (cjwatson) said :
#2

1) We don't have a stock tool for this, but most things are exported via Launchpad's webservice API, so you should be able to write something to extract what you need. See https://help.launchpad.net/API/launchpadlib for details. If you find yourself with specific questions about this then we can help with those.

2) It is true that we don't require users to contribute comments and similar under something like CC BY-SA, perhaps unfortunately; so we can't give you an authoritative answer. My personal view would be that simply moving things verbatim to a different hosting site is very unlikely to be a problem, but I don't think we can give you a legal answer here (while we do have a legal team, this is probably the sort of thing where you'd want somebody acting for you in case of doubt). Sorry.

3) Changing back the section settings as you suggest is the only mechanism available at present. It's not a perfect block to further contributions (IIRC there are a couple of unintentional loopholes), but it does for example mean that attempting to report a new bug results in a page saying "<project> does not use Launchpad as its bug tracker" rather than letting you report a bug.

4) It disables indexes, but doesn't disable access via direct URLs.

5) We can deactivate a project administratively on request, after which even direct URLs won't work.

Revision history for this message
Dr E (ilikedebs) said :
#3

Thank you very much for your answers.

I think the easiest (and safest from the legal point of view) path to follow would be to disable the sections from Launchpad (keeping the contents in Launchpad), and to generate static tables of contents for the sections (using the webservice API) that we would host on our site.

Would it be possible for you to disclose the "unintentional loopholes" you mentioned in your answer to 3) (no necessarily in the open), or to clarify whether we would be exposed to them if we followed the strategy above? In particular, after disabling the sections, would users still be able to add comments to existing threads, or to create new threads starting from old threads?

Thanks.

Revision history for this message
Colin Watson (cjwatson) said :
#4

I don't have a definitive list, just things I've noticed in the past that lead me to believe that some edge-case bugs may exist, probably along the lines of being able to file bugs or add bug tasks via URL editing. We don't consider this to be a hard security boundary: the settings for where bugs should be filed are really meant more to guide users towards somewhere where their report is most likely to be read, rather than something that's vital to enforce.

It is the case that, even if bug tracking is disabled for a project, people can still add comments to existing bugs filed against that project. This is hard to avoid due to the nature of Launchpad's data model: a bug is only attached to a project via a bug task, and a bug can have many tasks, so there wouldn't really be a coherent way to disable that sort of thing even if we wanted to.

Revision history for this message
Dr E (ilikedebs) said :
#5

Thanks Colin Watson, that solved my question.