From josh at berkus.org Tue Oct 1 15:47:38 2024 From: josh at berkus.org (Josh Berkus) Date: Tue, 1 Oct 2024 08:47:38 -0700 Subject: [License-discuss] Request Discussion Pre-Reviews For New Licenses (chewkeanho-rlos, chewkeanho-cos, chewkeanho-gpos) In-Reply-To: References: Message-ID: <7c1d3877-57a6-40fb-8627-a345736b9546@berkus.org> On 9/29/24 23:58, (Holloway) Chew, Kean Ho via License-discuss wrote: > The main goal is to create a new set of license frameworks which does > not require issuing multiple outbound licenses (e.g. Apache 2.0 for > software, CC-BY-ND for images, CC-BY-SA for video, ...) for a single > project repository and picked up the latest updates in the market > implementations. Can you explain this goal in more detail? I think this is the interesting part to discuss. > Wait, you mean rlos will not be approved mainly due to reason (1) > fromhttps://opensource.org/licenses/common-reasons-for-rejection-of-licenses, > right? I drafted this based on BSD-3-Clear and BSD-2-Patent licenses. The BSD-2-Patent license specificially *grants* limited patent rights. Your license specifically *denies them*, so I don't understand how it's "based on" the approved license. -- Josh Berkus From pamela at chesteklegal.com Tue Oct 1 15:57:41 2024 From: pamela at chesteklegal.com (Pamela Chestek) Date: Tue, 1 Oct 2024 11:57:41 -0400 Subject: [License-discuss] Request Discussion Pre-Reviews For New Licenses (chewkeanho-rlos, chewkeanho-cos, chewkeanho-gpos) In-Reply-To: <7c1d3877-57a6-40fb-8627-a345736b9546@berkus.org> References: <7c1d3877-57a6-40fb-8627-a345736b9546@berkus.org> Message-ID: <9cf42779-1935-400f-a163-0e3ddd1e261f@chesteklegal.com> On 10/1/2024 11:47 AM, Josh Berkus wrote: > On 9/29/24 23:58, (Holloway) Chew, Kean Ho via License-discuss wrote: >> The main goal is to create a new set of license frameworks which does >> not require issuing multiple outbound licenses (e.g. Apache 2.0 for >> software, CC-BY-ND for images, CC-BY-SA for video, ...) for a single >> project repository and picked up the latest updates in the market >> implementations. > > Can you explain this goal in more detail?? I think this is the > interesting part to discuss. > > > Wait,? you mean rlos will not be approved mainly due to reason (1) > > > fromhttps://opensource.org/licenses/common-reasons-for-rejection-of-licenses, > > right? I drafted this based on BSD-3-Clear and BSD-2-Patent licenses. > > The BSD-2-Patent license specificially *grants* limited patent rights. > Your license specifically *denies them*, so I don't understand how > it's "based on" the approved license. > > > To add to this, IIRC the BSD-Clear license is not an OSI-approved license specifically because it is meant to withhold patent rights. Pam Pamela S. Chestek Chestek Legal 300 Fayetteville St. Unit 2492 Raleigh, NC 27602 +1 919-800-8033 pamela at chesteklegal.com www.chesteklegal.com From bruce at perens.com Tue Oct 1 17:28:01 2024 From: bruce at perens.com (Bruce Perens) Date: Tue, 1 Oct 2024 10:28:01 -0700 Subject: [License-discuss] Request Discussion Pre-Reviews For New Licenses (chewkeanho-rlos, chewkeanho-cos, chewkeanho-gpos) In-Reply-To: References: Message-ID: The word "SHALL" must not be used in a license. Please replace all occurrences of "SHALL" with "MUST" and see https://www.plainlanguage.gov/guidelines/conversational/shall-and-must/ for the reasons you must do so. I am assuming you are not a legal professional, I think one would not have missed that issue by now. In my own license drafting, I am very careful not to propose that anyone use the text until my own lawyer has revised it for legal correctness. Please see 1.6 at https://perens.com/static/DEVELOPMENT_LICENSE.txt for the disclaimer I apply, which also states why it is a bad idea for a non-legal-professional to inflict a license upon the Open Source developers. I was expert witness in the appeal of one of the first Open Source license cases, which resulted from Larry Wall drafting the Artistic License 1.0 without the knowledge of a legal professional, resulting in the lower court judge parsing it as a simple dedication to the public domain. The lawyer I worked with was the dean of law at a big college. We, and the court, all spent a lot of time fixing something we would not have had to fix had Larry used a lawyer. In his defense: no lawyer would help us draft licenses at the time, indeed few would talk with us at all and many of those only in anger. But that is different today. You should also not assume that OSI or this mailing list is your legal review. They aren't your lawyer and a good many lawyers do not participate in this activity due to liability and other issues of giving legal advice to people they aren't contracted to. Thanks Bruce On Mon, Sep 30, 2024, 06:44 (Holloway) Chew, Kean Ho via License-discuss < license-discuss at lists.opensource.org> wrote: > Hi all, > > Wish you a lovely day. Complying to > https://opensource.org/licenses/review-process process, I wish to invite > everyone here to discuss and pre-review my newly drafted open-source > licenses not just for software but also general intellectual properties > usage before submitting to license-review mailing list. > > The main goal is to create a new set of license frameworks which does not > require issuing multiple outbound licenses (e.g. Apache 2.0 for software, > CC-BY-ND for images, CC-BY-SA for video, ...) for a single project > repository and picked up the latest updates in the market implementations. > > What was mainly updated: > > 1. Changed Software to Product so that the license can be expanded to > non-software product licensing usage (e.g. graphics, video, manufacturing > design, audio, etc) without needing to spin multiple outbound licenses; AND > 2. Added license assignment, ratification, and tenure section to > specify when and how is the license applied; AND > 3. Added version controlled clauses for which version shall be in > effect by default; AND > 4. Added artificial intelligence training dataset usage clauses; AND > 5. Added Sensitive Data warranty and liability coverage; AND > 6. Added global vendors (e.g. datacenter) Sensitive Data limitation of > liability; AND > 7. Added force manjure limitation of liability; AND > 8. Added global vendors (e.g. datacenter) Sensitive Data limitation of > liability; AND > 9. Added judiciary minimal damage values limitation of liability; AND > 10. Expanded grant clauses into Creative Commons' rights categories; > 11. AND Added geographical indicator coverage; AND > 12. Added protected geographical indicator coverage; AND > 13. Added protected designation indicator coverage; AND > 14. Added industrial design use coverage; AND > 15. Added integrated circuit layout design use coverage; AND > 16. Added trade secret use coverage. > > ---- > > There are 4 sets of licenses (3 are open-source): > > (1) chewkeanho-rlos > A libre-like license similar to BSD3-Clear but reserves registered IPs > (patent, etc) back to the owner. > > Primary license source: https://doi.org/10.5281/zenodo.13777226 > Backup license source: https://github.com/ChewKeanHo/license-rlos > > > (2) chewkeanho-cos > An Apache 2.0-like license where registered IPs are granting use licenses > by default. > > Primary license source: https://doi.org/10.5281/zenodo.13788522 > Backup license source: https://github.com/ChewKeanHo/license-cos > > > (3) chewkeanho-gpos > A GPLv2-like general public license. Functions like a backhole open-source > that makes everything general public and forcing upstream. Copyleft > boundaries designations (where its effects shall stop) are included and > warning notice is on the cover page in case of excited junior executives. > > Primary license source: https://doi.org/10.5281/zenodo.13825030 > Backup license source: https://github.com/ChewKeanHo/license-gpos > > > (4) chewkeanho-proprietary > A fallback, safety first, designed specifically for junior executives in > case of mishaps. The goal is that, when a project is generated, this shall > be the default license (where everything is locked up). Just in case a > junior accidentally "open" the project, the proprietary license effect is > still there where any senior / legal executive can fire-fight the > situation. The project can be re-licensed into the other open-source > licenses once the embargo is cleared by the business unit. > > IMPORTANT: This is not an open-source license but is listed here for > reference as the other licenses are inter-relate with each other. > > Primary license source: https://doi.org/10.5281/zenodo.13767361 > Backup license source: https://github.com/ChewKeanHo/license-proprietary > > ---- > > Proposed SPDX identifier: > Recommended: **chewkeanho-Xos** (X is the type like c, gp, rl) since there > is a version control clause so the stewards can update the primary license > without backfiring the older versions. > If version locked is required: **chewkeanho-Xos-5-and-above** (where > version 5 is reserved and shall includes the feedback from OSI) > > Supported languages: English > > Available file formats: (1) PDF - for legal folks; AND (2) RTF - for > Microsoft MSI packager; (3) TXT - for Unix packager (e.g. debian package) > > Source redundancies: (1) Zenodo - in the EU that issued the common DOI; > AND (2) GitHub, in the US. > > ---- > > Feedbacks & amendments are welcome. Version 4 is reserved for OSI feedback > and improvement for externals. > > Site-note: if possible, please let me issue PDF for each iteration. the > TXT requires manual formatting (to make it human readable friendly) which > is very time consuming. If possible, I would like the TXT formatting to be > done only after finalization. > > Thank you for your time. > > > Regards, > (Holloway) Chew, Kean Ho > *Justus Dominus* > 202403160286 (003613489-T) > W: https://www.hollowaykeanho.com > E: me at hollowaykeanho.com | hollowaykeanho at gmail.com > ------------------------------ > If you are not the intended recipient, please contact the sender immediately > and delete all copies. The sender shall not be held liable for any > damages, losses, or expenses of any kind arising from the use of or > reliance on the contents of this email herein. If the contents of this > email are digitally and cryptographically signed by a GNU Privacy Guard > (GnuPG) key, please seek out the public key with the sender email available > at: *https://www.hollowaykeanho.com/pubkey.gpg > * > _______________________________________________ > The opinions expressed in this email are those of the sender and not > necessarily those of the Open Source Initiative. Official statements by the > Open Source Initiative will be sent from an opensource.org email address. > > License-discuss mailing list > License-discuss at lists.opensource.org > > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at email.hollowaykeanho.com Wed Oct 2 02:52:05 2024 From: me at email.hollowaykeanho.com ((Holloway) Chew, Kean Ho) Date: Wed, 2 Oct 2024 10:52:05 +0800 Subject: [License-discuss] Request Discussion Pre-Reviews For New Licenses (chewkeanho-rlos, chewkeanho-cos, chewkeanho-gpos) In-Reply-To: <9cf42779-1935-400f-a163-0e3ddd1e261f@chesteklegal.com> References: <7c1d3877-57a6-40fb-8627-a345736b9546@berkus.org> <9cf42779-1935-400f-a163-0e3ddd1e261f@chesteklegal.com> Message-ID: On Tue, Oct 1, 2024 at 11:58?PM Pamela Chestek wrote: > > To add to this, IIRC the BSD-Clear license is not an OSI-approved > license specifically because it is meant to withhold patent rights. > > Pam > > >> On Tue, Oct 1, 2024 at 11:47?PM Josh Berkus wrote: >> The BSD-2-Patent license specificially *grants* limited patent rights. >> Your license specifically *denies them*, so I don't understand how it's >> "based on" the approved license. My bad. I misinterpreted BSD-2-Patent but the context understanding is correct. Basically, I have 2 options: 1. Drop those 2 clauses; OR 2. Update those 2 clauses to grant the permission. I won't do (1) because I personally think it's irresponsible for the downstream (as in, kicking the can down the road) to wildly figure out what to do with the Registered IPs. Not something I'm proud of or have the passion to maintain. If I do (2), then rlos becomes cos. Hence, the convergence. Well, it's not a bad thing because: (a) 1 less license to maintain. (b) The cos license value becomes higher. I may have to re-title the cos license (maybe "Commercial & Libre" - clos) to better represent the convergence. On Wed, Oct 2, 2024 at 1:28?AM Bruce Perens wrote: > > The word "SHALL" must not be used in a license. Please replace all occurrences of "SHALL" with "MUST" and see https://www.plainlanguage.gov/guidelines/conversational/shall-and-must/ for the reasons you must do so. > That website is a great resource! Thank you so much for sharing. I will work on it. > I am assuming you are not a legal professional, I think one would not have missed that issue by now. You are absolutely right. I'm a software developer at core now dealing with multimedia work. I'm also a CI tool maintainer+developer that facilitates more than just source code development. > In my own license drafting, I am very careful not to propose that anyone use the text until my own lawyer has revised it for legal correctness. Please see 1.6 at https://perens.com/static/DEVELOPMENT_LICENSE.txt for the disclaimer I apply, which also states why it is a bad idea for a non-legal-professional to inflict a license upon the Open Source developers. > Noted. I shall add the warning notice asap. Thanks for sharing your template. I will reference it for the next upgrade. > I was expert witness in the appeal of one of the first Open Source license cases, which resulted from Larry Wall drafting the Artistic License 1.0 without the knowledge of a legal professional, resulting in the lower court judge parsing it as a simple dedication to the public domain. The lawyer I worked with was the dean of law at a big college. We, and the court, all spent a lot of time fixing something we would not have had to fix had Larry used a lawyer. In his defense: no lawyer would help us draft licenses at the time, indeed few would talk with us at all and many of those only in anger. But that is different today. > > You should also not assume that OSI or this mailing list is your legal review. They aren't your lawyer and a good many lawyers do not participate in this activity due to liability and other issues of giving legal advice to people they aren't contracted to. > All right. Point taken. I just need to find a way to raise funds for hiring a lawyer to review at least 1 time. > On Tue, Oct 1, 2024 at 11:47?PM Josh Berkus wrote: > > Can you explain this goal in more detail? I think this is the > interesting part to discuss. Basically I'm attempting to create a foundational license framework to meet today's composite project needs (e.g. a single repo can release source codes, images, video, audio, etc) in a single release. As we all know, each element has its own license. Example: (1) Source codes - Apache 2.0; (2) Images - CC-BY-SA-4.0; (3) Video - CC-BY-ND; (4) Website - Apache 2.0? for HTML and the other web components are -- well that's another cycle of complications. So in a single release based on the example above, my outbound license has a minimum of 3 types since Apache-2.0 is specifically for software and CC can't offer what Apache 2.0 can. The general practice is to staple all the licenses into 1 thick file so complex to know which is what for; pass it down to the customers; pray they don't come back with a dispute. That's the initial reason I started the effort - to make sure the outbound license is only 1 single type carries the same legal effect for all kinds of files so that customers (including non-legal folks) can understand it. That's where the: "cos", and "gpos" are drafted where "gpos" is based on GPLv2 with strong copyleft while "cos" is the one without. Note that the "gpos" is written based on what I understand from my past linux kernel development experience (no offense: FSF's GPLv2 is so hard to read). There is a slight difference: "gpos" can designate "Externally Usable Interface" where the copyleft is bounded mainly for removing the fear of copyleft effect when using the product as specified (based on what I observed from Linux kernel in the past). Consumers can be both commercial entities and the general public. The naming conventions using simple terms were intentional since the primary target audience is non-legal developers or artists (usually without legal attorney). Then that AI training drama came in, I basically just added a license trigger where the currently disputing "Right to Learn" comes after "Right to Use" (as in you have to use the dataset with read permission in order to learn). This forces those AI data harvesters to comply with the license rather than that "I didn't use it so I don't have to comply" attitude. Then along the way, after analyzing a bunch of licenses, I realized there is a missing fallback "proprietary" license for the case of "excited junior executive" who loves sharing IP to social media without much consideration. That's why I purposely drafted the "proprietary" license alongside the "cos" license based on CC "rights of use" identification. The idea is: 1. When a project is created - it shall always be the "proprietary" outbound license first. When a junior executive accidentally leaked stuff, the proprietary license's effect is in so the senior executive and the attorney can still have a chance to fire-fight. It also simplifies the CI tools developer as we only need to issue 1 type of license and tell the users where and how to re-license. 2. The proprietary license can also use "License Grant" with overriding t&c acting like how we consumers can understand - Right to Use, How to pay, Open Core, Tivoization, or whatever funky licenses claimed to be "open-source" etc. 3. The product owner can also re-license to any open-source license anytime. Yes, I know - the proprietary license is not open-source. I am just stating the relation and why it was born; not planning to submit to OSI for review. Disclaimer: the "proprietary" carries its general terms; as in, not specific to/from me. Then towards the clean-up, when I cross checked with MYIPO, I realized existing licenses missed out other registered IPs apart from patent (Industrial Design, IC Layout Design) and new identifiers (geographical indicator (GI), designation indicator (DI), Protected GI (PGI), Protected DI (PDI)), etc. Hence, I also looked into USPTO, EUIPO, and CNIPA before performing another upgrade. These new licenses must not deter and restrict the use of existing licenses. They must not carry anything specific to me (except I'm an author and my name for SPDX application in case they are approved). That's all my intention - some upgrades & updates here and there + simplify things for a composite project. Since OSI governs "Open Source" definitions, hence, here we are, making sure those open source licenses are truly open-source. Thanks for your time and patience with me. I was very scared entering into the legal industry. Regards, Holloway From aaron at williamson.legal Wed Oct 2 17:48:37 2024 From: aaron at williamson.legal (Aaron Williamson) Date: Wed, 2 Oct 2024 13:48:37 -0400 Subject: [License-discuss] Request Discussion Pre-Reviews For New Licenses (chewkeanho-rlos, chewkeanho-cos, chewkeanho-gpos) In-Reply-To: References: Message-ID: On Wed, Oct 2, 2024 at 7:48?AM Bruce Perens via License-discuss < license-discuss at lists.opensource.org> wrote: > The word "SHALL" must not be used in a license. Please replace all > occurrences of "SHALL" with "MUST" and see > https://www.plainlanguage.gov/guidelines/conversational/shall-and-must/ > for the reasons you must do so. > > I am assuming you are not a legal professional, I think one would not have > missed that issue by now. > This may be an emerging best practice, but it's certainly not ubiquitous practice amongst U.S. legal professionals. On the contrary, my experience is that "shall" is still more commonly used, regardless of the type of legal document in question. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mccoy at lexpan.law Wed Oct 2 19:35:55 2024 From: mccoy at lexpan.law (McCoy Smith) Date: Wed, 2 Oct 2024 12:35:55 -0700 Subject: [License-discuss] Request Discussion Pre-Reviews For New Licenses (chewkeanho-rlos, chewkeanho-cos, chewkeanho-gpos) In-Reply-To: References: Message-ID: <7d87dfa5-1573-4c8d-b9f5-15182e3f3d5a@lexpan.law> "Shall" is a huge bugaboo of Bryan Garner, who's a bit of a legal drafting guru (who some swear by and others think is all wet). He did write a fairly influential book (with Antonin Scalia) on interpreting legal texts, and also apparently was pals with, of all people, David Foster Wallace. And for a time (maybe still) edited Black's Law Dictionary. I sort of agree with him on shall (it is potentially ambiguous and I think a bit antiquated) but its one of those things that is so ingrained in legal drafting that we'll likely never be rid of it. And others find it valuable. On 10/2/2024 10:48 AM, Aaron Williamson wrote: > On Wed, Oct 2, 2024 at 7:48?AM Bruce Perens via License-discuss > wrote: > > The word "SHALL" must not be used in a license. Please replace all > occurrences of "SHALL" with "MUST" and see > https://www.plainlanguage.gov/guidelines/conversational/shall-and-must/ > for the reasons you must do so. > > I am assuming you are not a legal professional, I think one would > not have missed that issue by now. > > > This may be an emerging best practice, but it's certainly not > ubiquitous practice amongst U.S. legal professionals. On the contrary, > my experience is that "shall" is still more commonly used, regardless > of the type of legal document in question. > > > _______________________________________________ > The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address. > > License-discuss mailing list > License-discuss at lists.opensource.org > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at berkus.org Wed Oct 2 22:25:32 2024 From: josh at berkus.org (Josh Berkus) Date: Wed, 2 Oct 2024 15:25:32 -0700 Subject: [License-discuss] Request Discussion Pre-Reviews For New Licenses (chewkeanho-rlos, chewkeanho-cos, chewkeanho-gpos) In-Reply-To: References: <7c1d3877-57a6-40fb-8627-a345736b9546@berkus.org> <9cf42779-1935-400f-a163-0e3ddd1e261f@chesteklegal.com> Message-ID: On 10/1/24 19:52, (Holloway) Chew, Kean Ho via License-discuss wrote: > I won't do (1) because I personally think it's irresponsible for the > downstream (as in, kicking the can down the road) to wildly figure out > what to do with the Registered IPs. Not something I'm proud of or have > the passion to maintain. Again, what are you trying to accomplish here? Why do you think it's necessary? -- Josh Berkus From roland at rolandturner.com Thu Oct 3 07:33:27 2024 From: roland at rolandturner.com (Roland Turner) Date: Thu, 3 Oct 2024 15:33:27 +0800 Subject: [License-discuss] Thoughts on the Pretix License? In-Reply-To: <1005c9d5-dbed-4db4-85f8-c54758760467@berkus.org> References: <1005c9d5-dbed-4db4-85f8-c54758760467@berkus.org> Message-ID: <1aee7216-c585-4f59-aac4-8625a37d6a3d@rolandturner.com> On 24/9/24 02:18, Josh Berkus wrote: > The Pretix conference software project is using a modified version of > the AGPL for its license: > > https://github.com/pretix/pretix/blob/master/LICENSE > > Curious whether folks think this is OSS or not? I can't see anything in > there that is specifically not, but the business-specific exemptions > from certain AGPL requirements just feels weird. On the other hand, > anyone who doesn't qualify for those exemptions just has to follow the > AGPL, which is open source. A non-open-source license which offers a fall-through to open source is still itself non-open-source. The code is still of use to open source communities of course. An increasingly common case of this is automatically-open-source-fixed-time-after-release, which provides an important risk-management capability for corporate users. So, I'd suggest keeping separate: * is *this license* open source? from * is *the **fall-through license* open source? > 1. You are permitted to use pretix or combined or modified versions of > pretix without respecting GNU AGPL section 13 > ?? (Remote Network Interaction) as long as you follow all of the > additional terms in this document and do NOT use > ?? pretix for any of the following purposes: Purpose-differential terms would appear to be a breach of OSD#6, unless "restrict" is interpreted to mean "total prohibition only". This exception is explicitly field-of-endaevour discriminatory. > 2. Pursuant to AGPLv3, Section 7 (b), you are not allowed to remove > the attribution notice indicating the generated > ?? website is built using pretix at the bottom of all generated web > pages. If you run a modified version of pretix, > ?? you are allowed to rephrase it to indicate a combined work in a > form similar to "powered by based on > ?? pretix, source code available at ". The word pretix must > be a link to https://pretix.eu/. It's badgeware, but doesn't appear to breach OSD. If you create a derivative work which doesn't generate web pages then you'll trivially comply (all 0 pages have the advert on them). This seems dumb, but makes sense given Pretix's objectives. > 3. Pursuant to AGPLv3, Section 7 (c), if you distribute a modified > version in source or binary form, or if you offer > ?? usage of a modified version to third parties (SaaS), it is > important to be clear about what kind of modifications > ?? the distributed work contains. You may not give the impression that > the work being distributed or the service > ?? provided is an authorized or original distribution by pretix. Very untidy drafting, but seems reasonable. - Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce at perens.com Wed Oct 2 18:07:42 2024 From: bruce at perens.com (Bruce Perens) Date: Wed, 2 Oct 2024 11:07:42 -0700 Subject: [License-discuss] Request Discussion Pre-Reviews For New Licenses (chewkeanho-rlos, chewkeanho-cos, chewkeanho-gpos) In-Reply-To: References: Message-ID: On Wed, Oct 2, 2024 at 7:48?AM Bruce Perens via License-discuss < license-discuss at lists.opensource.org> wrote: > This may be an emerging best practice, but it's certainly not ubiquitous practice amongst U.S. legal professionals. I have worked very extensively with lawyers, and have come to the conclusion that although a lot of them have spent a great deal of time and work on education, that there are some really good lawyers out there, but the average is not terrific in quality. And a good many hate their jobs and that shows too. One really great lawyer that I work with brought up this issue years ago. If you find a great one, nurture them. On Wed, Oct 2, 2024 at 10:48?AM Aaron Williamson wrote: > On Wed, Oct 2, 2024 at 7:48?AM Bruce Perens via License-discuss < > license-discuss at lists.opensource.org> wrote: > >> The word "SHALL" must not be used in a license. Please replace all >> occurrences of "SHALL" with "MUST" and see >> https://www.plainlanguage.gov/guidelines/conversational/shall-and-must/ >> for the reasons you must do so. >> >> I am assuming you are not a legal professional, I think one would not >> have missed that issue by now. >> > > This may be an emerging best practice, but it's certainly not ubiquitous > practice amongst U.S. legal professionals. On the contrary, my experience > is that "shall" is still more commonly used, regardless of the type of > legal document in question. > > -- Bruce Perens K6BP -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce at perens.com Wed Oct 2 19:54:55 2024 From: bruce at perens.com (Bruce Perens) Date: Wed, 2 Oct 2024 12:54:55 -0700 Subject: [License-discuss] Request Discussion Pre-Reviews For New Licenses (chewkeanho-rlos, chewkeanho-cos, chewkeanho-gpos) In-Reply-To: <7d87dfa5-1573-4c8d-b9f5-15182e3f3d5a@lexpan.law> References: <7d87dfa5-1573-4c8d-b9f5-15182e3f3d5a@lexpan.law> Message-ID: I was impressed with this:*There are 76 pages in ?Words and Phrases? (a legal reference) that summarize hundreds of cases interpreting ?shall.?* That is quite an indictment. As an Open Source compliance and intellectual property specialist, I consider it one of my main duties to keep the customer out of litigation, and a personal failure if my clients _listen_to_me_ and then are involved in litigation over the issue. There are, surprisingly, some who pay a lot of money for advice and then don't listen. I work for an attorney 100% of the time, so perhaps the ones who get into litigation have first said I'm all wet. On Wed, Oct 2, 2024 at 12:37?PM McCoy Smith wrote: > "Shall" is a huge bugaboo of Bryan Garner, who's a bit of a legal drafting > guru (who some swear by and others think is all wet). He did write a fairly > influential book (with Antonin Scalia) on interpreting legal texts, and > also apparently was pals with, of all people, David Foster Wallace. And for > a time (maybe still) edited Black's Law Dictionary. > > I sort of agree with him on shall (it is potentially ambiguous and I think > a bit antiquated) but its one of those things that is so ingrained in legal > drafting that we'll likely never be rid of it. And others find it valuable. > On 10/2/2024 10:48 AM, Aaron Williamson wrote: > > On Wed, Oct 2, 2024 at 7:48?AM Bruce Perens via License-discuss < > license-discuss at lists.opensource.org> wrote: > >> The word "SHALL" must not be used in a license. Please replace all >> occurrences of "SHALL" with "MUST" and see >> https://www.plainlanguage.gov/guidelines/conversational/shall-and-must/ >> for the reasons you must do so. >> >> I am assuming you are not a legal professional, I think one would not >> have missed that issue by now. >> > > This may be an emerging best practice, but it's certainly not ubiquitous > practice amongst U.S. legal professionals. On the contrary, my experience > is that "shall" is still more commonly used, regardless of the type of > legal document in question. > > > _______________________________________________ > The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address. > > License-discuss mailing listLicense-discuss at lists.opensource.orghttp://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org > > _______________________________________________ > The opinions expressed in this email are those of the sender and not > necessarily those of the Open Source Initiative. Official statements by the > Open Source Initiative will be sent from an opensource.org email address. > > License-discuss mailing list > License-discuss at lists.opensource.org > > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org > -- Bruce Perens K6BP -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at email.hollowaykeanho.com Thu Oct 3 01:03:16 2024 From: me at email.hollowaykeanho.com ((Holloway) Chew, Kean Ho) Date: Thu, 3 Oct 2024 09:03:16 +0800 Subject: [License-discuss] Request Discussion Pre-Reviews For New Licenses (chewkeanho-rlos, chewkeanho-cos, chewkeanho-gpos) In-Reply-To: References: <7c1d3877-57a6-40fb-8627-a345736b9546@berkus.org> <9cf42779-1935-400f-a163-0e3ddd1e261f@chesteklegal.com> Message-ID: On Thu, Oct 3, 2024 at 6:25?AM Josh Berkus wrote: > > Again, what are you trying to accomplish here? Why do you think it's > necessary? > > -- > Josh Berkus I plan to grant the registered IPs like the cos then have the newly converged license to be renamed as clos (Commercial & Libre) and make rlos deprecated from use. Then upgrade it with https://www.plainlanguage.gov/guidelines/audience/. If your query is about my train of thought: license is a black and white document and Registered IPs are usually sorted out at inbound licenses stage. It's the matter of how to roll out to the customer so it's either explicitly stating the grant is denied or permitted with conditions; no in-between or "I don't know". Clarity is the keyword, not deny or grant. By removing those denying clauses, it assumes the customers know what to do and they are likely going to assume the registered IPs are granted. Assumptions are bad especially in the case of clear B&W and the latter has very bad repercussions. Hence, this is why I think it's very irresponsible. OSI determines what is suitable for "Open Source" definitions so I will comply with its requirements. Regards, Holloway From lucybrown at vivaldi.net Thu Oct 3 20:12:41 2024 From: lucybrown at vivaldi.net (Lucy Brown) Date: Thu, 3 Oct 2024 13:12:41 -0700 Subject: [License-discuss] Question: is the following paragraph in violation of OSD6 Message-ID: An HTML attachment was scrubbed... URL: