XertroV
commented
4 years ago One way to think of this is what would we want other actors NOT to be able to do:
e.g.
Closed XertroV closed 4 years ago
XertroV
commented
4 years ago One way to think of this is what would we want other actors NOT to be able to do:
e.g.
KipCrossing
commented
4 years ago 
SimonBiggs
commented
4 years ago With regard for what license to choose. In Australia, for this kind of software, where liability for negligence and liability for loss of revenue or profits may be very real outcomes, I personally would want a license that appropriately covers those cases. From what I understand the Apache-2.0 license does cover those (https://choosealicense.com/licenses/apache-2.0/).
With regard to the GPL and MIT see the following statements:
Australian courts will give an exclusion clause its natural and ordinary meaning but, if there is any ambiguity, it will be construed against the person seeking to rely on the clause ... If liability for negligence is not expressly excluded, the courts may read down the exclusion clause so that liability for negligence is not excluded. It is best therefore to specifically exclude liability for negligence. There is a real risk that the GNU General Public License does not exclude liability for negligence of the licensor.
...
The GNU General Public licence (and a great many traditional proprietary software licences for that matter) does not adequately exclude liability for loss of revenue or profits. Also, there is a risk that the exclusion for loss of data will be read to apply only when that is a consequential loss and not when the loss of data is a direct and natural result of the breach (for example, a breach of an implied condition or warranty).
-- https://eprints.qut.edu.au/7404/1/open_source_book.pdf
The Apache 2.0 license however does appear to cover these cases:
8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.
-- https://www.apache.org/licenses/LICENSE-2.0#no-liability
With regard to a few of the comments of what you want in a license.
we want other actors NOT to be able to do ... forks the app and distributes a new copy
With regards to making it so that others can't "fork the app and create a new copy", that's open source 101. All open source licenses will allow that, it is one of the four essential freedoms of free software:
We (maybe) don't want them to be able to add telemetry that would enable them to see how individual voters were voting (outside of what the voting system already does).
Many of the software that Google and other software companies use is GPL software. GPL doesn't protect against adding telemetry. One way to help make sure voter privacy is kept is to make it clear that this version within this repository doesn't do that. Ideally that feature should become part of this software's brand, once that's the case, any fork that removes that feature shoots themselves in the foot.
Should you wish to go with a copyleft license GPL software does allow for "Additional Terms". It is possible to have the Apache license be included under the "Additional Terms" clause. Given this sort of application may be hosted over the web I would er on the side of the AGPL instead of the GPL.
An example license header that includes both the AGPL and Apache is given below:
Copyright (C) 2020 PyMedPhys Contributors
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version (the “AGPL-3.0+”).
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Affero General Public License and the additional terms for more
details.
You should have received a copy of the GNU Affero General Public
License along with this program. If not, see
https://www.gnu.org/licenses/agpl.html.
ADDITIONAL TERMS are also included as allowed by Section 7 of the
GNU Affero General Public License. These additional terms are
Sections 1, 5, 6, 7, 8, and 9 from the Apache License, Version 2.0
(the “Apache-2.0”) where all references to the definition “License”
are instead defined to mean the AGPL-3.0+.
You should have received a copy of the Apache-2.0 along with this
program. If not, see http://www.apache.org/licenses/LICENSE-2.0.Thanks a lot for your input @SimonBiggs,
Many of the software that Google and other software companies use is GPL software. GPL doesn't protect against adding telemetry. One way to help make sure voter privacy is kept is to make it clear that this version within this repository doesn't do that. Ideally, that feature should become part of this software's brand, once that's the case, any fork that removes that feature shoots themselves in the foot.
This is a good strategy. Part of the reason this Issue has been sitting here for a while is because of the tension between two of our values Open-source software and voter privacy. I would go one further and give our code a tick of approval. Perhaps something like; Approved by SecureVote (Just brainstorming). And when the code is forked and modified, the "check if approved" link would fail until the code was checked.
okdaithi
commented
4 years ago Adding some feedback from conversation with a friend who has experience with large open-source projects:
You have two levers to play with here - your trademark and the license/copyright. You can control an open source project via the trademark... Red Hat does this to some extent with their branding and actually forces forks to remove all of their brand (not that difficult but they have a level of control through this). Trademark is a smart option here.
Personally I prefer to default to as open as possible but you are in a tricky situation because of the secure.vote IP... does their license allow you to share your code and for others to fork it?
I highly recommend reading a bit of Pieter Hintjens (sadly passed away but I'm a huge fan of his): Ten Rules for Open Source Success - http://hintjens.com/blog:95 How To Capture an Open Source Project - http://hintjens.com/blog:68 The Castle and the City - http://hintjens.com/blog:47 Good, Cheap, and Fast - PC3 -http://hintjens.com/blog:23 How to Make Money from Open Source - http://hintjens.com/blog:27
Hintjens says:
Preventing Capture There is only one model I know that prevents capture of an open source software project, and that is: A GPL-family license (or MPLv2, which works the same). Distributed copyrights. This is how I construct the open source projects I start, and it's the requirement for any community I join. Your right to make money does not include the right to use my work in a competing product, unless that's reciprocal.After reading these short blog posts I think you will want to read some of his books.. Culture and Empire is awesome, so is Social Architectures. The others equally so (and quite short). Well worth reading as you are trying to build a community and that is what Hintjens did as well.
His books are all on github but if you buy a book it will support his family (https://github.com/hintjens/cultureandempire and https://github.com/hintjens/socialarchitecture).
RE the patent... not sure what to do but perhaps suggest you perhaps use it as a defensive thing to protect the community?
KipCrossing
commented
4 years ago tl;dr? GPL 3.0 +Apache 2.0 + trademarks
Thanks for that @okdaithi , I really like the reading list.
Personally I prefer to default to as open as possible but you are in a tricky situation because of the secure.vote IP... does their license allow you to share your code and for others to fork it?
It's just the UI in this repo so far, so I don’t think we need to worry about securevote IP. It may be important for other repos or if the scope of this one increases.
We also need to keep in mind the reason for valuing open-source software and making our project open-source. It's not necessarily to contribute to the open-source/free software community, rather, it's to get voter confidence in our solution by allowing them to review how we did it. For example, it shows that votes are private and there is no shifty telemetry. Therefore we should probably go with a copyleft licence AND if we don't want it to be used in shiny, better advertised, proprietary software (the likely candidate for telemetry) we should go with a strong copyleft licence, ie GPL 3.0:
You may copy, distribute and modify the software as long as you track changes/dates in source files. Any modifications to or software including (via compiler) GPL-licensed code must also be made available under the GPL along with build & install instructions.
Being on Github, we need to allow forking; see here. So, how should we help to protect voters using clones from nasty forks, I think, a potential solution could be a “secure-vote tick of approval” (with logo) and/or a “supported by Flux” is a good defence (Splash page and README).
That said, we NEED to protect our contributors if we want to attract them and therefore, we should include Apache 2.0 as @SimonBiggs suggested. Perhaps we should also include the Apache license in the lib, test and assets directories; where the work will be done.
Some final licence checks on packages and libraries:
Flutter - BSD cupertino_icons - MIT Pdf_Viewer_Plugin - MIT path_provider - BSD http - BSD pie_chart - MIT flutter_login - MIT
We should check the licences of all the external packages/libraries we use before using them.
In summary; GPL and trademark to protect voters and Apache 2.0 to protect our contributors.
SimonBiggs
commented
4 years ago As a note, if someone was to host your app as a website the GPL wouldn't cover that case as the source code nor the executable itself wasn't being distributed in the traditional sense, it is staying on the server.
The AGPL covers cases that host the software online.
KipCrossing
commented
4 years ago The BSD licence (used by flutter ^) looks like a great licence to consider as it's simple and covers both of our requirements:
It seems to have a pretty robust warranty disclaimer:
IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
By using an approved by securevote sticker, people who make forks cannot include it unless with written consent:
Neither the name of Securevote Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
SimonBiggs
commented
4 years ago That does address my liability concerns. It does however not grant patent rights, so without grant of patent rights I myself would rather not be [edit] creating my own forks/contributions especially knowing that there is a patent on the governing software. I don't see myself personally being a contributor in this space any time soon either way though, so don't weight my opinion too highly in this space. [/edit] [delete] either running the software or providing pull requests. [/delete]
KipCrossing
commented
4 years ago @SimonBiggs could you please flesh out your reasoning a bit more for me? Why you'd want patent rights and running the software? It's all a bit new to me.
SimonBiggs
commented
4 years ago Here's a reasonable overview:
On Wed, 1 Apr 2020 at 05:52, Kipling notifications@github.com wrote:
@SimonBiggs https://github.com/SimonBiggs could you please flesh out your reasoning a bit more for me? Why you'd want patent rights and running the software? It's all a bit new to me.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/voteflux/voting_app/issues/7#issuecomment-606808317, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSBK67ZST5P563ZLZK5C3LRKI3VXANCNFSM4LEAIZ3A .
KipCrossing
commented
4 years ago I created GPL + Apache here: #15
For review. Please check to see if I've missed anything.
Thread for discussing license details.