I have no clue what’s meant by “without download”, but this app just uses web assembly to inspect the archive in the browser. The sandbox they talk about most likely refers to the browser sandboxing.

So it pretty much boils down to “risking running malicious code is fine, because this app as a whole is treated as malicious by the browser”.

Licensing the source as GPL doesn’t really force the copyright holder (which is 100% BitWarden due to their Contributors Agreement^*, no matter who contributed the code) to do anything - they are absolutely free to release binaries built on the same codebase as proprietary software without any mention of the GPL.

For example if I write a hello world terminal program, release its source code under GPLv3 and then build it and give the built binary to you (and a permission to use it), you cannot force me to give you the source code for that build because I never gave you a GPL licensed binary.

If you were to take my GPLv3 source code and distribute a build of it however, you would have to license your binaries under GPLv3, because that’s the terms of the license I provided the source code to you under. Your users would then have the right to request the source code of those binaries from you. And if you released the build under an incompatible license, I (but not the users) could sue you for violating my license.

Their previous versions, still being under the GPL, would require them to release a change to make it usable on desktops.

License violations are usually not resolved by making the violator comply retroactively, just going forward. And it’s the copyright holder (so BitWarden themselves) who needs to force the violator to comply.

^* this is the relevant part of the CA:

By submitting a Contribution, you assign to Bitwarden all right, title, and interest in any copyright in the Contribution and you waive any rights, including any moral rights or database rights, that may affect our ownership of the copyright in the Contribution.

It is followed by a workaround license for parts of the world where copyright cannot be given up.

OK, cool. Just remember that the only entity who can sue in this situation is Microsoft (because when you contribute code to VS Code, you must sign a CLA that says you give Microsoft full perpetual rights to distribute your code under any license they wish - it is Microsoft who then “graciously” releases your code under a copy left license while also building their proprietary version of VS Code using it).

And Microsoft cannot use the code if it gets released under a copyleft license - that wouldn’t allow them to build their proprietary build with it. So the only one who can do anything has less than zero (because it would improve only the FOSS forks, which are meant to be inferior) interest in making these guys publish the source code as proper FOSS.

No, they are just in violation of the original license. That doesn’t mean they have to comply with it by properly open sourcing the project. Generally it’s also OK to just delete everything.

There were plenty of cases where commercial software included open source stuff in a way that violated its license, and the accepted way to fix the license violation was for the software/hardware vendor to stop using the violated project going forward. Usually they don’t even have to for example scrub old firmware downloads that improperly included FOSS bits.

Salt from the seawater

Yes, that’s exactly the problem - there’s nothing wrong with the encryption used, but it’s IMHO incorrect to call it time-based when it’s “work-based” and it just so happens that the specific computer doing the encryption works at a given speed.

I don’t call my laptop’s FDE time-based encryption just because I picked an encryption that takes it 10 seconds to decrypt the key.

def generate_proof_of_work_key(initial_key, time_seconds):
    proof_key = initial_key
    end_time = time.time() + time_seconds
    iterations = 0
    while time.time() < end_time:
        proof_key = scrypt(proof_key, salt=b'', N=SCRYPT_N, r=SCRYPT_R, p=SCRYPT_P, key_len=SCRYPT_KEY_LEN)
        iterations += 1
    print(f"Proof-of-work iterations (save this): {iterations}")
    return proof_key


def generate_proof_of_work_key_decrypt(initial_key, iterations):
    proof_key = initial_key
    for _ in range(iterations):
        proof_key = scrypt(proof_key, salt=b'', N=SCRYPT_N, r=SCRYPT_R, p=SCRYPT_P, key_len=SCRYPT_KEY_LEN)
    return proof_key

The first function is used during the encryption process, and the while loop clearly runs until the specified time duration has elapsed. So encryption would take 5 days no matter how fast your computer is, and to decrypt it, you’d have to do the same number of iterations your computer managed to do in that time. So if you do the decryption on the same computer, you should get a similar time, but if you use a different computer that is faster at doing these operations, it will decrypt it faster.

It’s a very short Python script and I’m confident I get the general idea - there’s absolutely nothing related to current time in the decryption process. What they refer to as a “time lock” is just encrypting the key in a loop (so the encrypted key from one loop becomes the plain text for the next one) for the specified duration and then telling you how many iterations were done. That number then becomes a second part of the password - to decrypt, you simply provide the password and the number of iterations, nothing else matters.

See? Hidden in an image, clearly that’s steganography! /s