LicenseReviewProcessImprovementSpec

Differences between revisions 23 and 24
⇤ ← Revision 23 as of 2010-10-22 17:42:50 →
Size: 6168
Editor: 99-191-111-134
Comment: ## page was copied from SpecSpec
← 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 2: Line 2:
 * '''Launchpad Entry''': UbuntuSpec:foo
 * '''Created''': <<Date(2005-10-25T15:45:54Z)>>
 * '''Contributors''':
 * '''Packages affected''':
 * '''See also''': SpecTemplate		  * '''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 10: Line 10:
This specification describes the way we would like Ubuntu specifications to be written. It takes the form of a specification itself. 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 14: Line 14:
As we develop new ideas for features in Ubuntu, it's important to be able to communicate them clearly. This serves the purpose of making it clear what the feature is about, and allowing people to evolve an implementation strategy for it. 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 16: Line 16:
Publishing this content 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 also allows community members who were not physically present at meetings discussing a topic to participate in the implementation of the spec.

Bottom line: the better your spec, the better the chances that your ideas will be clearly understood by the review team.		 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 24: Line 21:
  * Bob is the maintainer for the boot process for Ubuntu. In the Dapper cycle, he would like to work on getting the boot time down to two seconds from boot manager to GDM screen. He creates an entry for the specification in Launchpad, proposes it for the UBZ sprint, and starts writing out a braindump of it in the Ubuntu wiki. Magnus, who is in charge of UBZ scheduling, thinks it sounds fishy but approves it to make sure that the change is discussed and documented properly. He marks it as priority Medium because he isn't sure Bob will have time free for implementing it during Dapper.   * 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 26: Line 23:
  * Pedro works on Malone, in Launchpad. Before UBZ, he remembers that the dependency handling in the bug tracker is really not optimal. He writes out a Summary and Rationale in a Launchpad wiki page, registers it as a specification in Launchpad, and suggests it for UBZ. Monica, Launchpad manageress, thinks that this is really not the time to be talking about it and rejects the application for UBZ. He then indicates it for the next conference, UBB, and marks its priority is Low.

  * Jason is an Ubuntu and Rosetta user. He has noticed that changes made to translations are making their way into language packs but not to the upstream versions, and adds a specification that describes a way for getting upstream to use language packs. Monica also has a plan for this but hadn't described it in a spec, so she adds it to the UBZ spec list, and adds Carlos, Rosetta maintainer, as drafter for it.
Line 32: Line 26:
This specification covers feature specifications for Ubuntu and Launchpad. It is not meant as a more general specification format. 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.
Line 36: Line 30:
A specification should be built with the following considerations: When a new package is nominated to be promoted into main:
Line 38: Line 32:
  * The person implementing it may not be the person writing it. It should be clear enough for someone to be able to read it and have a clear path towards implementing it. If it doesn't, it needs more detail.   * 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.
Line 40: Line 34:
  * That the use cases covered in the specification should be practical situations, not contrived issues.

  * Limitations and issues discovered during the creation of a specification should be clearly pointed out so that they can be dealt with explicitly.

  * If you don't know enough to be able to competently write a spec, you should either get help or research the problem further. Avoid spending time making up a solution: base yourself on your peers' opinions and prior work.

  * Specifications should be written in clear, concise and correct English. If you're not a native speaker, co-editing the spec with somebody who is might be a good idea.

Specific issues related to particular sections are described further below.		   * 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: [[http://fedoraproject.org/wiki/Licensing|2]]
Line 52: Line 43:
The summary should not attempt to say '''why''' the spec is being defined, just '''what''' is being specified. 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.
Line 56: Line 47:
This should be the description of '''why''' this spec is being defined. 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.
Line 60: Line 51:
While 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. 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.
Line 64: Line 55:
Use cases are positive statements which (loosely) conform to a pattern like

  * A person and their role
  * The objective they want to achieve
  * The steps they go through
  * The positive result

Specifically, describing the current unsatisfactory state of affairs is not a use case; that belongs in the Rationale section.
Line 75: Line 58:
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 well).  * 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.
Line 79: Line 65:
To implement a specification, the assignee should observe the use cases carefully, and follow the design specified. He should make note of places in which he has strayed from the design section, adding rationale describing why this happened. This is important so that next iterations of this specification (and new specifications that touch upon this subject) can use the specification as a reference.
Line 81: Line 66:
The implementation is very dependent on the type of feature to be implemented. Refer to the team leader for further suggestions and guidance on this topic.
Line 84: Line 68:

The specification process requires experienced people to drive it. More documentation on the process should be produced.

The drafting of a specification requires English skills and a very good understanding of the problem. It must also describe things to an extent that someone else could implement. This is a difficult set of conditions to ensure throughout all the specifications added.

There is a lot of difficulty in gardening obsolete, unwanted and abandoned specifications in the Wiki.		    * 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], ?? )
Line 93: Line 76:
We'll have a first public session on this on the first Monday in UBZ. 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

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)