Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change licences from MIT to MPL v2 #22

Merged
merged 2 commits into from
Sep 24, 2023
Merged

Change licences from MIT to MPL v2 #22

merged 2 commits into from
Sep 24, 2023

Conversation

robotlolita
Copy link
Contributor

@robotlolita robotlolita commented Sep 24, 2023

This changes the existing source code licence from MIT to MPL v2. The primary reason for it is to improve the guarantees that end-users will be able to audit the software they're given even if they do not download it from a the official github repository. Since MIT does not require source code to be divulged, or even that modifications to source code be stated, it does not fulfil that purpose.

Transparency is a core tenet of Kate's security (it is one of the reasons why all features must have proper formal semantics and a public threat model). While we cannot ensure that malicious actors will comply with the licence, we can at least mitigate some of the damage from changes that, while not malicious, still change the threat models that we communicate to end users and that they expect from Kate. At the very least, the MPL encourages people to be open about their changes, and Kate's informational text surrounding the licences now strongly encourages this as well.

Relicencing it under the GPL v3 was considered. However, since the kate-dist tool needs to embed the whole OS with the cartridge for standalone distribution purposes, that complicated matters a bit. Imposing Kate's licence and guarantees on external releases is a non-goal, and we already state that no security guarantees can be provided by us in those cases. Going with the MPL should break no existing uses that were served by the MIT licence in practice, and supported OS modifications are still a work in progress in any case.

The new licence applies from the next Kate release (so v0.23.9+).

Unfortunately MIT does not provide enough transparency rights to
end-users, and this was not considered when the project started.
Users should *still* be able to audit any distribution of Kate,
whether official or not, because all security promises in Kate
strongly depend on this.
@robotlolita robotlolita added c:kernel Changes to the Kate emulator kernel (requires strict audits!) c:tooling Changes to Kate's developer tooling/SDKs (relaxed audits) c:ecosystem Changes to Kate's userland ecosystem (relaxed audits) BREAKING CHANGE The patch is incompatible with previous versions of Kate labels Sep 24, 2023
@robotlolita robotlolita merged commit b41448f into main Sep 24, 2023
1 check passed
@robotlolita robotlolita deleted the patch/licence branch September 24, 2023 09:21
cute-the-niini added a commit that referenced this pull request May 10, 2024
This was considered already in a previous pull request (see #22), but OS
extension cartridges weren't properly considered back then since their
specific design was not very well formed, and the MPL does not provide
the necessary protections for them. This is a problem for some of the
items in the roadmap (e.g.: cartridges that provide OS extensions).

For example, suppose someone releases a cartridge that provides a new OS
theme to make everything look like a pastel-coloured pixel art game of
certain franchise. Such cartridge could change the visual behaviour of
all of the Kate operating system, but wouldn't require any of the
commonly powerful capabilities (e.g.: "passive network access"), and
still it could cause a lot of damage to Kate's security guarantees.

Much of the security guarantees we provide for third-party cartridges
ride on the [trust and resource indicator
bar](https://docs.kate.qteati.me/user/manual/security/trust.html). In
Kate code there's special code to make sure this bar communicates enough
information on whether the process is trusted (part of the OS) or not. A
theme has no obligation of maintaining the same, and there's no form of
static analysis we can employ to check either way. Whether it would be
an honest mistake (additional effort is required to make the visual
trusted/untrusted distinction) or a deliberate omission, the end result
is the same: players would not be able to distinguish which process
screens they can trust to carry the security and privacy guarantees Kate
communicates. As a result, users could end up making dangerous decisions
while being misled by their OS.

This is a scenario we want to avoid at all costs, and so we require
changes that are made directly to the OS (and thus impact these security
and privacy guarantees) to also provide the source code and build
instructions such that users can, realistically, audit what they're
running if they feel inclined to. The MPL unfortunately doesn't provide
this guarantee---it only covers changes that are made directly to files
marked as MPL-covered, but cartridges will contain new files that are
linked dynamically through the upcoming file system layer and extension
feature.

The reason the previous PR avoided using GPL was, primarily, because
releasing things under GPL complicates things a lot for end users. Many
open source licences are incompatible with it, and even versions of the
GPL are incompatible with each other. Sadly this complication appears to
be unavoidable if we want direct OS modifications to be auditable, so
it's better to just go ahead and make the changes before the project is
publicly available :')

In the interest of making the GPL extend only to changes that would in
some way change the OS behaviour and feedback directly, the licencing
change is restricted in the following way:

- It only applies to the Kate OS itself (i.e.: `kate-core`, `kate-api`,
`kate-bridges`, and `kate-desktop`), the build system (`make.js`,
`support/*`), and things that are used to build cartridges
(`kate-tools`, `kate-importer`, and `kate-publisher`). Technically we
could avoid extending it to the cartridge-making tools, but it's good to
reassure developers exactly how their cartridge gets built and what gets
included in it, and there are no drawbacks to either developers or
end-users.

- There's a special exception with linking dynamically to the runtime
API (`kate-api` and `kate-bridges`) so the vast majority of cartridges
don't get accidentally covered by the GPL --- there's no need for them
to, we already treat all regular cartridges as untrusted so they can't
subvert the security/privacy expectations we set.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BREAKING CHANGE The patch is incompatible with previous versions of Kate c:ecosystem Changes to Kate's userland ecosystem (relaxed audits) c:kernel Changes to the Kate emulator kernel (requires strict audits!) c:tooling Changes to Kate's developer tooling/SDKs (relaxed audits)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant