Comments on Recommendation-License-Review-Process
Last modified by Pamela Chestek on 2023/06/16 17:20
- Manage
- Copy
- Actions
- Export
- Print Preview
- Viewers
- Source
- Children
- Content
- Attachments
- History
- Information
- Likes
Export
Choose the export format from the list below:
$services.rendering.render($uix.execute(), 'html/5.0')
$services.rendering.render($uix.execute(), 'html/5.0')
$services.rendering.render($uix.execute(), 'html/5.0')
- Office Formats (3)
-
Export as Open Document Text (ODT) format using the Office Server
-
Export as Portable Document Format (PDF) using the Web Browser
-
Export as Rich Text Format (RTF) using the Office Server
-
- Other Formats (1)
-
Export as HyperText Markup Language (HTML)
-
Export as
Select the pages to export:
- Legend:
- Created Page
- Modified Extension Page
- Clean Extension Page
Ok, Ctrl+M is the trick
One must first register, and this function is in the hamburger menu on the upper right corner.
Phenomenal. Eagle eyed and more expert reviewers will no doubt find some good suggestions to make here, but my first take on this section: a powerfully clarifying way to navigate new licenses well in line with the spirit and mission.
So far, the discussion of the licenses occurred in English. A few times a license written in a different language was submitted (I remember one in Chinese). I think in this case to allow an international discussion and an informed evaluation an English version should anyway be provided (not an automated translation, but equally a legally vetted one by some licensing expert) so that there is a guarantee that nuances are as much as possible.
Hi Carlo,
Thanks, yes for pointing that out. It has been the practice of the License Committee to ask for a human translation of a foreign language license and we will continue that. We'll add something to that effect in the updated guidelines.
Shouldn't we include an SPDX identifier, if available? After all, SPDX is an International standard (ISO/IEC 5962:2021) and its list provides a canonical point of reference, even if it's not per se an unique source of truth.
Added. We have been already been asking for that, so we'll just continue asking for it.
Please use "must" rather than "does". While this may seem like a minor nit to the legally uninformed, there has been a great deal of litigation over the ambiguity of the similar word "shall". "Shall" has become so corrupted by misuse that it has no firm meaning. It can mean ‘must,’ ‘should,’ ‘will,’ ‘may,’ or ‘is.’ - Joseph Kimble, Lifting the Fog of Legalese, 160 (2006). In recognition of this and their Plain Writing Act of 2010, USA government documents such as the Federal Rules of Civil Procedure are being re-styled to use "must" rather than "shall" and this is becoming a preference among attorneys.
Here are guidelines on similar words: "Must” is required to. “Must not” is required not to; is disallowed. “May” has discretion to; is permitted to. “May not” is not permitted to; is disallowed from. “Is entitled to” has a right to. “Should” ought to. “Will” means one of the following: (a) To express a future contingency. (b) In an adhesion contract, to express the strong party’s obligations. (c) In a delicate contract between equals, to express both parties’ obligations. - Richard C. Wydick - Plain English for Lawyers (5th ed. 2005).
Thanks Bruce, changed.
Pam
I wonder if the Standards need to include a requirement that the submission is the complete license that will be used, and not an overlay (like Commons Clause) or a text designed to be used with another document that is not included (such as seperate patent terms)?
Added directly under the heading "License Approval Standards." See if you think that wording works.
This removes the category of "Special Purpose Licenses", of which we have several, and may approve more soon. These include licenses that only make sense for folks in certain countries, or for the US Federal Government, or for specific domains of technology. Why remove this category? Is it too difficult to determine which licenses are Special Purpose?
It's not a very helpful category without also explaining what the special purpose is. The tagging of licenses is meant to allow people to more granularly identify licenses that suit their needs, rather than the unhelpful "special purpose."
What about legacy licenses used by only one project, but that project is really big?
Suggested language:
"more than twenty project maintained by different unrelated entities, or one project with more than 100,000 current active users not restricted to a single company's customer base."
Ok, a bit awkward, but you see what I'm getting at? We have, and likely will again, approved "Legacy Licenses" that were single-project where the project was something like Sendmail.
Are you aware of any licenses that fit that description?
Wording has been adjusted.
This section feels like it has a lot of redundancy with the License Submission Process section. Maybe we should consolidate them somehow?
It's two different stages by two different sets of people. I believe it will only make it more confusing to try to combine them.
Will legacy licenses carry any kind of tagging in our online listings? I feel like they should, somehow.
I don't think so. It would mean that some licenses would be "not legacy," so at what point would they be changed? The reason for saying a license is "legacy" is to make the review process a little less onerous for currently existing licenses. I don't see the value of attaching the term to the license in perpetuity. It might help someone understand why a license with something odd was nevertheless approved, but I think that is already known and understood even without mentioning it as such.