Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add AGPL-3 license #475

Merged
merged 1 commit into from
Mar 6, 2024
Merged

Add AGPL-3 license #475

merged 1 commit into from
Mar 6, 2024

Conversation

ArendPeter
Copy link
Member

@ArendPeter ArendPeter commented Feb 24, 2024

Disclaimer

The information in this write up is based on a very short dive into the topic. My definitions are base on how I understand the licenses but please correct me if I'm wrong

Overview

Vision: I want the star elections project to exist as a true open source project, but I also want private companies to have a clear reference point for implementing STAR without fear of legal issues.

Hence I suggest we have the star-server repo use an AGPL-3.0 license, and have the starpy repo using BSD 3. This will keep star-server open source, but allow private companies to freely use starpy if they're looking for a reference implementation.

  • AGPL-3 : This is the new standard for open source. The GPL family has strong copy-left protections which ensure that all derivatives must also be open source. AGPL also fixes various loopholes found in GPL.
  • BSD 3 : This is one of the more permissive license available. It will give companies free reign to use the software however they like without any requirements to keep it open source. I specifically chose this one over the other permissive licenses since BSD 3 adds an endorsement clause stating that usage and modification to the starpy library doesn't imply that the Equal Vote Coalition endorses those changes (see companion PR Add BSD3 license starpy#27)

Other starpy options

These are other options I considered for starpy

  • Public Domain : This another extreme of permissable, but BSD3 is preferable since companies are more comfortable using an official license
  • MIT : This is the most popular of the permissive licenses, but it doesn't have the endorsement clause so I prefer BSD3
  • LGPL : This is a weaker version of GPL-3 that allows the code to be privately used as a library, but still requires direct modifications to the library to be open source
  • MPL : Similar to LGPL except it also allows you to privately copy the code and add other code files along side it.

The LGPL vs MPL approach is nice if we're paranoid about a company consuming our code and then making fundamental changes to the STAR algorithm. If we wanted to go that route then we'd pick between the 2 based on how we want starpy to be consumed (either as a library or a script that they copy).

However going down the LGPL/MPL route would also open up questions on whether companies can rewrite the code in a different language. Under LGPL/MPL a company wouldn't be allowed to rewrite the code and still use it in a proprietary project. This is because rewriting the code counts as a derivation and derivations under LGPL/MPL are required to be open source. That's why I'm advocating for BSD3 over LGPL/MPL. BSD3 removes any friction for people using the license.

Future Equal Vote Certification project

In previous conversations we were hesitant to make these projects too open since we ideally still wanted to have veto power over people who implemented the voting methods incorrectly. However after more discussion we realized that veto power wouldn't be compatible with true open source ethos. (I recommend reading Sara's comment below for clarification on this)

Instead I suggest we create a Equal Vote Certification program. Organizations freely copy and modify our starpy code, but after that they'll need to receive our certification in order to be an officially approved implementation of STAR Voting.

We're essentially using the certification as a carrot instead of using the license as a stick. But that said we still have the STAR Voting trademark, so we can always revoke access to the term "STAR Voting" if people use our brand incorrectly.

References

Overall license overview: https://www.youtube.com/watch?v=UMIG4KnM8xw

Another good overview: https://www.youtube.com/watch?v=RVhCXWoNjfM

AGPL vs GPL: https://www.youtube.com/watch?v=5_n1PN0mWWQ

How companies take advantage of normal GPL: https://www.youtube.com/watch?v=cXLFXV6zIyk

Rewriting into different languages: https://softwareengineering.stackexchange.com/questions/208776/would-copyrights-drop-if-i-re-write-open-source-project-into-another-language

Public Domain vs MIT : https://opensource.stackexchange.com/questions/5601/can-software-be-both-mit-licensed-and-in-the-public-domain

@penyuan
Copy link

penyuan commented Feb 27, 2024

Thank you @ArendPeter for this super thoughtful write up! ❤️

