[License-review] For Approval: The BOS Public License v1.2

Sat Jul 25 18:45:09 UTC 2026

Dear Harz,

Please provide the rest of the information that is required for a 
license submission.

Pamela S. Chestek
Chestek Legal
4641 Post St.
Unit 4316
El Dorado Hills, CA 95762
+1 919-800-8033
pamela at chesteklegal.com
www.chesteklegal.com

On 7/24/2026 3:33 AM, Harz Tronics wrote:
> Here is the revised BOS Public License v1.2, which explicitly 
> clarifies that attribution requirements apply solely to source code 
> releases and not to compiled binaries/object code.
>
> Here is the link: https://github.com/Luis-Harz/The-BOS-License
>
> And here the full License:
> THE BOS PUBLIC LICENSE (Better Open Source)
> Version 1.2 Based on the MIT License with custom attribution terms
> Copyright (c) 2026 [Your Name]
>
> Permission is hereby granted, free of charge, to any person obtaining 
> a copy
> of this software and associated documentation files (the “Software”), 
> to deal
> in the Software without restriction, including without limitation the 
> rights
> to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> copies of the Software, and to permit persons to whom the Software is
> furnished to do so, subject to the following conditions:
>
> The above copyright notice, this permission notice, and the additional 
> terms
> below shall be included in all copies, forks, or substantial portions 
> of the Software.
>
> ADDITIONAL TERMS:
> (Note: The additional terms below apply strictly to public Source Code 
> distribution and repositories, not to compiled binaries or object code.)
>
> 1. Original Project Link: Any public fork, web-hosted repository, or 
> public
>    republication of this Software (such as on GitHub, GitLab, or 
> similar platforms)
>    must contain a clearly visible and accessible link back to its 
> immediate
>    upstream repository in its primary documentation (e.g., the README 
> file or main
>    project description). This requirement applies strictly to public 
> code distribution
>    and repository forks; it does not apply to private, internal, 
> offline, or
>    execution-only use. In case the upstream repository's URL becomes 
> invalid,
>    deleted, private, or inaccessible, this requirement is waived.
>
> 2. Preservation of Credits: If the Software contains a CREDITS.txt file,
>    existing names and credits within this file must be preserved 
> without removal
>    or alteration in all forks, modifications, or republished versions 
> of the
>    Software. You are permitted to add new credits or names (for 
> yourself or
>    other contributors) to the file.
>
> THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT 
> SHALL THE
> AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> ARISING FROM,
> OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> THE SOFTWARE.
>
> On Fri, Jul 24, 2026, 12:20 Carlo Piana <carlo at piana.eu> wrote:
>
>
>
>     ------------------------------------------------------------------------
>
>         *Da: *"Harz Tronics" <harztronicsgmbh at gmail.com>
>         *A: *"Carlo Piana" <carlo at piana.eu>
>         *Inviato: *Venerdì, 24 luglio 2026 10:30:27
>         *Oggetto: *Re: [License-review] For Approval: The BOS Public
>         License v1.0
>
>         Hello Carlo,
>
>         Thank you for your feedback and perspective from the
>         compliance side. I would like to clarify a few points and
>         share the updated context with Version 1.1:
>
>
>     Please retract the previous versione and apply for the new one.
>     Also, you seem to have replied to me only, this discussion should
>     be public. Can you bring it back to the list?
>
>     Also, see the requirements for the submission (Pam's email).
>
>
>         1. Downstream Rights & Credits: In V1.1, I explicitly
>         clarified that downstream authors and contributors are fully
>         encouraged to add their own names/credits to CREDITS.txt. The
>         requirement only ensures that existing upstream credits are
>         not stripped away.
>
>
>     OK, this is similar to what happens in other contexts, so I think
>     it's legit. That was not transparent since we could not see the
>     text. But does this apply only to source or also to object code? 
>     Because in the second case it would be shifting to some copyleft.
>
>         2. Invalid/Offline Links: V1.1 includes an explicit waiver
>         clause. If an upstream repository becomes private, deleted, or
>         unavailable, the backlink requirement is completely waived to
>         prevent legal traps for downstream users.
>
>
>     OK, this fixes at least one of my untold concerns.
>
>
>         3. Friction & Rationale: The motivation comes from the modern
>         "single-click republication" ecosystem on platforms like
>         GitHub or GitLab. The requirement is meant to be minimal:
>         standard platform forks (which display origin links by
>         default) or a simple line in the README already fully satisfy
>         this condition.
>
>     My objection still stands. And IMHO it creates bigger problems
>     than the fixed ones.
>
>     Cheers,
>
>     Carlo
>
>
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
>
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20260725/dadac15d/attachment-0001.htm>