BLF

What is BLF?

Most software licenses are written in dense legal language. Developers shouldn't need a law degree to understand "can I use this in my project?"

BLF adds a human-readable summary on top, then includes the original legal text below.

The legal terms remain 100% unchanged and binding. The summary just helps people understand what they're agreeing to.

The Problem

Traditional software licenses:

• Are written entirely in legal language
• Require careful reading to understand basic permissions
• Make developers hesitant to use software
• Create barriers for non-native English speakers
• Force people to use "license explainer" websites instead of reading the actual license

Result: People click "I agree" without understanding what they're agreeing to.

The Solution

BLF uses progressive disclosure - show the simple version first, legal version second:

1. Human-Readable Summary - Simple terms anyone can understand
2. Visual Separator - Clear boundary between summary and legal text
3. Original Legal Text - Unchanged, legally binding license terms

Both sections are legally binding. The summary doesn't replace the legal terms - it supplements them.

How It Works

1. Take Any Existing License

BLF works with any license: MIT, Apache, GPL, BSD, proprietary licenses, anything.

The legal text stays 100% identical.

2. Add Human-Readable Summary

At the top of the license, add a clear summary in plain language:

• What you CAN do (use, modify, distribute, etc.)
• What you CANNOT do (remove copyright, sue us, etc.)
• Any important conditions (attribution, share-alike, etc.)

3. Add Visual Separator

Create a clear boundary between summary and legal text. Example:

4. Keep Original Legal Text

Below the separator, include the complete, unmodified legal license text.

Naming Convention

When a license uses BLF formatting, append -BLF to the license name:

The -BLF suffix indicates the license uses Barrer License Format presentation.

Example: MIT-BLF

Why BLF Matters

• Accessibility: Non-lawyers can understand licenses
• Non-invasive: Doesn't change the legal license at all
• Universal: Works with any license (open source or proprietary)
• Progressive disclosure: Simple first, details when needed
• Legally sound: Both sections are binding, nothing is hidden
• International friendly: Simple summaries are easier to translate

Guidelines for Writing BLF Summaries

Keep It Simple

• Use plain language, not legal jargon
• Write at 8th grade reading level or below
• Use bullet points, not paragraphs
• Be direct: "You can do X" not "Licensee is permitted to..."

Be Accurate

• Don't add restrictions that aren't in the legal text
• Don't make promises the legal text doesn't make
• When in doubt, be more restrictive in summary (people will read legal text if they need specifics)

Cover Key Points

• What users CAN do
• What users CANNOT do
• Important conditions (attribution, copyleft, etc.)
• Warranty disclaimers (if critical)

Use Clear Visual Hierarchy

• Bold headings for sections
• Checkmarks ✅ and X marks ❌ for CAN/CANNOT
• Bullets for lists
• White space for readability

Who Should Use BLF?

Everyone.

• Open Source Projects: Make your license accessible to contributors worldwide
• Commercial Software: Help customers understand what they're buying
• Internal Tools: Clarify license terms for your own team
• Libraries & Frameworks: Let developers quickly check if they can use your code

If you have a software license, BLF makes it better.

Getting Started

1. Take your existing license file
2. Write a simple summary of the key points
3. Add a clear separator line
4. Keep your original legal text below
5. Add -BLF to your license name

That's it. You've made your license human-readable.

Examples in the Wild

See BLF in action:

• BarrerSoftware License (BSL) - Our free software license in BLF format
• BarrerSoftware Commercial License - Our paid software license in BLF format

Notice how easy it is to understand what you can and cannot do, before diving into the legal details.