launchpad development|
Size: 3197
Comment:
|
Size: 4458
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 16: | Line 16: |
| '''Summary:''' This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. Mention tables being created. | '''Summary:''' This specification describes how sourcepackage licenses will be stored and tracked within Launchpad using the new debian copyright format. See http://wiki.debian.org/Proposals/CopyrightFormat for more information. |
| Line 18: | Line 18: |
| '''Goal/Deliverables:''' Extract and store as much information as possible from the new machine readable copyright format when it's used. | |
| Line 19: | Line 20: |
| '''Goal/Deliverables:''' What do we plan to achieve and what actual things will be released/deployed? | '''We will know we have finished when the license relationships expressed in the new copyright format are stored and accessible after a sourcepackage upload is processed.''' |
| Line 21: | Line 22: |
| '''We will know we have finished when ...''' - complete this sentence and leave in bold format. {{{ e.g. We will know we have finished when we have basic pages in Launchpad on login.launchpad.net that allow someone to do the workflows outlined in the UI Mockups spec.}}} |
|
| Line 27: | Line 25: |
| This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the first part of our release change log. | This basic implementation will enrich the Launchpad sourcepackage model with all the copyright information provided by the packager. Once it's completed other subsystems will be able to deal with sourcepackages according to their licences. |
| Line 29: | Line 27: |
| It is mandatory. | |
| Line 33: | Line 30: |
| This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. | Licenses are not well represented at the sourcepackage level. It's currently very hard to extract that information and consider licences as an attribute of the package itself. It's about time to allow developers to equate licences issues properly in their packages and allow users to browse/query packages considering this aspect. |
| Line 37: | Line 34: |
| This section should be a bulleted list of use cases which also include the user experience. Try to address who would use this, how they would use it, and what advantage it would be. | * John, a developer, has packaged a new upstream source and should be able to express all the licenses involved in his package for uploading it and would be very happy if all his efforts are visible in the Launchpad UI. * Richard is a strong GPL-v3 advocate, and to prove his point, he want to produce a report of all sources currently published in ubuntu/jaunty which contains GPL-v3 license code. * Romeu, a release manager of a distribution hosted in Launchpad, wants to audit all the sources published in his release and decide, based on their licenses, which sources can be redistributed on their mirrors. * Juliet, a package reviewer, should be able to inspect the licenses involved in a new source uploaded to ubuntu before accept it. * Ruben, an user, wants to find a ERP application already packaged in ubuntu and licensed under a GPL-compatible license, so he can start to implement his free extensions to it. * ... |
| Line 41: | Line 44: |
| A list of assumptions should go here. This should include any assumptions about the users, the workflow, the implementation, the system this will reside on, the hardware requirements, access, etc.. Note that these are assumptions that everyone should believe are "business as usual". If you find yourself writing things which aren't, they are requirements and should be documented in the Implementation section below. | 1. The ubuntu and the debian community are happy with http://wiki.debian.org/Proposals/CopyrightFormat specification; 1. There is no major different (pattern-wise) between the debian format and the RPM proposal (see http://fedoraproject.org/wiki/Packaging/LicensingGuidelines); 1. This specification will focus in storing a comprehensive set of data that represents what is encoded in the debian/copyright file. No UI features have to be delivered yet. 1. ... |
| Line 45: | Line 51: |
| This section should cover changes required to the UI, or specific UI features that are required to implement this. | None, see '''Assumptions''' |
| Line 49: | Line 56: |
| This section should describe a plan of action (the "how") to implement the changes discussed. This could include subsections in addition to what is provided in this spec template. |
|
| Line 53: | Line 58: |
| Code changes should include an overview of what needs to change, and in some cases even the specific details. | The `debian/copyright` content is already stored during upload processing as part of the NascentUpload workflow. That step of the code should be extended to also parse the copyright content in a intermediate object (probably reusing or current RFC-822 parser) to allow the SourcePackageReleaseCopyright records to inserted later, at the same point we actually create the SourcePackageRelease. |
| Line 57: | Line 64: |
| What Database changes are you proposing? Do you need a new index created? Proposing a new table? If so, what does it look like? | * SourcePackageRelease table new fields: * copyright_format_url: Text (valid_url); * upstream_name: Text; * upstream_source: Text (valid_url); * SourcePackageReleaseCopyright (new table): * sourcepackagerelease: SourcePackageRelease FK; * license: DBEnum License; * file_glob: Text (fti); * copyright_note: Text (fti); * copyright_holder: Person FK (may be null on copyright_note without email address); |
| Line 61: | Line 78: |
| Include: * data migration, if any * redirects from old URLs to new ones, if any * how users will be pointed to the new way of doing things, if necessary. (If your change is big enough, consider using the [[ReleaseCycles/RollOutTemplate|rollout template]].) |
Since the new copyright format isn't being used yet, no migration is required. However if the deployment get late and sources using the new format get uploaded, the original `debian/copyright` content is being stored in SourcePackageRelease and could be easily re-processed. |
| Line 68: | Line 85: |
| In this section list out any issues which are unresolved and will impact or block the implementation of this spec. | None, so far. |
Contents |
SourcePackage licenses
Overview
Launchpad entry: https://blueprints.edge.launchpad.net/soyuz/+spec/sourcepackage-licenses
Created: 2008-12-01 by CelsoProvidelo
Contributors: JulianEdwards
Overall Summary
Summary: This specification describes how sourcepackage licenses will be stored and tracked within Launchpad using the new debian copyright format. See http://wiki.debian.org/Proposals/CopyrightFormat for more information.
Goal/Deliverables: Extract and store as much information as possible from the new machine readable copyright format when it's used.
We will know we have finished when the license relationships expressed in the new copyright format are stored and accessible after a sourcepackage upload is processed.
Release Note
This basic implementation will enrich the Launchpad sourcepackage model with all the copyright information provided by the packager. Once it's completed other subsystems will be able to deal with sourcepackages according to their licences.
Rationale
Licenses are not well represented at the sourcepackage level. It's currently very hard to extract that information and consider licences as an attribute of the package itself. It's about time to allow developers to equate licences issues properly in their packages and allow users to browse/query packages considering this aspect.
Use cases
- John, a developer, has packaged a new upstream source and should be able to express all the licenses involved in his package for uploading it and would be very happy if all his efforts are visible in the Launchpad UI.
- Richard is a strong GPL-v3 advocate, and to prove his point, he want to produce a report of all sources currently published in ubuntu/jaunty which contains GPL-v3 license code.
- Romeu, a release manager of a distribution hosted in Launchpad, wants to audit all the sources published in his release and decide, based on their licenses, which sources can be redistributed on their mirrors.
- Juliet, a package reviewer, should be able to inspect the licenses involved in a new source uploaded to ubuntu before accept it.
- Ruben, an user, wants to find a ERP application already packaged in ubuntu and licensed under a GPL-compatible license, so he can start to implement his free extensions to it.
- ...
Assumptions
The ubuntu and the debian community are happy with http://wiki.debian.org/Proposals/CopyrightFormat specification;
There is no major different (pattern-wise) between the debian format and the RPM proposal (see http://fedoraproject.org/wiki/Packaging/LicensingGuidelines);
- This specification will focus in storing a comprehensive set of data that represents what is encoded in the debian/copyright file. No UI features have to be delivered yet.
- ...
User Interface
None, see Assumptions
Implementation
Code Changes
The debian/copyright content is already stored during upload processing as part of the NascentUpload workflow.
That step of the code should be extended to also parse the copyright content in a intermediate object (probably reusing or current RFC-822 parser) to allow the SourcePackageReleaseCopyright records to inserted later, at the same point we actually create the SourcePackageRelease.
Schema Changes
SourcePackageRelease table new fields:
- copyright_format_url: Text (valid_url);
- upstream_name: Text;
- upstream_source: Text (valid_url);
SourcePackageReleaseCopyright (new table):
sourcepackagerelease: SourcePackageRelease FK;
- license: DBEnum License;
- file_glob: Text (fti);
- copyright_note: Text (fti);
- copyright_holder: Person FK (may be null on copyright_note without email address);
Migration
Since the new copyright format isn't being used yet, no migration is required.
However if the deployment get late and sources using the new format get uploaded, the original debian/copyright content is being stored in SourcePackageRelease and could be easily re-processed.
Unresolved issues
None, so far.
