[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [zen@freedbms.net: Veracrypt license - how to change it]

* On 8/7/19 9:31 AM, Zenaan Harkness wrote:
> In the interests of having Veracrypt be distributable by Debian,
> all Veracrypt code must be licensed accordingly.
> This can be done by public notice (see below).

Re-licensing can be a difficult, lengthy process and - as far as I've seen in
the one case I observed and took part in (mpv's core re-licensing, which started
in 2015 and is more or less done at the current time, but still not completely
finished) - doesn't work the way you'd like to have it.

> Doing so would be somewhat similar to how the MAME community caused
> their source code license to be changed from "problematic for Debian/
> the FSF etc" into something distributable by Debian etc (I think they
> went to GPL).

Skimming over articles, this situation looks different. The MAME project didn't
just inherit/fork code from another developer team, but was always headed by the
MAME development team itself, with changing personnel. Crucially, the project
lead that initiated the license change has already been head for 3 years at the
time, so I figure he'd be part of the project to some degree/contributing to it
for an even longer time already.

If anything, this example shows that re-licensing can be pretty easy IFF you
control most code and contributors can be easily reached (they obviously have
contacted contributors individually as well, not just issued this "public
notice"), but even that process is dodgy as best, as it wasn't carried out in
the public, as far as I can tell. There was no way to observe it.

> Here's what the Veracrypt community would need to do:
>  - make a public announcement that they will, after DURATION say 1
>    year, change the license to all outstanding source code inherited
>    from TrueCrypt, to be Apache/GPL/whatever

... and effectively ignore the original authors's copyright and original license.

>  - include in the announcement that any party objecting must contact
>    the developers at BLAH (email list address, or list of developer
>    email addresses)

That's not the way this stuff works. You have to assume objection UNTIL given
permission. I wonder if that would be a fitting metaphor: a burglar justifying
his actions by giving the sleeping original occupants an ample amount of time,
say, 10 minutes, to answer the question if they'd be okay with him taking
valuables. Since they haven't responded, he assumed that it's fine to proceed.
More tongue-in-cheek, naturally, but still somewhat fitting.

> The announcement needs to be published and made generally publicly
> available - e.g. at Slashdot, LWN, on the Veracrypt home page, etc.

Ugh, I didn't yet know I have to check these outlets regularly. Now I'm
terrified of having missed a lot of legal announcements for any project I ever
contributed to!

> Legally, this does a few things:
>  - gives general public Notice (legal concept), that something will
>    be done in the future, thus satisfying the general duty of care to
>    the public that something will be done which may affect the
>    interests of the public

I don't think this concept can be applied in this case. It might be a fine in
order to inform a mostly anonymous, but concerned mass, but the situation is
different here.

For instance, informing affected parties about upcoming communal changes via
public announcements/notices in the town hall (including about their legal right
to oppose the changes) is fine if the affected parties can not be easily
identified. Even if the administration had an up-to-date list of residents,
other affected parties might exist that are not registered at that place, but,
e.g. commuting.

On the other hand, this is not an acceptable procedure in legal proceedings that
involve a set of known parties. In this case, they must be notified explicitly.

This case is more alike the latter one.

>  - parties who remain silent, are thereafter (after time period
>    DURATION) "taken to have tacitly consented"

During the mpv re-licensing, code written/modified by unreachable contributors
was marked as not re-licensable and to be rewritten, which sounds like a much
saner approach.

> The above is legally sufficient to make such a change, and the MAME
> community is at least one example where this legal technique of
> Public Notice has been used effectively.

Again, I consider MAME's license change shady at best. A contributor with
considerable changes objecting to the change (even retrospectively, for instance
because the whole "public notice" thing didn't reach him) might easily pull the
project into interesting legal issues.

Having no public record likely doesn't help the case, neither.

> If an objection -is- raised, and if the person objecting is an actual
> copyright holder of certain Truecrypt code, then that particular code
> can thereafter be rewritten.  Other than this, objections are
> unlikely to be legally substantive and may well be able to be
> ignored.  Notwithstanding, all objections should be responded to as
> to what position is being taken in relation to that objection (this
> is part of the duty of care to the general public/ others in our
> community).

Careful, I very much misinterpreted that paragraph at first. My original reply
would have said "Wait, I may misunderstand this paragraph, but it sounds like
you're saying that code affected by direct objections *CAN*, but needs not, be
rewritten later on and that any objections would have no legal binding
whatsoever anyway and can be ignored?"

I assume that what you actually meant is that objections by non-contributors
have no legal binding and can be ignored, which is true, but also a tautologism.


The suggested approach sounds HIGHLY questionable to me. I personally fully
support the intention, but strictly oppose the mechanism.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: