kemitchell

I've guided companies to decisions on all these licensing choices. Decisions differed, and reasons did, too. Every choice to delayed-relicense open meant more open software and made the ecosystem better, insofar as more code means better. Everyone thought their choices were right---for them. There's definitely value in painting the shed red and calling that a standard, but there's no one in any position to enforce adherence.

The thought I'd leave you with is that if you're worried about adoption under your restricted terms, and not just the eventual open ones, I think you could get a lot more projects reusing a "don't compete with us" license uncoupled from permissive relicensing on an aggressively short interval. "Licensed under Foundation Source v2, releases become MIT after 2 years" isn't any harder to mimic, for companies you suspect will just follow your lead. And then anyone adopting just FSLv2, or "FSLv2, releases become MPLv2 after 4 years" (Hashi?), or some other combination, could also be bouncing around through the industry, bumping into coders and legal departments, informing them one at a time that FSL exists and might be worth green-lighting.

I wish you and yours the best. I'd never say this is bad, and I haven't. But I've been at this a while, and I do suspect it could be better.

Maybe your goal with the new "Functional" brand, rather than a new "Sentry License", was just to communicate that you'd welcome follow-on by other companies who happen to make all the same license choices you did, and are willing to put that under a neutral brand, rather than your own. But I strongly suspect you'd get more reuse and stronger branding for your approach, in the long term, by remembering how much confusion and controversy conjoined naming like "MIT + Commons Clause" and "Apache2 + Commons Clause" caused.

I know and deeply respect a number of people involved in that presentational choice. I think they made for apparently good reasons, to give everyone who came together around the project a way to adopt without dropping the brands of their current open licenses. I also think it's safe to say it backfired.

It's not about minimizing blanks to fill out. It's about maximizing what terms licensors can share and reuse, and what "brands" for those terms they can promote and popularize.

It's pretty clear what the questions are for scheduled relicensing: "what new terms?" and "when?" And it's a relatively small legal job to write terms that just schedule a new license to kick in, with blanks for the answers.

I don't see why we'd want to "hard-code" those values, given how much licensors' choices have varied. The original users of scheduled relicensing, and most recently Hashi, chose copyleft licenses, not MIT or Apache 2. Of the recent crop of companies announcing scheduled relicensing, I think Sentry's the first I've seen that chose two years.

There is also a lot of variation in what terms developers want to apply from initial release, but a lot of it has been independent reinvention on recurring themes. If we popularize a named form just for scheduling relicensing, projects can put those terms in `FUTURE-LICENSE` or somesuch and whatever license terms they want for day one in `LICENSE`. Then we can focus on developing a recognizable set of restricted-license choices that serve most developers in these situations, for maximum reuse. The "menu" of PolyForm licenses https://polyformproject.org/licenses/ has already put a few into the field. Some are proving more popular than others.

I've been working with colleagues to publish reusable restricted licenses through PolyForm Project (https://polyformproject.org/) for a few years now. I'd like to publish a form for scheduled relicensing through them as well, and blogged about it here: https://writing.kemitchell.com/2023/10/24/Scheduled-Relicens.... That's still a work in progress, but pretty close to presentable.

When dealing with government entities, you may run into policies of those entities that require use of a pre-approved service. For example: https://www.sos.ca.gov/administration/regulations/current-re...

All that said, I have both implemented electronic signature in my own software and reliably recommended clients running sales ops just buy DocuSign. Familiarity and credibility can matter way more than legal or technical details...or not at all.

https://blueoakcouncil.org/license/1.0.0#acceptance

We've published a very liberal license for use of the Blue Oak license text, as well:

https://blueoakcouncil.org/license/1.0.0#permission

It's all intuitive, but I get the distinct feeling they took a big decision toward conscious reality distortion at the top. Not just to shore up credibility of their investment theses to LPs, but to will the very success of their investments into being. Maybe that's just natural for equity flippers on a particular time scale with enough management fees and brand rec: grease both sides of the two-sided market you turn in. Envelop as many minds as you can.

They route systematically important gobs of capital. I guess I just keep watching the space, to note the content and timing of their big investment-theme announcements. Stick to headlines and leads.

I do wonder who the other 5,000 words are for.

If I were going to summarize my mental model overall, I would say that terms like GPL pasted into license notices for published source code memorialize the terms of contracts that grant licenses. In the jargon, the deals between developers, users, and distributors are "license agreements".

