Refactoring OSD: draft of OSD 1.99

This is mirrored to GitHub for versioning purposes, but (to the extent I'm interested in collaboration on this) I'd prefer to try it on HackMD. You can do that here (or if you're already reading this on HackMD, welcome!)

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

Refactoring OSD: draft of OSD 1.99
Goals and summary
OSD 1.9
Changelog

Goals and summary

This is a refactoring of the Open Source Definition, inspired by work I did some time ago to refactor the Open Knowledge Definition between its version 1 and 2.0, and egged on by real-life discussions at FOSDEM and CopyleftConf in 2020 and on Twitter in 2021.

My primary motivation here is to show what can be done to make the OSD more comprehensible and useful. I do not have the time or motivation to shepherd a rewrite through OSI, but since I've done the work I'm sharing in hopes it can be useful to someone.

Primary changes

The primary structural changes are two-fold:

The definition of open source software is split from open source licenses, resolving a confusion OSI historically inherited from Debian (which as a distributor of software itself, had to answer both questions simultaneously).
Breaks the definition of an open license into required permissions, forbidden restrictions, and permitted restrictions, each of which are separate concepts but which are intertwingled in the original OSD and DFSG.

Value of this effort; relationship to "commercial" and ethical movements

I've labeled this 1.99 because the goal is to refactor, not rewrite. In other words, I've earnestly tried to keep it as close as possible to the meaning of the current version (little-known fact: already 1.9!), as interpreted in practice over the 1.5 decades since it was last revised.

There are many proposals to change (in ways small and large) the OSD. This refactoring proposal is not an endorsement of any of those; it's entirely possible that the right move for OSI as an organization is simply to refactor (to improve the reliability and transparency of the existing license review process) and leave it at that. At the same time, if the organization (or other related organizations) think there should be change, I hope a refactoring will be a more solid basis for such work, allowing them to be more clear and impactful.

Unavoidable(?) questions

Refactoring code often exposes questions about the intended behavior of the original code. This refactoring is no different. Two particular questions jump out, but I'm sure others may be lurking:

Allowed Restrictions: The OSD has always explicitly permitted some restrictions, but has remained silent on many others that are nevertheless present in many licenses. Sections 2.3.1 and 2.3.2 extract OSD's existing language on this topic, while Sections 2.3.3-2.3.6 (and the last clause of 2.3.1) attempt to capture existing permitted restrictions, such as copyleft. This is almost certainly not a comprehensive list, but I've attempted to capture most of the common restrictions. It is my opinion that capturing such an explicit list will be helpful when evaluating future innovative licenses.
Explicit Grant of Use: Licenses must of course allow use, but this is not actually explicit in the current OSD. (It is implied most strongly by OSD #6.) It seemed to me worth saying, so this is now 2.1.1.

Questions that are out of scope

In keeping with the notion that this is a refactoring and not a rewrite (or even a substantial fix of known issues!) here are a variety of issues that are known to me, but explicitly not addressed in this draft.

How, if at all, should previous OSI rule-writing(?) efforts like the non-proliferation report be integrated?
Where should the benefit of the doubt lie when interpreting a new license submitted to OSI?
What presumptions should be made about different types of license stewards?
How should OSI think about innovation?
How should OSI react to groups creating source-available, but likely not OSD-compliant, licensing schemes?
What advice would OSI give that are "SHOULD" and "SHOULD NOT" buckets, rather than "MAY"/"MUST" as labeled by the IETF? There are many of these accumulated over time, but few are formally documented.

I share some of my thoughts on these and related topics here.

Stylistic notes

A few notes on stylistic choices:

Rationale: I include these merely as an explanation for newly added sections; I did not intend for them to become parts of the permanent document, but they may make sense to incorporate into a FAQ or other document that explains any future revisions.
Word Count: Not including Secs. 2.3.3-2.3.6, which are not explicitly included in OSD 1.0, this is 509 words compared to the 493 words of OSD 1.0.
Examples: I have chosen to drop most examples. In my opinion, they should move to an FAQ, where they can be updated regularly with examples from license submissions, rather than being static and limited in a document that should be rarely updated. This does not imply dislike of any particular examples; in particular, this is not an attempt to sneak in "commercial open" by removing the example of for-profit businesses from OSD #6!
Refactor or rewrite?: When I originally wrote this in 2020, I tried to keep it to a minimalist refactor, making as few changes as possible to the actual text. My increasing frustration with bad drafting in 2021 sparked some more major stylistic changes (though again still with the intent of keeping the substance the same). Most notably, this includes a complete rewrite of Sec. 2.1.3 from an earlier cut/paste pastiche of OSD 1, 3, and 4; and an aggressive simplification of 2.1.2. This may make comparison harder, and invite more conspiracy theorizing about how I'm trying to ruin the OSD somehow.
Titles: I've tried to draft section titles to make them closely match the wording of the section.
Parallelism: I have, wherever possible, tried to create parallelism of language. For example, part of OSD #6 that was "must not restrict" becomes "must allow" in Section 2.1.2. However, more could be done here; for example, someone should find a better way to phrase 2.1.4 to make it consistent with the rest of 2.1 (including perhaps accepting that it should be part of Section 1!)
Terminology: I have tried to be consistent in terminology, such as consistent use throughout of "licensed software" rather than "work" or "program".

OSD 1.9

Summary

Software is open if anyone is free to access, use, modify, and share it — subject, at most, to measures that preserve provenance and openness.

The key words “must”, “must not”, “should”, and “may” in this document are to be interpreted as described in RFC2119.

1. Open Source Software

To be open source, software must satisfy the following requirements:

1.1 Open License

The complete source code for the software must be available under an open source license (as defined in Section 2). Any additional terms accompanying any form of the software (such as terms of use, or patents held by the licensor) must not contradict the terms of the license.

1.2 Source Available

The source code for the software must be available to those who receive the software, either distributed with the software or via a well-publicized means for no more than a reasonable reproduction cost.

The source code means the preferred form in which a programmer would modify the software. Deliberately obfuscated source code, or intermediate forms such as preprocessor output, are not allowed.

2. Open Source License

A license is an open source license if its terms satisfy the following conditions:

2.1 Required Permissions

The license must grant the following permissions:

2.1.1 Use

The license must allow use of the licensed software.

2.1.2 Modification

The license must allow the modification of the licensed software.

2.1.3 Redistribution

The license must allow redistribution of the licensed software under the same terms as the license of the original software, and:

for a fee or at no cost;
on its own, or as part of a collection made from software from different sources;
in source code form or other form; and
modified or unmodified.

2.1.4 Propagation

The license must apply to all to whom the licensed software is redistributed without the need for them to agree to any additional legal terms.

2.1.5 Separability

The license must allow any part of the licensed software to be distributed separately from any other part of the licensed software, or from any collection of software with which it was originally distributed.

2.1.6 Subsequent Recipients

The license must grant all subsequent parties who receive licensed software at least the same rights granted to the original recipients.

2.2 Prohibited Restrictions

The license must not contain any of the following restrictions:

2.2.1 Non-discrimination

The license must not discriminate against any person or group.

2.2.2 No Charge

The license must not condition the permissions in Sec. 2.1 on any fee arrangement, royalty, or other compensation or monetary remuneration.

2.2.3 Application to Any Purpose

The license must not restrict anyone from using the licensed software in a specific field of endeavor.

2.2.4 Unrelated Software Distributed Alongside

The license must not restrict other software that is distributed alongside licensed software.

2.2.5 Technology Neutrality

The license must not condition the permissions in Sec. 2.1 on a specific technology or style of interface.

2.3 Acceptable Conditions

The license must not limit the permissions required in Section 2.1, except by the following allowable conditions:

2.3.1 Reputational Integrity

The license may require that modified software carry a different name or version number from the original software, or otherwise indicate that changes have been made.

Rationale: The first part of this section is the third sentence of OSD #4, but an added "or otherwise indicate" clause attempts to capture Apache 2.0 4.b and GPL 2 2.a.

2.3.2 Source Code Integrity

The license may restrict source code from being distributed in modified form, if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time.

2.3.3 Attribution

The license may require retention and conveyance of copyright notices and license texts to recipients of the licensed software.

Rationale: This is an attempt to capture various notice and attribution requirements.

The license may require copies or modifications of the licensed software, including executable forms, to be distributed under the same license as the original licensed software.

The license may require distribution of the licensed software's source code to recipients of executable forms of the licensed software.

Rationale: This is an attempt to capture the core intutions and mechanisms of copyleft.

2.3.5 Technical Restriction Prohibition

The license may prohibit distribution of the licensed software in a manner where technical measures impose restrictions on the exercise of otherwise allowed rights.

Rationale: This is an attempt to capture GPL v3's DRM clauses. However, it is possible that it may be better seen as an instance of "otherwise aggressing" in Sec. 2.3.6, and used as an illustrative example in an FAQ.

2.3.6 Non-aggression

The license may condition a licensee's permissions on not litigating or otherwise aggressing against licensors or other licensees, in an attempt to prohibit the exercise of any grant allowed by the license.

Rationale: This is an attempt to capture patent defense clauses present in many OSI-approved licenses, dating back to the Netscape Public License.

Changelog

Unfortunately, I have not found a great way to visually (or otherwise, such as through a git history) show what sections of the former OSD go where in the new draft. This list is provided to allow easy auditing to make sure I didn't miss anything (and indeed, while preparing it, I found two sentences that had been accidentally dropped).

OSD #1 ("Free Redistribution")
- first sentence → 2.1.3
- second sentence → 2.2.2
OSD #2 ("Source Code") → 1.2
- This could easily be updated and slimmed down. For example, it is unclear whether there is any such thing as a 'reasonable reproduction cost' in 2021, and I suspect that the definition of source code in this context is now so well-understood that it could be deleted, or moved to an FAQ/annotation.
- I am unclear what it means that "The program must… allow distribution in source code as well as compiled form" (programs don't allow distribution in source code form, rightsholders do?) so that has not been included in this revision.
OSD #3 ("Derived Works")
- first clause → 2.1.2
- second clause → 2.1.3
OSD #4 ("Integrity of the Author's Source Code")
- first sentence → 2.3.2
- second sentence → 2.1.3 (modified to make structure parallel to other permissions)
- third sentence → 2.3.1 (with addition to reflect Apache/GPLv2 requirements)
OSD #5 ("No Discrimination Against Persons or Groups") → 2.2.1
OSD #6 ("No Discrimination Against Fields of Endeavor") → 2.2.3
- In keeping with the drafting note that examples should generally live in an FAQ or annotation, the second sentence has been dropped. This is not intended to endorse discrimination against businesses (or genetic research), but rather to make it easier to update and elaborate on the list of examples.
OSD #7 ("Distribution of License") → 2.1.4.
- It's possible that this should either (1) be merged with 2.1.6 or (2) made Sec. 1.3 (i.e., a quality of software rather than of a license)
- This is a good example of where earlier refactoring would have helped clarify drafting—if this is an attempt to prohibit someone from distributing, say, Netscape Navigator under a clickwrap NDA and calling it open source, then this should be in Sec. 1; if it is an attempt to prohibit clickwrap open source licenses for some other reason, then it should be in Sec. 2.1 but drafted more clearly.
OSD #8 ("License Must Not Be Specific to a Product") → 2.1.5 and 2.1.6.
- This entire section could stand to be further edited/rewritten for better parallelism.
- Like OSD 7/New OSD 2.1.4, the first sentence ("The rights attached to the program…") may be better placed in Sec. 1 instead of Sec. 2.
OSD #9 ("License Must Not Restrict Other Software") → 2.2.4.
- Could perhaps be combined with 2.1.3 instead?
- Again I have removed an example that better belongs (and should be expanded!) in an FAQ or annotation.
OSD #10 ("License Must Be Technology-Neutral") → 2.2.5.

Matt Wilson

2021/02/23 20:55:32

restrictions

either "obligations" or "requirements". obligations = "You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: ..." (Edited)

2021/02/23 21:26:50

Unrelated Software Distributed Alongside

Unrelated Works (Edited)

2021/02/23 21:30:34

restrict other software that is distributed alongside licensed software.

define "restrict" ... The license _must not_ apply conditions or requirements outside of the scope of the licensed work, or derivatives of the licensed work, except for the Acceptable Conditions listed in Section 2.3. (Edited)

2021/02/23 22:47:12

(I wanted to make sure that this requirement worked with the non-aggregation condition, so that's why I added the Section 2.3 reference)

2021/02/23 22:02:38

Sec.

Section (Edited)

2021/02/23 22:03:02

S/Sec./Section/g -- unless you want "Sec." (Edited)

2021/02/23 22:17:21

The *license* _may_ require that the source code be provided without modifications, as provided by the original authors, _only if_ the license allows the software to be modified by applying incremental changes using tools and methods commonly used by programmers in building software programs. (Edited)

2021/02/23 22:24:57

Prohibited Restrictions

I think that "Prohibited Restrictions" opens the OSD to gaming through Simons "constructive restrictions". (Edited)

2021/02/23 22:26:06

Might want to have both Prohibited Restrictions (to cover things like field of use restrictions) and Prohibited Conditions

2021/02/23 22:41:01

copyleft

To me, "you may not remove the copyright notice if it is displayed by the program" is a restriction. "You must cause conveyed derivative works to be licensed under the terms of this license" is a condition. But maybe it's all semantics? (Edited)

2021/02/23 22:54:32

The *license* _may_ require a recipient wave legal rights that would prohibit others from exercising the rights provided by the license with respect to the covered work. Agree that anti-DRM / DMCA is a different type of "non-aggression". (Edited)

2021/02/23 22:55:53

Acceptable Conditions

Consider adding Acceptable Exclusions * no warranty / as-is * exclusion of trademark (Edited)

Luis Villa

2021/03/13 16:07:56

OSD 1 uses ‘restrict’ throughout; not going to relabel. (Edited)

2021/03/13 16:10:28

The condition/restriction label is, to some extent, semantic. So if others want to change it, that’s fine. (Edited)

Paul Berg

2021/03/14 01:30:52

modified or unmodified.

Or removed/deleted. It has come up that the removal of software may lead to confusion as to whether that is included in modification. For instance, I include an Apache licensed module in my product and attribute it appropriately. In a later version I remove that module but retain the attribution. The deletion should be allowed as a modification to the original and I should not need to worry about repercussions of the attribution being "incorrect". (Edited)

2021/03/14 02:01:21

against licensors or other licensees

This does not seem broad enough to capture the MPL1.1 which imposes a condition against those that would litigate against OTHER MPL1.1 licensed software. Explicitly, if a license conditions that you not be aggressing against my other GPL licensed software should that be allowed? What about if it is not mine (I restrict against aggressing against ANY OSS software). (Edited)

2021/03/14 02:03:08

As an example, see my draft (not OSI approved) license here, specifically section 10. https://github.com/holy-order-of-the-lambda-cube/MonasticLicense/blob/master/LICENSE

pchestek

2021/03/14 02:54:09

Subsequent Recipients

Not clear what the intention is here. Do you mean that there can't be two different classes of users defined in the license (more favored and less favored) or that someone distributing the software can't add further restrictions? (Edited)

2021/03/14 02:57:23

If I understand the purpose, it's a refactoring, not a new OSD. The original language, for better or worse, is "restrict" (Edited)

2021/03/15 01:37:31

As I wrote in the prefatory materials, my goal was definitely refactoring, with the caveat that some parts are so badly drafted that once you start pulling them apart it was really hard to avoid redrafting at least in part. As a general matter, if OSI wants to actually look seriously at adopting this, in case of any conflict/confusion between the original text and my refactoring, I'd certainly advise ditching my revisions and sticking closer to the original text.

Guest Keller2021/05/24 12:21:25

I don't know how I do the this stuff with computer and program (Edited)

Guest Hines2021/05/24 12:22:21

Need help with wifi for alxsa (Edited)