Change license to AGPL
This commit:
- Updates the `LICENSE` file
- Start every file with something like:
// Copyright YEAR_FIRST_PUBLISHED Signal Messenger, LLC
// SPDX-License-Identifier: AGPL-3.0-only
---
First, I removed existing license headers with this Ruby 3.1.2 script:
require 'set'
EXTENSIONS_TO_CHECK = Set['.h', '.hpp', '.cpp', '.m', '.mm', '.pch', '.swift']
same = 0
different = 0
all_files = `git ls-files`.lines.map { |line| line.strip }
all_files.each do |relative_path|
if relative_path == 'Pods'
next
end
unless EXTENSIONS_TO_CHECK.include? File.extname(relative_path)
next
end
path = File.expand_path(relative_path)
contents = File.read(path)
new_contents = contents.sub(/\/\/\n\/\/ Copyright .*\n\/\/\n\n/, '')
if contents == new_contents
same += 1
else
different += 1
end
File.write(path, new_contents)
end
puts "updated #{different} file(s), left #{same} untouched"
I'm sure this script could be improved, but it worked well enough.
Then, I created `Scripts/lint/lint-license-headers` and ran it to auto-
fix a lot of files. This changed the mode of some files, but I think
that's actually desirable. For example,
`SignalServiceKit/src/Util/AppContext.m` previously had a mode of
`0755/-rwxr-xr-x`, and it's now `0644/-rw-r--r--`.
Then I fixed some stragglers and updated the precommit script.
See [a similar change in the Desktop app][0].
[0]: 8bfaf598af
This restores the behavior prior to
4a0141be41, where I made a mistake that
affect development builds.
Previously, the generated code looked like this, to prevent
instantiation of `SignalServiceAddress`es with no identifiers:
// This is a sketch!
let address: SignalServiceAddress? = {
guard hasUuid || hasE164 else { return nil }
let address = SignalServiceAddress(uuid: uuid, e164: e164)
guard address.isValid else {
owsFailDebug("address was unexpectedly invalid")
return nil
}
return address
}()
It makes sense (to me) to do this, because all proto fields are
optional. That means you can have a valid message that lacks both of
these fields, which is allowed. It shouldn't error.
However, I changed it to the equivalent of this, which caused an error
in `SignalServiceAddress`'s initializer:
let address: SignalServiceAddress? = {
let address = SignalServiceAddress(uuid: uuid, e164: e164)
guard address.isValid else {
return nil
}
return address
}()
This reverts that to avoid the debug assertion failure. I don't think
this ever affected "real" builds beyond some extra logging.
[Android][0] and [Desktop][1] have already removed this field. This
follows suit.
The highlights:
- `SignalService.proto` removes some fields by making them `reserved`
- `ProtoWrappers.py` updates our code generation to support addresses
that only have a UUID (previously, you needed both a UUID and E164
field)
- Most everything else is removing E164s
[0]: 9c266e7995
[1]: 2b0d3cab40
_This change should have no user impact._ And you can see that the only
changes to generated files are in comments.
Before this change, we used comments to denote reserved or deprecated
fields. This works, but I think we should instead use the `reserved`
keyword, which offers a few advantages. From [the protobuf docs][0]:
> If you update a message type by entirely removing a field, or
> commenting it out, future users can reuse the field number when making
> their own updates to the type. This can cause severe issues if they
> later load old versions of the same .proto, including data corruption,
> privacy bugs, and so on. One way to make sure this doesn't happen is
> to specify that the field numbers (and/or names, which can also cause
> issues for JSON serialization) of your deleted fields are reserved.
> The protocol buffer compiler will complain if any future users try to
> use these field identifiers.
This updates our proto files to use `reserved` instead of comments. It
also adds support to our wrapper script. (I moved a few things around in
that script, too, for consistency.)
I think this is a useful change on its own, but I think it'll make
things a little better when we deprecate some fields, which we're
planning to do soon.
[0]: https://developers.google.com/protocol-buffers/docs/proto3#reserved
We expose many of these builders to Objective-C, but Swift is unable
to map forward-declarations of those types (@class) back to the real
Swift classes because they're nested within the protos. Since we're
already using fully-qualified names even in Swift (e.g.
"SSKProtoContentBuilder"), nesting isn't worth the trouble it's
causing.
Shaves off about 20% of a deep serialization benchmark (that's
unfortunately using code that isn't checked in yet).
Also removes Equatable from oneof enums, which wasn't really doing the
right thing anyway when there were non-primitive payloads because the
proto classes didn't override isEqual.
The Swift compiler ought to be smart enough to prove that
copy-out/mutate/copy-in is the same as mutate-in-place for structs,
but it currently isn't clever enough to do that.
(See https://bugs.swift.org/browse/SR-11895.)
