License and Permitted Usage

[KiwiKilian]

A couple weeks ago the license of the project changed from MIT to FSL-1.1-MIT. It's totally understandable due to the amount of work you guys are putting into it, which is awesome. But this might create a legal problem for some users coming over from openapi-typescript-codegen. I'm especially concerned, many users didn't even notice due to #1140.

In our case we are working on government projects, which are to be released under a permissive license. This means we also sometimes have a whitelist of licenses to be used within our dependencies. Thereby the clearance to use this package is becoming troublesome.

I think it would be great to have a FAQ around the license choice. It would help to have clear examples of permitted and unpermitted usages. I also understand discussing this topic is difficult as most of us aren't lawyers and making statements towards this or any license can be complicated.

First of all, the FSL license was created by Sentry. We self-host Sentry under this license. Access is limited to employees and only we use this Sentry instance for our company projects, which we develop as contractors to our customers. I understand the license as permitting this usage, because we are not selling an direct alternative to sentry.io to our customers, but rather we are employed to develop and run a specific software for our customers. Only we use Sentry as a tool within our belt to monitor our applications.

There is similarity towards @hey-api/openapi-ts. We use it to create API clients directly in each project, which again is only one of our tools to create the software and the result itself is not a service or product which would allow OpenAPI client generation. Thereby I figure it's a permitted usage. But currently it is not 100% clear what services hey-api commercially provides. It's not publicly documented, what the GitHub action does, which I guess is going to be a commercial service?

I also see other problems about client side code: Sentry only licensed their main application under FSL, not their client packages. Did you consider to only apply FSL towards @hey-api/openapi-ts and keep @hey-api/client-fetch under MIT?

Furthermore, what license applies to code generated by @hey-api/openapi-ts? This would also be relevant if a client is published by itself as a package, which I guess would also be permitted usage?

[mrlubos]

Hey @KiwiKilian, you're spot on! I am open to consulting you (or others) on the license choice, but you've got it right. I will also link the Open Source is not a Business Model article by @dcramer which touches on this topic.

The main objective of me changing the license was to protect this package from freeloaders. I took Sentry's work as inspiration and applied their license as I identify with their views, but I am open to exploring alternatives if you're aware of any. The issue with MIT is that there's nothing stopping anyone from profiting off of others' open source work. As you pointed out, there's a lot of work being done on this project so I want to protect it rather sooner than later.

This was a pre-emptive move, I am not aware of any non-permissive usage as of today. Everything you listed is permitted. The specific scenario I had in mind when looking at the license is someone building a service like Speakeasy (openapi-typescript-codegen's sponsor) on top of this package.

You're also making a good point on the main application versus client packages distinction. I think you're right and the client packages should remain MIT, I will change that. Regarding the generated code, this is where a lawyer would probably know better, but my intent isn't to place any restrictions on it. My (perhaps naive) understanding is that as long as you're not charging people for generating SDKs, it's a permitted usage.

You can get a rough idea of what's next on the roadmap from my sponsors page. While that list isn't exhaustive, I am unlikely to go in a different direction in the near-term. Long-term, the objective is to create a service like Speakeasy, hence the license change. Does that help clarify things?

[KiwiKilian]

Highly appreciate your open words! I totally support your protection against the freeloading aspect.

I think relicensing the client side packages lifts the biggest concerns, thank you for reconsidering. I feel now much more confident in using the package, thanks! 🙏

[mrlubos]

@KiwiKilian I've added the FAQ page, let me know your thoughts please! https://heyapi.dev/license.html

[ChillyBwoy]

@mrlubos Sorry, but I'm totally confused about this license and the FAQ

First, I'd like to be clear: I don't own any commercial service that deals with code generation or development tools, nor do I plan to. My projects are mostly homebrew projects. Maybe someday I will make one of my projects public, but this industry has nothing to do with development tools. I respect and appreciate what you have done in the current project, it's really a great tool

You referred to sentry, which is an old SaaS project with a monetization system. There are many questions about sentry licensing (for example, is it a violation of the license to charge for customer support if users do not have access to sentry which is hosted internally and only available to employees?), but in general it means Do not use our source code to create a clone of our service, so it's clear, we can refer to the existing service. In the case of the current project, is there SaaS or any service? Because at the moment it looks like, when using it, users agree not to compete with a service that is not yet implemented.

Another issue is the license change. I realize that as a maintainer you have the right to do whatever you want with this repo, but has this PR been discussed in the community?

I'm sorry, but with the new license, this project looks more like closed software than open source software

[mrlubos]

@ChillyBwoy everything you listed falls under the permitted usage. You are correct, there's presently no SaaS as I am fully focused on this package.

In regards to the license change, I am open to discussion. It's still not clear to me what's your concern regarding the change?

[ChillyBwoy]

Sorry, i think I attached wrong commit. I meant this one 8eac24b

So, let me explain (but I must warn that I may be biased in case of licensing 😁) I've had some unpleasant experiences in the past with legal issues regarding licensing. Long story short: the legal department banned the development team from using a couple of libraries, because the company I worked for became a direct competitor of the library developer's company, and the development team had no choice but to replace some parts of the projects with our own invention in a hurry. Yes, that source of the problem was from the opposite side, but the problem is still the same. Not a great experience, I'd say 😁

Of course, if you are an independent developer or work for a company whose compliance allows you to use any license, there is no problem. But perhaps there are some people among the project users who may get into a lot of trouble with a sudden license change (@KiwiKilian gave an example in his original post). So, I see a big problem that the license was changed by a minor change in this release (commit), without prior notice

[mrlubos]

I get you! However, your example would be a perfect scenario of not permitted usage as soon as the company decides to directly compete. I understand it's not a pleasant experience as a developer, but it's no different than working on a project that gets cancelled after you've dedicated months to it, only because the management decided to change the strategy. Imagine you were on the other side of that situation as a library developer, what do you think would be an appropriate response there?

These things are annoying, but look at what's happening with WordPress and WP Engine right now as an example. If I kept the library MIT licensed, I wouldn't even have a recourse as it allows anyone to do anything with the source code. As a reminder, the current license converts to MIT after 2 years, at which point you'd be able to do anything with the source code again.

In terms of the release, I'll share a few thoughts. First, I am not aware of anyone using this package in a way that would fall under the not permitted usage. If they did, I would've notified them personally. That's for example the reason Speakeasy is sponsoring the previous package and not this one. I notified them in July that we'd be competitive in the TypeScript codegen and they decided not to pursue the sponsorship further.

Second, all packages are in v0. The definition of v0 is that any release can introduce breaking changes. For this reason, some companies won't use v0 at all. Otherwise, the homepage could've featured some recognisable logos already. If anyone uses v0, they should at minimum ensure their builds do not break. I should've mentioned the license change in the earlier release or perhaps added FAQ sooner, that's on me. I'll see what kind of feedback will there be now that it's hopefully more clear.

The reason to use v0 was exactly so that I can break things as there were many surface areas to cover before I'd feel comfortable saying this is ready for v1. In fact, if you look at the migration notes, the very first release I did removed useUnionTypes. This was a huge change and many people weren't able to smoothly transition as a result, including my friend Nicolas who created the fork that became this package. I felt very strongly about not supporting that design and I wanted to prevent any new users from getting locked into the wrong pattern. Had this been a v1 following semantic versioning, I'd feel more responsibility to provide a better upgrade experience. With the amount of work ahead, that simply wasn't something I wanted to be focusing on at the time. The good news is, v1 is getting close. After that, the releases will (have to) be more thoughtful.

Well, that was a long detour from the license discussion, but I wanted to provide more context. I am figuring this out as I go and who knows, this package might even become MIT licensed again. As it stands, I wanted to cover potential services in the not permitted usage as openapi-ts is the main asset at the moment. Another idea I have is for paid courses about the package, but some things would have to happen first to convince me that's a good product to focus on. The most likely candidate for the first paid product is still the GitHub integration.

[ChillyBwoy]

That sounds fair. Thanks for the clarification!