LicenseReviewProcessImprovementSpec

Differences between revisions 1 and 24 (spanning 23 versions)
⇤ ← Revision 1 as of 2005-04-20 09:40:14 →
Size: 2975
Editor: 150
Comment: create it
← Revision 24 as of 2010-10-22 22:59:10 → ⇥
Size: 4894
Editor: 99-191-111-134
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was copied from SpecSpec
 * '''Launchpad Entry''': UbuntuSpec:ubuntutheproject-foundations-n-main-license-review
 * '''Created''': <<Date(2010-10-22T15:45:54Z)>>
 * '''Contributors''': KateStewart
 * '''Packages affected''': all new packages to be promoted into main
 * '''See also''': https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
Line 2: Line 8:
= How to Write an Ubuntu Specification = == Summary ==
Line 4: Line 10:
This is an example Ubuntu specification, with comments on how to write a
good Ubuntu specification. The better your spec, the better the chances that
your ideas will be implemented in Ubuntu, and accepted by the distro team.

== Status ==

 People: MarkShuttleworthLead, MattZimmermanSecond[[BR]]
 Created: 19/04/05[[BR]]
 Author: MarkShuttleworth[[BR]]
 Contributors: [[BR]]
 Status: BrainDump, UduBof, UbuntuSpecification[[BR]]
 Priority: LowPriority[[BR]]
 Branch: n/a[[BR]]
 Bug #: n/a

== Introduction ==

This specification decribes the way we would like Ubuntu specifications to
be written. It takes the form of a specification itself. You can see the
SpecificationTemplate, which it is recommended you use for your own
specifications in this system.		 The license statement for packages is not always accurate, due to conflicts at the file level inside the package. Improving the process for documenting the actual license(s) in effect, for a package, before it is accepted into main, is the goal.
Line 28: Line 14:
As we develop new ideas for features in Ubuntu it's important to have a
clear idea of the exact status of each idea. Putting this content in the
wiki gives our community a chance to participate in the discussion and
design of a feature, and increases the chance that community members will
feel confident enough to start work on the implementation of the feature. A
good specification allows community members who were not physically present
at meetings discussing a topic to participate in the implementation of the
spec.		 Package license statements do not always accurately reflect all of the actual licenses that need to be complied with for that package. See: [[http://turingmachine.org/~dmg/papers/dmg2010_icpc.pdf|1]]
Line 37: Line 16:
== Specification Structure == When a new packages is nominated for main, as part of the license check the individual files should be scanned for licenses. By using current open source tools to analyze the contents, the file level can be surveyed efficiently, and the licenses can be recorded accurately in the package before it is accepted into main.
 
Line 39: Line 19:
The spec is broken into a number of sections and sub-sections. We describe
each of these in turn:		 == Use Cases ==
Line 42: Line 21:
  1. '''The title'''. A short heading for the spec, no more than 12 words.   * A package is denoted to as released under BSD, however files inside it are licensed under GPLv2. If the files are part of the binary, then the source distribution requirement needs to be known to comply with. Knowing there are GPLv2 licensed files present, signals that better analysis in order to comply with the license terms may be required.
Line 44: Line 23:
  1. '''The status metadata'''. This section contains some well-defined
     metadata for the spec. It's important to put in as may flags and tags
     as possible that accurately describe the state and scope of the
     specification. These flags are used to generate reporting pages
     automatically. Please use as many flags as make sense for this spec
     from the following list: HighPriority, LowPriority, MediumPriority,
     UduBof, BrainDump, DraftSpecification, ApprovedSpecification,
     ImplementedSpecification, DistroSpecification, LaunchpadSpecification,
     CommunitySpecification.
Line 54: Line 24:
  1. '''Introduction'''. A brief introduction to the topic or spec. This
     should not attempt to tell '''why''' the spec is being defined, just
     '''what''' is being specified.		 == Scope ==
Line 58: Line 26:
  1. '''Rationale''': a summary of '''why''' this spec is being defined. This specification covers the promotion of a new package into main. Once a new package has been adopted, ongoing scans to prevent inadvertent inclusion may be required.

== Design ==

When a new package is nominated to be promoted into main:

  * The person nominating it, should run FOSSology, ninka, or one of the commercial tools on the package, and verify that the results at the file level match the declared license of the package.

  * If any file does not match the declared license of the package:
    * It should be documented as a detected license, in the information associated with the package.
Line 60: Line 37:
  1. '''Scope and Use Cases'''. The use cases are not always required, but
     in many cases they bring much better clarity to the scope and scale of
     the specification than could be obtained by talking in abstract terms.		   * If any detected license is incompatible with the declared license:
    * Before the package is accepted into main, the person nominating it should work with the package maintainer to resolve the licensing conflict.
    * a good summary of compatible/incompatible licenses can be found: [[http://fedoraproject.org/wiki/Licensing|2]]
Line 64: Line 41:
  1. '''Implementation Plan'''. This section is usually broken down into
     subsections, such as the packages being affected, data and system
     migration where necessary, user interface requirements and pictures
     (photographs of drawings on paper work ell).		 === Summary ===

This specification is for a process change to be applied before accepting new packages into main, by using file level scanning tools to check the analysis.

=== Rationale ===

There is increased awareness in the commercial supply chain to ensure that the licenses code is released under can be complied to [3]. There is a legacy of projects where the intent of the package maintainer does not match what the licenses in the contents say [1]. This step is a low cost overhead to avoid the problem becoming worse.

=== Scope and Use Cases ===

Scope at this time is limited to packages getting added into main. We may want to extend it to updates to main packages to go through the file level scrutiny, but first step is to make sure new packages are license accurately documented as a condition of addition.

==== Use Cases ====


=== Implementation Plan ===

 * installation of common tools that can provide file level scanning
 * update process requirements[4] and process [5] to make license check explicit
 * file level exceptions to package license get documented in one of the emerging standard formats (DEP-5 or SPDX)
 * main archive approvers understand the new requirement and have a strategy to look for it.

== Implementation ==



== Outstanding Issues ==
 
 * process documentation and existing tools confuse copyright and licensing in places.
 * is there an approved list of licenses for packages that can go into main?
 * FOSSology server setup and access, or other tools?
 * mechanism to list all the licenses present in a package ( DEP-5 [8] , SPDX [9], ?? )

== BoF agenda and discussion ==

We'll have a first public session on this at UDS-N

== References ==

 * [1] http://turingmachine.org/~dmg/papers/dmg2010_icpc.pdf
 * [2] http://fedoraproject.org/wiki/Licensing
 * [3] http://www.linuxfoundation.org/programs/legal/compliance
 * [4] https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
 * [5] https://wiki.ubuntu.com/MainInclusionProcess
 * [6] http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
 * [7] http://www.debian.org/doc/debian-policy/footnotes.html#f101
 * [8] http://dep.debian.net/deps/dep5/
 * [9] http://www.spdx.org/node/2456
 * [10] http://www.linuxfoundation.org/programs/legal/compliance/tools


----
CategorySpec

Summary

The license statement for packages is not always accurate, due to conflicts at the file level inside the package. Improving the process for documenting the actual license(s) in effect, for a package, before it is accepted into main, is the goal.

Rationale

Package license statements do not always accurately reflect all of the actual licenses that need to be complied with for that package. See: 1

When a new packages is nominated for main, as part of the license check the individual files should be scanned for licenses. By using current open source tools to analyze the contents, the file level can be surveyed efficiently, and the licenses can be recorded accurately in the package before it is accepted into main.

Use Cases

  • A package is denoted to as released under BSD, however files inside it are licensed under GPLv2. If the files are part of the binary, then the source distribution requirement needs to be known to comply with. Knowing there are GPLv2 licensed files present, signals that better analysis in order to comply with the license terms may be required.

Scope

This specification covers the promotion of a new package into main. Once a new package has been adopted, ongoing scans to prevent inadvertent inclusion may be required.

Design

When a new package is nominated to be promoted into main:

  • The person nominating it, should run FOSSology, ninka, or one of the commercial tools on the package, and verify that the results at the file level match the declared license of the package.
  • If any file does not match the declared license of the package:
    • It should be documented as a detected license, in the information associated with the package.
  • If any detected license is incompatible with the declared license:
    • Before the package is accepted into main, the person nominating it should work with the package maintainer to resolve the licensing conflict.

    • a good summary of compatible/incompatible licenses can be found: 2

Summary

This specification is for a process change to be applied before accepting new packages into main, by using file level scanning tools to check the analysis.

Rationale

There is increased awareness in the commercial supply chain to ensure that the licenses code is released under can be complied to [3]. There is a legacy of projects where the intent of the package maintainer does not match what the licenses in the contents say [1]. This step is a low cost overhead to avoid the problem becoming worse.

Scope and Use Cases

Scope at this time is limited to packages getting added into main. We may want to extend it to updates to main packages to go through the file level scrutiny, but first step is to make sure new packages are license accurately documented as a condition of addition.

Use Cases

Implementation Plan

  • installation of common tools that can provide file level scanning
  • update process requirements[4] and process [5] to make license check explicit
  • file level exceptions to package license get documented in one of the emerging standard formats (DEP-5 or SPDX)
  • main archive approvers understand the new requirement and have a strategy to look for it.

Implementation

Outstanding Issues

  • process documentation and existing tools confuse copyright and licensing in places.
  • is there an approved list of licenses for packages that can go into main?
  • FOSSology server setup and access, or other tools?
  • mechanism to list all the licenses present in a package ( DEP-5 [8] , SPDX [9], ?? )

BoF agenda and discussion

We'll have a first public session on this at UDS-N

References

CategorySpec

LicenseReviewProcessImprovementSpec (last edited 2010-10-26 13:56:51 by host194)