* 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. Mihai
Attachment:
signature.asc
Description: OpenPGP digital signature