The argument against revocation at will is either reliance or consideration---contract doctrines. If there's ambiguity or vagueness in the terms, it will be argued under rules of construction---again contract doctrines---not statutory interpretation or some copyright-specific scheme. Claims for exceeding the license or breaking rules in the terms will be infringement when preempted and breach otherwise, with a lot of work still to be done sharpening lines like the "extra element test" and "substantial use restrictions". The defense to plead against an infringement claim is license---a property concept.

The fundamental error of "license, not contract" is really the underlying idea that they're mutually exclusive. They're really integral and complementary. Between private parties, contracts are the means by which licenses are given and received.

When writing specifically about the GPLs, the claims are usually about the source code requirement. I can slip into just saying "contract" because that's where I see those claims heading.

My best guess is in the blog post. A lot of activist attention was focused on trying to push back against strong copyright. If that work succeeded, it could have meant nothing if "evil" software companies just used contract law to restrict software instead.

The awkwardness in the evidence comes from all the old writing, tracing back to FSF, arguing license to the exclusion of contract.

For the kind of "relicensing" relevant to HasiCorp and similar, the question is "What will be the license terms for new work going forward?"

Unless authors are claiming to revoke the license under which they previously released code---neither Hashi, nor Elastic, nor Mongo, nor the Commons Clause companies I saw ever claimed to do this---those old license grants do not go away. Hashi Terraform releases from the before the announcement are still available under MPLv2, and likely always will be. There is no backwards-looking, retroactive change.

When I fork, say, an Apache-2-licensed project, add my own work, and release under Hashi's BSL, the original, Apache-2-licensed code doesn't cease to be Apache-2-licensed. However, Apache 2 license terms don't apply to my new work unless I say they do. If I choose BSL instead, users of my new releases---old Apache-2 work plus my new Hashi-BSL-licensed work---have to comply with both Apache 2 and the BSL. They can toss my new work and just comply with Apache 2, but they can't have the whole package with my new work without my terms.

The situation's akin to using an Apache-licensed library or copying in Apache-licensed code snippets. All of this is possible because Apache 2, a "permissive" license, doesn't restrict how I can license new work.

The "relicensing" that requires getting every copyright owner's agreement is giving license grants under new or different terms for old releases. Say we're trying to "relicense" a project "from GPLv2 to GPLv3". If we get all copyright holders to sign off, the old releases essentially become "dual licensed"---another overloaded term that here means effectively "available under the user's choice of two or more licenses", specifically GPLv2 or GPLv3. Once copyright holders in existing work have agreed to make that work available under GPLv3, as well, future developers can license further work under GPLv3, too, effectively choosing to comply with the new GPLv3 grant for the old code, rather than the old GPLv2 grant.

We tend to see CLAs less often in permissive-licensed projects. There are various reasons for that, one of which is that permissive terms are by nature less complicated, more stable over time, and contend with fewer "license compatibility" issues. But we still see CLAs in some permissively licensed projects that never anticipate making grants under new terms for old releases, because the project stewards want to make sure people have the legal rights to license copyright in the contributions they offer, and they want documentation to back that up if there's a dispute. Typical CLA forms also address that problem.

So "uses CLA" is only a poor proxy for "stewarded by a company that may not choose to make its new work available under the old license forever". Developers can certainly choose to develop patches to these projects and refuse to give the steward a contributor license agreement. But the steward isn't obligated to accept or maintain those patches. They may very well refuse to do so without the flexibility the CLA provides.

When the public license for the project is copyleft, commercial-company project stewards are highly unlikely to give up licensing flexibility, agree to comply with the new contributor's copyleft license, and "lock the project open" just for some new patch, even if it's quality work. Depending on the copyleft license, that work may have to be licensed under the same copyleft terms, rendering it "compatible". But it simply won't be merged.

This happens, but in my experience, pretty rarely, and with little lasting effect. Outside developers usually aren't interested in spending all the time developing patches to other people's projects in the first place if their work won't be merged to mainline and kept up by the maintainers driving development.

HashiCorp's CLA doesn't assign copyright. It just licenses it. Hence CLA---contributor license agreement. Contributors keep their rights to use and license their work otherwise.

Seeing legal FUD via throwaway account here doesn't make me happy for HN.

I believe I read that Nick's, up north, is also heading worker-owned.

And of course worker-owned doesn't just mean pizza in Oakland.

Thank you.

And that's setting aside the more basic issues of whether an organization like OSI can impose its definition on the universe, whether the definition it's been trying to impose really works or just sounds good, and whether that's really a legal spec or a political document.

The world is messy. It does not owe us the luxury of clear binaries.

I don't see what locking corporations into future open releasing does to solve the general problem.

The problem is fueling and operating maintenance and development for as long as those costs remain worthwhile. There are no perpetual motion machines. We have multiple data points from companies suggesting the rules of the game being played today create an inflection point away from universal permissive licensing. Restricting an organization's freedom of operation might maximize the time it holds out in forlorn hope on a pure, doomed model. It might also grind it to a halt when it could have kept going by compromise.

A project steward going bust can send a clear signal to former free riders that they need to step up and organize or switch off. But in the meantime, what's to stop some other firm, without charter restrictions, stepping in to try the model the restricted firm wasn't allowed to? What's to stop the engineers at the restricted firm jumping ship?

On the level of implementation, I wonder at the need for public benefit corporation structure, with all its vagueness, expenses, and complications. Are the feel-goods really worth the complication?

You can put corporate-powers limitations in a "regular" corporation charter. That's a key part of how we turn C-corps into tax-exempt charities and business leagues. The restrictions we put in, say, 501(c)(3) charters also read vague, but they're statutory language we've been fighting about and refining by law over time. Conversely, putting eight novel, vaguely worded restrictions into a corporate charter, with or without line-by-line statements of intent, is putting a whole lot of fluff in the very beating heart of a governance structure. Who settles interpretation fights there, a judge in a shareholder derivative suit? I think the hullabaloo of the OpenAI Charter might be instructive.

> There are social contracts

> > Try to enforce it.

There is no contract. Try to enforce it. Even non-binding expectations differ widely among projects.

> We believe that HashiCorp should earn a return by leveraging its unique position in the Terraform ecosystem to build a better product, not by outright preventing others from competing in the first place.

Nobody at Hashi cares how their competitors think they should make money. As for competition, Hashi just blew the whistle for an all-comers product pace-race against its formerly free-riding rivals. The old code remains MPLv2-licesed. That's the starting line. Their new BSL automatically releases new code under MPLv2 four years after it's published. That's Hashi committing to a minimum pace. They clearly foresaw a fork.

They are betting their maintenance commitment, expertise, new development pace, and existing book of business will make their new, less than four-year-old versions the versions users want, despite the license. Hashi's announcement and FAQs try to minimize perceived cost of the license change by emphasizing they intend no change for users, customers, and contributors, as distinct from product-service competitors. This new fork announcement tries to maximize uncertainty about the license and throw shade on future development prospects. It's all in the game.

Customers can watch the runners run. Eat popcorn.

I think it's highly unlikely Hashi's rivals will make enough marketing pain on this to force them to reverse the change. The database companies made far bigger moves, with more complexity and fewer marketing lessons learned. They held out. So the war's on the product dev and product marketing fronts.

The real test will come in January, after Hashi says it will stop backporting fixes to the current MPL release. At that point, the rivals are under their own power only. Will any MPL-today-licensed fork be so competitive with Hashi's version at that point that customers bet on it over Hashi's long-term? It will have to bear its own development and maintenance costs for whatever differentiates it.

I'm familiar with the products, but not an active user. My main question is whether there's substantial new development still to be done on the most popular projects, or whether it's really a maintenance war. I'd be looking for whether Hashi's new versions break compat, either tactically or as a consequence of new development.

That being the case, I'm betting I don't actually need to read it.

You could find answers you didn't know to questions you didn't know to ask for hours and hours. And then some tangent about French derailleurs, besides.

I still have tools color-coded Sheldon's way.

Looking back at the Athletica opinion, the 6th followed the Supreme Court in referring to Skidmore as "the power to persuade", as distinct from "the power to control". There's an abstract rubric for courts to use in assessing agency interpretations that don't have the force of law. But the door is very much left open for courts to adopt interpretations they find more thorough, better reasoned, more consistent, &c. You could squint and see an outline of how appeals courts review all decisions there.

With "presumption", I think you may be confusing terms. There's a statutory presumption you get in your favor once you successfully register copyright with the Copyright Office. That's a presumption for a party challenging the validity of a copyright to overcome---say, a defendant in a copyright infringement suit. Judges and courts don't bear "burdens" under "presumptions". They follow the rules that put them on litigants, or review the decisions of lower courts that should have.

Consider the opposite case where the Copyright Office refuses registration because it says the subject matter's not copyrightable. Perhaps because the artist created the artwork by prompting Midjourney. There's an appeal process for refusal to register within the Copyright Office, under its regulations. If you appeal twice and lose twice there, that's "final agency action" courts can look at.

If the issue ends up in court, the statutory presumption of 410(c), by its terms, doesn't apply. No issued registration, no presumption of validity. But there is still Skidmore. In the Sixth Circuit that's clear now. The court couldn't ignore the Copyright Office's reasons. But if it weren't persuaded, it could rule otherwise. It would have to read the Copyright Office and grapple with it, but not agree with it. Especially if it heard a better argument in briefing.

As I recall, Skidmore held that what agencies say laws mean gets only the deference it deserves. In other words, the courts will reconsider for themselves how persuasive their arguments are.

Chevron starts with the question of whether the administrative agency's decision was made in a way that a statute gives the force of law. The Copyright Act gives the Copyright Office that power in administering some processes, like copyright registration. But last I checked, which was well after Chevron, questions about whether an application followed the registration process got deference, but the more basic question of whether something's copyrightable in the first place remained with the courts. Just because it's called the "Copyright Office" doesn't mean the courts will defer to it about the whole Copyright Act.

This difference could very well matter for some going issues, like the Copyright Office's recent rejection of some artwork created with the help of generative AI. I would be very, very surprised to see appeals courts handing that legal question over the Copyright Office.

I don't think I've seen that asserted before. I certainly wouldn't bank on it these days.

As for timing, there were companies speculating well before '72 that copyright would be the game. Archival work found a copyright-based license agreement from IBM from as early as 1969. See https://www.create.ac.uk/blog/2018/11/14/the-first-software-....

That's not the same as saying the question was settled. After the Copyright Act amendment, it sure was.

I wasn't practicing law back then, but my secondhand understanding is that while it wasn't clear that copyright would apply to software, or how, savvy players largely expected some kind of protection for written software beyond trade secrecy.

There were all kinds of questions, theories, and proposals about whether that would happen under copyright law or perhaps through some software-specific regime. The US answer was clear when "computer program" was written into the scoping definitions of the Copyright Act. We still cite back to the commission that pushed that recommendation, CONTU, when debating loose ends.

No. That is not how law works in the United States.

If you'd like to learn more, try "Common Law" and "Stare Decisis" on Wikipedia.

This isn't a combo I think I've seen or read from other lawyers. Does it mean "identical"? Again, that's not what's required to make a point "settled"...or an outcome predictable.

The trial court opinion distinguishes Authors Guild, Google Books, Sony, and TV Eyes very explicitly in its opinion, starting on page 19. It's hindsight now, so worth fewer points, but I'm not the only one who thought distinctions based on "not giving out full copies" and "providing equipment" were coming.

The trial court did not say the Internet Archive isn't a nonprofit, a charity, or tax-exempt organization. The question under fair use analysis isn't whether the infringer is commercial or not, but whether the use is. It also comes up under other factors, such as effect on market.

The first and only mandatory piece of reading for discussing this case right now is the trial court opinion. Summary judgment was only possible procedurally because the two sides of the lawsuit agreed on the facts, only differing on how law applies to them.

That's what IA wants to believe. But it's just not the case that legal points aren't "resolved" or "tested" unless exactly the same situation shows up in court and gets ruled on. The law works in large part by analogy. Strong enough analogies can be predicted.

Here's from the trial court's summary judgment opinion against IA:

> Even full enforcement of a one-to-one owned-to-loaned ratio, however, would not excuse IA's reproduction of the Works in Suit.

Then there's the citation so many saw coming to a case called ReDigi, about a system for reselling authorized digital music downloads by ensuring there was only ever one digital copy. They lost, too.

There's another case out there, Aereo, about a company offering a warehouse full of TV tuners subscribers could stream from on a one-to-one basis. For technical legal reasons, that involved different aspects of the copyright law. But the case didn't go well for Aereo, either. Or for any of its competitors pursuing essentially the same business model.