GAP Against

From Buni.org

Jump to: navigation, search

Contents

GAP should not be approved by OSI

Introduction

The Generic Attribution Provision (GAP) is a short provision based on (but different from) the attribution requirements in the Attribution Assurance License, an OSI-approved license.

The board of OSI has asked proponents and opponents to the acceptance of SocialText's "Generic Attribution Provision" license. OSI's acceptance of a license is based on the board's interpretation of the Open Source Definition (OSD). This paper focuses primarily on arguments against submission based on interpretations of the applicability of the OSD.

This page is organized into four major sections. The first provides the text of the GAP. The second analyzes the conformance of the GAP with the Open Source Definition OSD. The third section analyzes the effects of forced UI attributions on open source generally but is not specific to this license. The fourth section contains links and references to other positions against approval.

Generic Attribution Provision

Redistributions of the [original code] in binary form or source code
form, must ensure that each time the resulting executable program, a
display of the same size as found in the [original code] released by
the original licensor (e.g., splash screen or banner text) of the
original licensor's attribution information, which includes:

(a) Company Name
(b) Logo (if any) and
(c) URL

Key arguments regarding OSD Conformance

Compliance with OSD #3

OSD #3 is

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

Issue

From a practical standpoint it may not be possible to create derivatives that include (as is common) several similar open source packages with the same license. Similar arguments were made of BSD and similar licenses, but they did not request a particular amount of screen real estate. It may not be possible to display hundreds of logos of the specific size on the screen at once. This inhibits the combination of codebases with similar licenses. GAP's generic nature also makes code reuse more difficult, since it can be appended to incompatible licenses (see #Generic_acceptance_of_this_as_an_amendable_clause).

Compliance with OSD #6

OSD #6 is

No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

Issue

The license does not specifically prohibit the use of the software in any endeavor. Indirectly, though, it makes the use of the software impractical in some fields. For example, companies will be unwilling to use GAP software that requires retaining a competitor's 500 pt. logo.[1]

In addition, the logo requirement make it impossible to use GAP software to create an interface for the visually impaired.[2] The size constraint may also mean GAP software can't be used in mobile computing. These limits are also OSD #10 violations.

Compliance with OSD #10

OSD #10 is

License Must Be Technology-Neutral No provision of the license may be predicated on any individual technology or style of interface.

Issue

The provision requires all derivative works to display attribution; it must be the same size as in the original program. It must also presumably be graphical if a logo is included. This prohibits the reuse of GAP code in programs without an interface, or with only a text interface. This is a problem, since under OSD #10 there needn't be any interface.

As written the provision might prevent use of the same code on different types of: interfaces, devices or operating systems. The "same size" clause is imprecise as many operating systems/devices do not measure distance in the display. Secondly, displaying the logo at the "same size" as the original may exceed the display size of the device.[3]

It was argued that [4] [5] the Attribution Assurance License [6], which is already OSI-approved, is a precedent for this. However, the AAL was approved before OSD #10 and thus did not have to comply with it. Also, the AAL is not as constrictive, allowing more discretion in how the attribution is implemented (as long as it is prominent). In contrast, the GAP adds a "same size" requirement, and possibly a logo (which is impossible to reproduce with certain UIs). For a detailed analysis of their differences, see [7].

Generic acceptance of this as an amendable clause

Issue

The board should not consider this as a generic provision to all amendable licenses as the effect on distribution of the combined license is variable and potentially invalid. For instance, some licenses specifically state that you do not have permission to use trademarks and logos yet this provision requires you to do so. Secondly, doing so would cause confusion; "Licensed under MPL v X" would not be clear as to which derivative of MPL was used. Essentially, approving GAP would mean approving 50 new combo licenses. This license proliferation is an issue that the board has stated is a "serious problem"[8]. If GAP itself is found acceptable, each combination should be submitted to OSI for separate approval. For the case of this provision the board should strictly consider MPL+GAP.

Other Issues

License is incomplete or poorly written

The license as written is not composed of a complete sentence. The license should contain a provision that describes what should be done with a logo of the same size, the items in parenthesis are probably intended to do this but do not relate to the sentence gramatically.[9]

OSD 10 Interpretation

OSD 10 was written in response to "click-wrap" licenses. There were attempts at that time to propose licenses that mandated "click-wrap" and similar "I accept the license" interfaces in distributed open source software. Much of the community thought it was unseemly to force a specific method of license acceptance onto future software distribution modes, specifically downstream derivative works that would have to retain technologically obsolete or interactive code for contract formation purposes. The OSI Board decided to foreclose such license provisions by adopting OSD #10. Thereafter, an open source license could require a "reasonable effort under the circumstances to obtain the express assent of recipients" (see AFL/OSL 3.0 ยง 9) but nothing more technologically specific.

As with the Amendments to the U.S. Constitution, when you say something in the OSD you are bound to interpret that provision consistently when other newer technologies and facts come around. So if it was improper under OSD 10 for an open source license to mandate upon derivative works a technology of license assent (presumably to encourage people to do what's best to protect them legally, but that's not enough reason to tamper with freedom!), it should also be improper to mandate a technology for author attribution.

The general principle that today's technology shouldn't lock in the future is a sound one. The Board made the right decision when it adopted OSD 10.

[10]

Other Resources

To be put in as references