Introducing SoftwareCompare: Objective data to find software that fits your needs!

General Project Showcase
22

(I’m not a lawyer and this is not legal advice)

could be interpreted by some as committed to protect a free philosophy in their product.

That would be a misinterpretation. Copyleft and permissive licenses are both foss and both permit users the same freedoms required under FOSS definitions. :slight_smile:

Also, the AGPLv3 in particular, while still FOSS, can be used in a quasi-proprietary way in practice. Weaponized Open Source

But I feel that a copyleft license complements AliasVault’s other trustworthy aspects.

You have yet to explain how licensing and trust relate, or why copyleft would be considered more trustworthy. If anything, the AGPLv3 in particular is sometimes an indicator of distrust, as it has a history of being used to bait and switch.

I can’t shake off the possibility that proprietary abuse could befall the software, like with what happened with MINIX and Intel.

Permissive licensing doesn’t mean someone can just take your code and make it proprietary. Code released under a FOSS license is FOSS forever, whether it’s copyleft or not. If anything, copyleft licenses like the AGPLv3 are more susceptible to being taken proprietary, as explained in the article I linked above. It makes the project a one way street, especially if they have a CLA. This is because they can always take their own code proprietary in future versions (code owners are not bound by their own licenses as they own the copyright). Sure, we’ll still have the old AGPLv3 version of the code, but that means we’ll be forced to release our changes as AGPLv3. Meanwhile they can take previous contributions proprietary because of their CLA. This isn’t a hypothetical, it’s a strategy that’s actively utilized.

1 Like
23

I’ll also note that the project you referenced appears to be using this exact strategy:

All contributors among other things have to:

You grant the Project maintainers a perpetual, worldwide, non-exclusive, royalty-free license to use, modify, distribute, and sublicense your contribution as part of the Project and any derivative works.

Note: sublicense.

It’s a clever trick to keep things as close to proprietary in practice as possible while still technically being FOSS. So ironically, the example you gave is actually a great counterexample to the idea that the AGPL is an indicator of trustworthiness :slightly_smiling_face: If anything, the AGPL (especially with a CLA) is an indicator of clever sneakiness, and is actually an indication of a restrictive and centralized project governance, as opposed to a free and open one.

1 Like
24

ProtonVPn no longer support port forwarding.
EDIT: Sorry, I was wrong.

25

What?! Pretty sure they do. They are proud to provide/have that feature.

Can you prove/provide a source for what you’re saying?

1 Like
26

The current line of thinking for including the copyleft license comparison in the trust category is that you can trust that proprietary code cannot legally be added to a distribution of the project. This avoids having a situation like Chromium where Google develops the project as open source, but distributes and promotes it with proprietary code through Chrome. This also leads to proprietary derivatives like Edge and Opera benefitting from open source code without contributing anything back. This comparison is on the site to ensure that the current project remains open source and that future projects do as well. I did not want to mislead people into thinking that they could fully trust a project that is copyleft. So, I included a tooltip explaining what a copyleft license means for a project, but I’m definitely open to improving this tooltip or changing the category it is in. I’d be happy to discuss possibilities further in a GitHub issue.

I’d also be open to adding a comparison that checks if the project doesn’t have a CLA since I agree that having a CLA does undermine trust that the project will remain open source/copyleft into the future. I’m unsure exactly what I would put for proprietary projects here, since they don’t have contributors, so we can also discuss the specifics of this in a GitHub issue.

27

(still not a lawyer, still not legal advice) :slight_smile:

you can trust that proprietary code cannot legally be added to a distribution of the project

Not necessarily, that depends on the license, the nature of the copyleft, and what constitutes distribution. Linux is GPLv2, but commonly ships with proprietary binary blobs. Other copyleft licenses like MPLv2, LGPL, permit combination in some form with proprietary software.

develops the project as open source, but distributes and promotes it with proprietary code

Why is this relevant to trustworthiness/independence? Chrome has no bearing on the FOSS status of Chromium. Chromium’s code is FOSS and legally must always be.

benefitting from open source code without contributing anything back

Again I’m questioning the relevance of this to trust/independence. This is of course aside from the fact that it’s not true, for example Edge in particular has upstreamed substantial features, like drumbrake.

This comparison is on the site to ensure that the current project remains open source

You seem to have a misunderstanding about what permissive licensing is. Permissively licensed software remains open source in perpetuity. This cannot be changed. Consider for example this line in the permissive Apache 2.0:

... each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license ...

I did not want to mislead people into thinking that they could fully trust a project that is copyleft.

The misleading part is making people think that copyleft has any bearing on trust or independence whatsoever.

CLA does undermine trust that the project will remain open source/copyleft into the future

You have misunderstood my point almost entirely. :sweat_smile:

With a CLA, the issue is copyleft. A CLA is significantly less problematic on a permissively licensed project, because the code owners are simultaneously granting a perpetual, worldwide license to sublicense the code. This means code owners and other contributors have similar rights.

With something like the AGPLv3 + a CLA however, this is not the case. A CLA with a permissive license is meh. A CLA with extremely strong copyleft like the AGPLv3 is a form of centralization and grants the project owners far more rights than other contributors. The code owners can use the code for any purpose, including taking it proprietary, whereas other contributors are bound by strict copyleft. In this scenario, copyleft causes a power imbalance.

I’d be happy to discuss possibilities further in a GitHub issue.

Sure, feel free to link it here and we can move there. Respectfully though, it seems like most of this is rooted in misunderstandings about software licensing. Copyleft has absolutely no bearing on whether a project is trustworthy or independent, except in a very negative sense when it’s combined with a CLA.

2 Likes
28

I am aware of both things, and it wasn’t a misinterpretation. Although permissive licenses do directly uphold the same freedoms as copyleft ones, copyleft ones have the potential to protect those freedoms by preventing forks from messing with those freedoms. MINIX upheld FOSS definition freedoms, but Intel didn’t. Now Intel ME is everywhere and people aren’t too fond of it.

In the case of copyleft, I could say “I can trust that forks of this project won’t disrespect FOSS freedoms”. It gives assurance that someone’s contributions won’t be used by forks in a proprietary way. If I contribute to Chromium, I contribute to Chrome, Edge, and Opera, which I may not necessarily trust.

It doesn’t necessarily ensure the core project itself won’t turn proprietary if there is a CLA (okay I may be misunderstanding this part), but it can complement a good track record of FOSS committal.

29

I have just created the github issue here:

If anyone has insight into this that they would like to share, feel free to join the discussion.

1 Like
30

copyleft ones have the potential to protect those freedoms by preventing forks from messing

This is the misunderstanding. Forks don’t alter/modify/“mess with” the license of the original project.

MINIX upheld FOSS definition freedoms, but Intel didn’t. Now Intel ME is everywhere and people aren’t too fond of it.

And MINIX still upholds the FOSS definitions

“I can trust that forks of this project won’t disrespect FOSS freedoms”.

That’s fine but I fail to see how it has any bearing on trusting the original project, which is the question here.

It doesn’t necessarily ensure the core project itself won’t turn proprietary if there is a CLA (okay I may be misunderstanding this part), but it can complement a good track record of FOSS committal.

If the code was made available under a permissive license, then you can do what you want with it even if there’s a CLA.

31

I could not find anything on this. Their site still says they support it here. If you’re able to link to a source, I’d be happy to look into this further.

1 Like
32

I just verified that I can still port forward on protonvpn :smile:

2 Likes
33

I am sorry, I mixed Mullvad and ProtonVPN.

1 Like
34

Dropping this here as well as it may be informative for folks. This site is (based on a quick skim) doing a good job capturing real issues with projects presenting themselves as FOSS despite having issues or not being FOSS at all, including the Copyleft+CLA issue I mentioned above.

Note that copyleft vs permissive is not one of the issues mentioned, except in a negative sense for copyleft when combined with a CLA :slight_smile:

1 Like