Diff for "Soyuz/SourcePackageLicenses"

Not logged in - Log In / Register
Differences between revisions 3 and 4
⇤ ← Revision 3 as of 2008-12-01 14:05:19 →
Size: 3476
Editor: cprov
Comment:
← Revision 4 as of 2008-12-01 14:18:35 → ⇥
Size: 3756
Editor: cprov
Comment:
Deletions are marked like this. Additions are marked like this.
Line 22: Line 22:
Line 23: Line 24:

/!\ Not yet.
Line 28: Line 31:
Line 29: Line 33:

/!\ Not yet.
Line 35: Line 41:
 * 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.
Line 36: Line 43:
 * 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 37: Line 46:
 * Juliet, a package reviewer, should be able to inspect the licenses involved in a new source uploaded to ubuntu before accept it.
Line 42: Line 50:
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 46: Line 57:
This section should cover changes required to the UI, or specific UI features that are required to implement this. None, see '''Assumptions'''
Line 52: Line 64:
Line 53: Line 66:

/!\ Not yet.
Line 56: Line 71:
Line 57: Line 73:

/!\ Not yet.
Line 60: Line 78:
Line 61: Line 80:

/!\ Not yet.
Line 67: Line 88:
Line 69: Line 91:
In this section list out any issues which are unresolved and will impact or block the implementation of this spec. None, so far.

Contents

Contents

  1. SourcePackage licenses
    1. Overview
      1. Overall Summary
      2. Release Note
      3. Rationale
      4. Use cases
      5. Assumptions
    2. User Interface
    3. Implementation
      1. Code Changes
      2. Schema Changes
      3. Migration
    4. Unresolved issues

SourcePackage licenses

Overview

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 acessible after a sourcepackage upload is processed.

Release Note

/!\ Not yet.

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.

It is mandatory.

Rationale

/!\ Not yet.

This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.

Use cases

  • Richard is a strong GPL-v3 defensor, 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.
  • 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.
  • Romeu, a release manager of a distribution hosted in Launchpad, wants to audit all the sources published in his release and decided, 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

  1. The ubuntu and the debian community are happy with http://wiki.debian.org/Proposals/CopyrightFormat specification;

  2. There is no major different (pattern-wise) between the debian format and the RPM proposal (see http://fedoraproject.org/wiki/Packaging/LicensingGuidelines);

  3. 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.
  4. ...

User Interface

None, see Assumptions

Implementation

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.

Code Changes

/!\ Not yet.

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Schema Changes

/!\ Not yet.

What Database changes are you proposing? Do you need a new index created? Proposing a new table? If so, what does it look like?

Migration

/!\ Not yet.

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

Unresolved issues

None, so far.

CategoryProposal

Soyuz/SourcePackageLicenses (last edited 2009-02-11 18:16:08 by cprov)