Thoughts on the Functional Source License

Earlier this month, Sentry announced a new software license called the “Functional Source License.” The announcement has a tagline “Freedom without Free-riding”. It purports to address some of the issues with the Business Source License.

An improvement?

It does, in fact, address some issues with the Business Source License. The Business Source License is less of a license and more of a homework problem for a combinatorics class. It has many options that materially change the terms, so being told that software is under the Business Source License doesn’t tell you much. The Functional Source License has one choice: does the license change to the Apache Software License or the MIT license?

While the Functional Source License does reduce complexity, it still suffers from the same problem: it’s not open source. That’s not a problem in itself; it’s a problem because it tries to co-opt the well-known “open source” label without actually being open source. Ultimately, these are attempts to use a license to address a business model problem. As we all should know by now, open source is not a business model.

The “right” approach

I’ve seen some people ask “then what’s the right approach?” The answer depends on what it is you want to do.

If you’re trying to achieve ubiquity, make the source fully closed and give it away to people who aren’t going to pay you money anyway. Or go with a “freemium” or “open core” model.

If you want your users to see the code so that they can trust it, then just make it source-available. This doesn’t make a lot of sense in a software-as-a-service context (which is what the Functional Source License is geared toward) because the user has no way of knowing that the code they’re inspecting is that the code you’re running.

If you want to get community contributions, use an open source license. Otherwise, you’re the free rider. A copyleft license won’t prevent competitors from building a product on your software, but it does prevent them from keeping their changes to themselves.

Other writing: October 2023

What have I been writing when I haven’t been writing here?

Stuff I wrote

Fedora

Duck Alignment Academy

Technically We Write

Other writing: September 2023

What have I been writing when I haven’t been writing here?

Stuff I wrote

Duck Alignment Academy

  • One approach to AI contributions — All communities will need an AI contribution policy at some point, and the Apache Software Foundation’s example is a good one to follow.
  • What are you optimizing? — If you start optimizing for a process and then discover you’re optimizing for the wrong thing, you’ve wasted time.
  • For companies, community should be “us” not “them” — Referring to the community as “them” as if there’s no overlap encourages treating company & community interests as separate, harming long-term sustainability.
  • New logo! — Almost two years after I meant to get around to it, Duck Alignment Academy has a logo.
  • Preparing for Hacktoberfest contributors — If your project is participating In Hacktoberfest, you’ll want to make sure you’re ready for an influx of new contributors.

Fedora

On “non-code contributors”

I was dismayed when I read Justin Dorfman’s “Why I’m proud to be a non-code open source contributor and you should be too” this morning. It’s mostly a great article. Dorfman makes valid points about the value of contributing to open source projects beyond code. Open source needs — and should encourage — these kinds of contributions.

Which brings me to my issue with the article. Dorfman anonymously quotes a well-respected open source leader:

If you find yourself about to use the phrase “non-code contributors” you should stop and use entirely different language.

He calls that a “horrible idea” and suggests that it discourages the kinds of contributions we need. But this take is disengenuous at best. I happen to know the post he’s referring to and it continues:

Defining people by what they are not is not a valid pathway to inclusion. Want to attract designers? Say so. Want to attract technical writers or community managers? Say so.

Far from suggesting that people should be quiet about non-code contributions, the post is calling on project leaders to stop othering those contributors and explicitly value them. The author is saying that lumping everything that’s not code as “not code” diminishes it. It’s just a shame that the article misrepresents a post when it could just agree with what was actually written instead.

Hurricane Lee forecast game

Update: we have a winner!

It took longer than I’d have liked to publish the results of this contest. I was traveling out of the country. But I’d like to congratulate KP on winning the Lee forecast contest.

One thing that I realized after the fact: my changes below made it so only whole numbers could be used for latitude and longitude. I’ve fixed that for next time!

Original post

The prodigal game returns! A technical glitch ruined the Dorian contest in 2019, so we haven’t seen a Funnel Fiasco tropical forecast game since Hurricane Matthew in 2016. But I’m pleased to announce that we’re up and running for Hurricane Lee. You can submit your landfall forecast by 2100 UTC on Wednesday 13 September.

In keeping with tradition, we’re still using the same crappy Perl script I wrote in 2005. Despite the fact that I’ve been putting off a total rewrite for over a decade, I did make a few improvements recently:

  • Numerical fields now require numeric input. If you were hoping to submit “butts” as your wind speed, I’m sorry to disappoint you.
  • Coordinates are constrained to reasonable ranges. I refuse to give in to Kevin’s whining about west being negative numbers. (I believe my exact words to him were “take it up with the Prime Meridian.”) But I was feeling magnanimous so I’ve constrained the latitude to 0–90 degrees north and the longitude to 180 degrees west to 10 degrees east.
  • Similarly, wind speed is now constrained to realistic values. You can’t submit a wind speed less than zero or above 200 miles per hour.
  • Furtherly similar, the time segments can’t be negative or overflow.