First of all, I generally agree with your suggestion of licenses for both projects. I think star-server is absolutely worth keeping open source with a strong license like AGPL, and that BSD3 is a good choice for a (relatively) simple reference implementation like starpy. I, too, like the endorsement clause in BSD3. The rest of my comments are therefore relatively minor...

  1. The carrot (certification program) and stick (trademark enforcement) approach sounds good. If it's up to me, I would put more emphasise on the certification program because not only is it a carrot (i.e comes across as more positive and welcoming), but also that certification might eventually become a revenue source. For example, one day companies might pay to get Equal Vote Certification for a STAR voting machine (?!?!).
  2. Your analysis of the LGPL/MPL situation is congruent with my understanding. I'll just add that a potential effect of using LGMP/MPL is that we will implicitly encourage companies who make use of starpy to also open source their work, and slightly discourage closed source derivatives. I personally see this as a plus, because IMO implementations of something as critical as voting should be open source anyway. In other words, the license choice would imply whether we want to make this additional political statement. But I think BSD3 is totally fine, too, so happy to go with the group's decision.
  3. Nitpicky pedantic legal point regarding: "[BSD3] will give companies free reign to use the software however they like without any requirements to keep it public domain." -> Actually, all creative works (like code) are automatically subject to copyright restrictions upon creation. Open source licenses make use of the power given to the copyright holder to explicitly grant others permission to use the work, while public domain is legally defined as the absence of any copyright. In other words, open source-licensed software are not in the public domain. The public domain option you listed for starpy is actually implemented by a public domain dedication (such as via the Unlicense or CC0), where you relinquish copyright altogether. The end result is almost identical because there are no restrictions on public domain works, but one happens in the presence of copyright (open source licenses) and the other in its absence (public domain dedication).

Hope some of this is useful!

@ArendPeter
Copy link
Member Author

Thanks for the response, and the clarification!

I've editing out the public domain reference to avoid confusion

Copy link
Collaborator

@mikefranze mikefranze left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved!

@ArendPeter
Copy link
Member Author

This was approved in a meeting on 3/5/2024 with the following atendees

  • Mike
  • Arend
  • Sara
  • Jon
  • Adam

@ArendPeter ArendPeter merged commit 775f3c8 into Equal-Vote:main Mar 6, 2024
3 checks passed
@ArendPeter ArendPeter deleted the license branch March 6, 2024 03:55
@SaraWolk
Copy link
Collaborator

SaraWolk commented Mar 7, 2024

Adding a few points of clarification.

  • Arend writes: "In previous conversations we were hesitant to make these projects too open since we ideally still wanted to have veto power over people who implemented the voting methods incorrectly. However after more discussion we realized that veto power wouldn't be compatible with true open source ethos.

This is incorrect. We were clear from the beginning that these two goals are inherently in conflict. That wasn't a "realization." We were trying to find a middle ground that would allow us to share our code widely and freely as desired, but with our consent and user agreements on use regarding quality of the implementation, specifically with regards to ensuring clear and correct voter education and instructions. Licencing is not a black and white choice, there is a spectrum of options from always shared to never shared and everything in between.

  • I'm authorizing Arend's proposal for now because we need a working license and currently have none. I think this is the absolute best choice we can make with the information we have access to at this time. I'm personally not 100% confident about it, but I do not have a better proposal. I don't feel like we've had the benefit of experience from a licensing or trademarking lawyer or expert who would be able to advise us carefully. To date we've only heard from the open source community on their position and rational, which has been extremely helpful, and I/we have done a fair bit of our own preliminary research. Still, until we have heard from both/all sides (open and proprietary, plus the middle ground) my recommendation to the board will be to adopt the current proposal as official but preliminary, pending a more thorough review when our campaign cycle isn't in full swing and we can retain a professional to advise. This decision will need to be further authorized by both boards of directors.

In the meantime, we will be pursuing a number of follow ups, including more work on trademarking and the Equal Vote Elections certification program as outlined above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants