[License-review] The Better Attribution License.

Fri May 15 00:11:02 UTC 2026

Lucy:
You've received a lot of feedback on this but have not provided any 
revisions or comments in response. Should we consider this submission 
withdrawn?

On 7/19/2025 5:13 PM, Pamela Chestek wrote:
>
> Putting the substance aside, this license is problematic from a 
> contract drafting perspective. It uses words in ways that are 
> ambiguous, which means they can cause interpretive problems in the 
> future. Legal writing can be as formulaic as software coding is -- 
> there are interpretive rules for contracts that are designed to help 
> everyone reach the same conclusion on what it means, so when you don't 
> follow the rules it leaves room for interpretive disagreements.
>
> For example, the definitions use the phrase "refers to." That's 
> open-ended language, meaning that, for example, "Standard Version," 
> could refer to what follows in the definition but it doesn't eliminate 
> the possibility that the term could "refer to" something else too. The 
> standard language construction of a definition is to use the word 
> "means," "Standard Version means ..." - that is closed-ended language 
> that doesn't allow for the possibility that Standard Version can mean 
> something in addition to how it's defined. And why is it "Standard 
> Version," singular, but "Modified Versions," plural?
>
> "Undue hassle, as mentioned in this license ..." It should be "Undue 
> hassle, as /used /in this license ..." You're not just "mentioning" 
> it, your intention is that the phrase has a very specific, defined 
> meaning that you are providing.
>
> And while on "undue hassle," the audience would be much better served 
> by simply saying how the source code has to be provided, an objective 
> standard, rather than the subjective standard of "acts which may 
> prevent users from requesting" code. A subjective standard allows for 
> the possibility that the degree of difficulty might be be measured by 
> someone's personal sensibilities, even if irrational, e.g., "I don't 
> use email, therefore it is an undue hassle for me to ask for the code 
> via email." You may think that of /course/ it's a rational or ordinary 
> person standard, but I promise you that if this license was ever 
> litigated, whether it was an ordinary person standard or the actual 
> user's sensibilities would be be a point of contention, to the tune of 
> mid-five figures of dollars. You can never write a contract that 
> doesn't require some interpretation, but where you can use objective, 
> measurable standards, like here, the better off everyone is because it 
> prevents disputes.
>
> Under III.1. you refer to "source form" but use "source code" 
> elsewhere. There is a principle in contract interpretation that when 
> you use different words it's because you meant it to have different 
> meanings. So if you mean source code here, then you should use "source 
> code," not "source form." If you mean that "source form" is something 
> different from "source code," then you need to clarify that. 
> Find-and-replace is the contract drafter's friend, to make sure that 
> the same term is used consistently throughout.
>
> The structure of the rights grants is:
>
> III.1. Copyright grant of some scope
>
> III.2. Copyright grant of some scope
>
> III.3. Copyright grant of some scope
>
> III.4. Copyright grant of some scope
>
> III.5. Can add your own attribution
>
> III.6. Patent grant of some scope
>
> III.7 Copyright grant of some scope that has some optional variables 
> (also refers to 6a, which should be 7a)
>
> III.8 No advertisement clause
>
> III.9 No warranties and limitation of liability
>
> You should be able to spot the problem - there are five different 
> sections that carve up rights under copyright law. Some of them use 
> terms of art and some do not. How is "giving away" under III.1. 
> different from "distributing" under III.3 or "redistributing" under 
> III.4.? Some of the grants are for "Standard Version" and some for 
> "Software," which are overlapping categories. The copyright grants 
> aren't even grouped together. This all makes it exceedingly difficult 
> to understand this license and, when you have so many different 
> overlapping scopes, there is bound to be a loophole somewhere. If you 
> need to have all these separate grants, then they should to be written 
> in parallel structure so the reader can easily see how they fit together.
>
> I haven't read this license thoroughly, this is just what I picked up 
> on a quick read, so I'm not suggesting that there aren't other 
> inconsistencies elsewhere. But on a rewrite you should consider these 
> structural drafting problems.
>
> Pam
>
> Pamela S. Chestek
> Chestek Legal
> PLEASE NOTE OUR NEW MAILING ADDRESS
> 4641 Post St.
> Unit 4316
> El Dorado Hills, CA 95762
> +1 919-800-8033
> pamela at chesteklegal
> www.chesteklegal.com
>
>
> On 7/10/2025 11:24 AM, Josh Berkus wrote:
>> On 6/30/25 17:33, Josh Berkus wrote:
>>> Lucy Randall,
>>>
>>> We are approaching 2 months from the submission of this license, our 
>>> usual interval for examination.  You've received some critical 
>>> feedback from our volunteer attorneys.  Do you plan to revise the 
>>> license submission, or keep it as it is?
>>>
>>
>> For the record, the submitter plans to submit a revised text.
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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/20260514/25953271/attachment-0001.htm>