So go ahead and submit your forecast by 2100 UTC on Wednesday so you can join in the grand tradition.

Other writing: August 2023

What have I been writing when I haven’t been writing here?

Stuff I wrote

Duck Alignment Academy

Docker

  • Protecting secrets with Docker — Keeping your secrets secret is an ongoing process, but it’s worth the effort. Learn about Docker features you can use to help prevent leaking secrets.

Other writing: July 2023

What have I been writing when I haven’t been writing here?

Stuff I wrote

Duck Alignment academy

Fedora

Does open source matter?

Matt Asay’s article “The Open Source Licensing War is Over” has been making the rounds this week, as text and subtext. While his position is certainly spicy, I don’t think it’s entirely wrong. “It’s not that open source doesn’t matter, but rather it has never mattered in the way some hoped or believed,” Asay writes. I think that’s true, and it’s our fault.

To the average person, and even to many developers, the freeness or openness of the software doesn’t matter. They want to be able to solve their problem in the easiest (and cheapest) way. Often that’s open source software. Sometimes it isn’t. But they’re not sitting there thinking about the societal impact of their software choices. They’re trying to get a job done.

Free and open source software (FOSS) advocates often tout the ethical benefits of FOSS. We talk about the “four essential freedoms“. And while those should matter to people, they often don’t. I’ve said before — and I still believe it — FOSS is not the end goal. Any time we end with “and thus: FOSS!”, we’re doing it wrong.

FOSS advocacy — and I suspect this is true of other advocacy efforts as well — tends to try to meet people where we want them to be. The problem, of course, is that people are not where we want them to be. They’re where they are. We have to meet them there, with language that resonates with them, addressing the problems they currently face instead of hypothetical future problems. This is all easier said than done, of course.

Open source licenses don’t matter — they’ve never mattered — except as an implementation detail for the goal we’re trying to achieve.

Barbenheimer

Over the weekend, I took part in the Barbenheimer Experience. We saw “Barbie” and — after a break to feed my sister’s dogs and also myself — “Oppenheimer”. I’ll be honest: I mostly did it because it felt like a silly Internet thing to do. But I’m glad I did it.

Barbie

Not since “Citizen Kane” has a movie about a beloved childhood possession made such good Art™. I wasn’t prepared for how much I enjoyed it. It was fun in a silly, self-aware way. Credit to the folks at Mattel who approved this, because it addresses some of Barbie’s problems.

It’s not just a fun movie, though. The movie addresses serious themes, sometimes satirically and sometimes earnestly. The message gets a little ham-handed in a few spots, but it quickly reels back in. Overall, it provokes thought in a fun way.

One thought it provoked in me: how many times did they have to shoot the beach off scene before they got a usable take?

Oppenheimer

“Oppenheimer” is not a fun movie, but it was interesting. I didn’t know much about Robert Oppenheimer before the movie, and I’m not sure how much I can claim to know now. While not fawning, the movie’s portrayal of Oppenheimer is complimentary. It doesn’t ignore his personal failings, but it also doesn’t explore them. They are just facts in the story.

I spent the rest of the evening thinking about atomic weapons. Truman’s decision to drop atomic bombs on Japan may be the ultimate Trolley Problem. An American invasion of mainland Japan would have cost many military and civilian lives. But that didn’t happen. The death of a few hundred thousand civilians did happen. No matter what the outcome of the road not traveled, we can’t ignore what did happen.

Was Oppenheimer’s opposition to Teller’s hydrogen bomb principled or was it petty? I either case, was it hypocritical? Was it ethical? What lessons should we take for the things we invent today?

Barbenheimer

Both movies are about the end of the world as the characters know it. Both grapple with what that means for the future. They are very different movies, but they compliment each other quite nicely. They’re good on their own, but I’m glad I saw them together.

Booth Tarkington on “The Golden Bachelor”

This weekend, it came to my attention that ABC is making a change in its long-running dating show The Bachelor. A 71 year old man will be the first “golden bachelor” in the upcoming 28th season. I don’t have much of an opinion on the show generally or the new season particularly, but I couldn’t help but think of Booth Tarkington’s Pulitzer Prize-winning The Magnificent Ambersons.

Youth cannot imagine romance apart from youth. That is why the roles of the heroes and heroines of plays are given by the managers to the most youthful actors they can find among the competent. Both middle-aged people and young people enjoy a play about young lovers; but only middle-aged people will tolerate a play about middle-aged lovers; young people will not come to see such a play, because, for them, middle-aged lovers are a joke—not a very funny one. Therefore, to bring both the middle-aged people and the young people into his house, the manager makes his romance as young as he can. Youth will indeed be served, and its profound instinct is to be not only scornfully amused but vaguely angered by middle-age romance.

Booth Tarkington, The Magnificent Ambersons

In an interesting coincidence, both Tarkington and the “Golden Bachelor” are from Indiana. At any rate, I suppose ratings will tell if Tarkington was right or not.