[FEATURE] Please consider a copyright license that protects the users of this software.

[zander]

Your project is labeled to use the MIT license, which is an open source license but it has the strict allowance that code under this license can be re-released by anyone later as closed source.

The direct effect is that while todays release is open source, there is no way to know that next month your organization does not decide to relicense to a closed source version. We just have your promise to not do that.

This is a huge risk to merchants. Merchants that would use this product want to receive updates, may want to pay someone to build features and generally want to make sure that they don't lock themselves into a dead-end project.

Maybe also relevant for your own motivation is that any competitor can come and fork your project and compete against you with a closed source project using your own code as a basis.

Describe the solution you'd like

Please consider relicensing your project to use a so called "copyleft" license which disallows you or anyone else from using this code against the userbase. I personally prefer GPLv3 for this.

Additional context

In Bitcoin Cash we had several cases where companies did follow the route I explained, which cost the community a lot.

The first is that the company nchain has relicensed their fork of one full node to no longer be open source. Code that goes in there can not be copied by others, they had some rule about the code being limited to their chain only.

The second is that the Bitcoin,com wallet was forked from another and after a year of development and getting a lot of people using their product, they stopped posting sources. They effectively made it closed source.

Neither of these actions is possible with any of the GPL licenses. Please consider protecting your users by adopting a GPL license.

[MrNaif2018]

Thank you for your detailed explanation! MIT license is one of the most widespread licenses currently, that's one of the reasons we picked it-simple but good. MIT license just sets basic rules to be followed by everyone, while GPL licenses, as I know, are way too strict, and have a lot more conditions.

Basically, why I think the MIT license should be left: it allows anyone to modify (i.e. fork and maintain their version), use and redistribute the app.
So even if (but it won't happen as the project sources will always be open, it is required for our docker deployment, plus python code itself is hard to hide) the project won't be maintained, anyone can fork and people can switch to that fork. But as I said that won't happen and the project will be maintained. So the users and the maintainers will be protected.

Ah and also, there is no organization existing, it's just another open source project with volunteers doing it.

I understand what do you mean, but many open source projects, even quite big, including many payment processors, all use MIT license, and that's actually the first time I hear about this problem.
I haven't seen a lot of projects using GPL license.
Also if I remember, if we use GPL license, all projects using bitcartcc will be forced to be with GPL license too? I don't want to restrict users.
To me actually, licenses don't matter much but the actual code does, but that's just me (:

[zander]

I haven't seen a lot of projects using GPL license.

It is by far the most used license if you count something as simple as packages software for a linux distro. So if you wonder who uses GPL, you just look at your local linux distro. Also things like the Linux kernel, OpenOffice, KDE, mysql, git and literally 10s of thousands of other large projects. The point is that GPL license protects the users and it protects contributors.

Basically, why I think the MIT license should be left: it allows anyone to modify (i.e. fork and maintain their version), use and redistribute the app.

This is the case for all open source licenses (see OSI).

So even if [snip] the project won't be maintained, anyone can fork and people can switch to that fork

Ditto. That is the basis of all open source licenses.

that's actually the first time I hear about this problem.

A lot of people are not aware of the issues surrounding this, and the two examples where this went wrong are real and are painful to users.

The simple point is that GPL is nearly the same as MIT (or any BSD like license) exept for the points where MIT can be used against you and your users. So GPL allows you to do all the things you described, as those properties are the basics of all open source projects. There would be no difference to you or your users in freedoms you have.

The only difference is that should you go for GPL then users are not allowed to close source it or to put a different license on it which forbids you to take their improvements.

The premise of this being a volunteer project makes it harder to sell to merchants. The ability for you to just close-source this is the part that really makes the risk very high.

[MrNaif2018]

The only difference is that should you go for GPL then users are not allowed to put a different license on it which forbids you to take their improvements.

So that's what I want to avoid, restricting the projects using bitcartcc in choosing license or anything.

The premise of this being a volunteer project makes it harder to sell to merchants. The ability for you to just close-source this is the part that really makes the risk very high.

Well, one day it might become my full-time job, who knows (:
But the project won't definitely be left unmaintained in the open source.

The reason above is the only thing why I am against GPL.

I will check GPL in-detail and think more

But what if, for example, I want to change license. I heard this is a painful process and every contributor should agree on this? Or that's not so?

Also there are lots of GPL flavours (GPL, AGPL, GPLv3, v2, etc.)-which one is better?

[zander]

Thank you for keeping this discussion open!

As I wrote on Telegram the usage of MIT allows everyone to do anything. It is like you starting to work for a company with an agreement that they can do anything. Its nice, you get paid. Until it is not nice, they can fire you or make you do work you don't want to do. The GPL (and other copyleft licenses) are thus restricting what people can do with the code in order to protect you and your users.

Sometimes this isn't worth it: the BitcartCC-store repo is meant to be copied and altered, an MIT license there is just fine.
At the same time I see there is a reluctance to want to restrict people using your code too much, so when in doubt maybe just keep it without the protections, and keep the MIT licence.

I'd change these to GPL:

• bitcart-daemons
  (running on servers in the background), they extend the functionality of Electrum/EC (MIT license) and use them as a python lib+Merchants API-i.e. web api, part of the ecosystem and deployment
  TZ: These likely would benefit from being GPL.

• bitcart-sdk
  SDK, allows to easily use daemons, it's a wrapper around daemon's JSON-RPC interface. It can be used in other projects for different functions, and it is also used by Merchants API itself, so it's included into deployment this way.
  TZ: These likely would benefit from being LGPL. People can still use the SDK in closed source software that way.

The places where merchants would clone and modify the git repo is likely easy to keep MIT. Major features created by those merchants will then not be something you can ask them to share with you, at the tradeoff that people feel more secure that way. From a legal perspective there isn't much difference.

Repos publishing docs, websites etc really don't need the GPL protection either.

• bitcart-admin
  admin panel, part of the ecosystem and deployment
• bitcart-store
  same but a store
• bitcart-site
  source code for the official site
• bitcart-blog
  same but for our official blog
• bitcart-docs
  documentation (.md files)
• bitcart-media
  media resources-logos, posters etc which can be used by others when referencing bitcartcc or just when someone needs a high-quality version of our logo
• launchbitcartcc
  a go program for easy launch on lunanode hosting provider, hosted on our demo server but anyone can run it
• bitcart-woocommerce
  whmcs-plugin.
  plugins for woocommerce and whmcs, written in php, I don't know php and haven't written them by scratch but used existing examples and modules, cleaned them up and adapted for our project
• docker-compose-builder
  docker-compose for different architectures, for easy installation on any machine, just packing docker-compose binary in a docker image as the final result of a docker build, used as a part of our initial deployment setup
• bitcart-docker
  deps - Dockerfile's of additional services, like Tor and others
• docker-gen
  forked jwilder/docker-gen with some improvements, used in our docker-compose ecosystem of services
• jsonrpc
  forked ybbus/jsonrpc with some improvements, used for our CLI (https://github.com/bitcartcc/bitcart/blob/master/cli/bitcart-cli.go)

I have to admit I didn't understand the bitccl repo, I'm not sure about the details. Maybe LGPL would be best. But I didn't look deeply enough into this one.

• bitccl
  language for merchants for checkout flow automation-can be used as a standalone python library (there is a PyPI package), and also it will be used by Merchants API to provide additional functionality, so part of the deployment too

[MrNaif2018]

Thank you your ideas!
So admin panel actually can stay MIT, right?
I agree about main repo being gpl.
About SDK being GPL, as it doesn't restrict the usage then it's fine. But why is GPL needed in this one, if it's more of a library? To protect users of a library, or how?
About bitccl, if to not go into details, it's the same in the use cases as our SDK-can be used as a standalone lib, and it is used by our deployment component (Merchants API)

[zander]

About SDK being GPL

I suggested a slightly different one the LGPL. The Library-GPL (or officially called the 'lesser'). https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

This one is a middle-ground between an MIT style license and the GPL. It allows people to use it in closed source software, it als allows people to sell that closed source software which uses your library.

[MrNaif2018]

Ok, I see.
Then probably, we would do it this way:
main repo-GPL
SDK and BitCCL-LGPL
others-MIT

And if I add a new component, it would also be MIT. But if I add a new library, it would be LGPL. But no new repo will be GPL, it'll be just for the main one.
Also just a side question: in MIT there is a copyright year. Should I update it every year, or should it be a time range (2019-2020, etc.)?

[MrNaif2018]

Also, about LGPL being in the middle between MIT and GPL, that you said it allows people to use it in closed source software and it also allows people to sell closed source software which uses the library-doesn't MIT also allow this?
Also, should AGPL be used over GPL for server code (main repo), or GPL is fine too?

[MrNaif2018]

I was also suggested to take a look at this license: https://github.com/tdlib/td/blob/master/LICENSE_1_0.txt
Is it the same to MIT or GPL?

[zander]

in MIT there is a copyright year. Should I update it every year, or should it be a time range (2019-2020, etc.)?

This is a copyright law requirement. This is similar between any license you pick. Check wikipedia.

What you want to do is update the year whenever you change the file.

Also, about LGPL being in the middle between MIT and GPL, that you said it allows people to use it in closed source software and it also allows people to sell closed source software which uses the library-doesn't MIT also allow this?

What I wrote was about how the LGPL is different from the GPL, indeed in ways that makes it closer to MIT license.

Also, should AGPL be used over GPL for server code (main repo), or GPL is fine too?

That is up to you. I personally say that GPL is fine as it protects the merchants and I think that is the benefit adopting the GPL brings to your project: better protection for your users.

I was also suggested to take a look at this license: https://github.com/tdlib/td/blob/master/LICENSE_1_0.txt
Is it the same to MIT or GPL?

This is what the FSF writes about it:

This is a lax, permissive non-copyleft free software license, compatible with the GNU GPL.

The protection you get for yourself and your users is generally speaking called copyleft, a smart name as it turns copyright (which protects only the author) on its head and instead protects the users. This is not a copyleft license, but you can copy code published under that license into GPL applications.

The boost license has various of question marks in table on the license-comparison chart on wikipedia. That doesn't sound good to me.

[MrNaif2018]

So if I change the license I should use current year? Or leave the copyright year as is?
Also, if MIT and LGPL are very similar, why not keep the python libraries MIT too and make only the main repo GPL?

Also about GPL itself, I heard it requires a COPYING file. May I put the GPL license text in LICENSE file? Also the license doesn't contain the copyright notice. I don't want to add copyright comments to every file, so could I just create NOTICE file and put it in there?

[zander]

So if I change the license I should use current year? Or leave the copyright year as is?

You don't change copyright years, copyright is the basis for all licenses (even closed ones) and changing license has no effect on things like the year.

I have things like "2016-2020".

if MIT and LGPL are very similar

Oh, I'm sorry, that was not what I wanted to say at all.

The LGPL allows users to do more things with the project than GPL.
LGPL is different than MIT because it does not allow you or other developers to close source the library itself. In the cases I described before, you are not allowed to close source the library. This is also a benefit for the customer, but as described before that also protects you yourself.

I heard it requires a COPYING file.

See https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/licensing-a-repository

May I put the GPL license text in LICENSE file?

Yes, that is suggested. This makes github auto-detect your license. Browse around github for plenty of examples.

so could I just create NOTICE file and put it in there?

Absolutely! Just please make sure that people that contribute a non-trivial amount of code add their email address there to make clear they also have a copyright claim.

[MrNaif2018]

Ok, I see. Will probably use a time interval like 2019-2020 and update once a year (:
So I will put GPL license text in the LICENSE file
But definitely all the contributors shouldn't be placed into the NOTICE file (or maybe there is a better name, like, COPYRIGHT, which is less generic? Is it used?). If you mean non-trivial ones only, maybe I could do like Copyright (c) 2019-2020 MrNaif2018 <https://github.com/MrNaif2018> and the BitcartCC core team
What do you think of that? By core team I mean current members of the bitcartcc organization

About encouraging contributors-check our readme, we have a list of every contrubutor there

And about LGPL in the libraries, should it be like a LICENSE file, and a LICENSE.lesser file for LGPL? As it requires both license texts to be there.

[zander]

sounds great.

The law says that every non-trivial content any person writes is their copyright. It would be useful to register that, especially if you don't assume that the git history is going to be there always.
This is the reason to have one place to have contributors listed. You can put it in release notes, you can have a contributors file, anything you want, really. The point is that you identify each copyright holder. A "core team" entry is not a copyright holder and it doesn't have much effect if you list that.

And about LGPL in the libraries, should it be like a LICENSE file, and a LICENSE.lesser file for LGPL? As it requires both license texts to be there.

You can have multiple license files in a single repo, if you have multiple licenses in that repo. But if you have multiple licenses, you need to have the specific license stated in each file.

Which repo needs two licenses? I thought each repo would have only one license.

[MrNaif2018]

Ok then, then I'll not change the copyright line. But contributors are already listed there:
https://github.com/bitcartcc/bitcart#contributors-
Not two licenses. When reading LGPL license, it says that I must include both GPL license text and LGPL one, even if I only need LGPL license

[MrNaif2018]

I have created a poll in our official group.
If our community accepts it, we will do this
https://t.me/bitcartcc/3011
https://t.me/bitcartcc/3012

[zander]

Not two licenses.

Ah, right, yeah, thats a bit weird. But there are nice instructions. I always look at the FSF as they originally wrote the thing. They write:

If you are releasing your program under the Lesser GPL, you should also include the text version of the LGPL, usually in a file called COPYING.LESSER. Please note that, since the LGPL is a set of additional permissions on top of the GPL, it's crucial to include both licenses so users have all the materials they need to understand their rights.

I saw the polls, awesome!

[MrNaif2018]

If you are releasing your program under the Lesser GPL, you should also include the text version of the LGPL, usually in a file called COPYING.LESSER. Please note that, since the LGPL is a set of additional permissions on top of the GPL, it's crucial to include both licenses so users have all the materials they need to understand their rights.

Yes, that's what I was talking about. Could I name the files LICENSE (with gpl text in it) and LICENSE.lesser (with lgpl text in it), or is it not widespread?
Same about COPYRIGHT file vs NOTICE file

[MrNaif2018]

Done. Thank you for your suggestion and help. Looking forward to seeing more feature requests from you in the future (:

[MrNaif2018]

@zander Hello! Sorry for bringing up an old issue.
I have accidentally found the ongoing debates on requests/chardet license issues due to it (chardet) being LGPL. Some projects are unable to use LGPL, for example pip can't be MIT license because of that, and some license issues arise.
See:
chardet/chardet#36 (comment)
pypa/pip#9824 (comment)

When moving the SDK to the LGPL license I exactly wanted this not to happen, to not restrict users in any way.
What do you think, maybe it should be left MIT? As for the main project repository, if LGPL limits some users of the SDK, does GPL limit them too?

[zander]

There is unfortunately a lot of push by companies like Microsoft and others to create conusion around open licenses. I wrote a comment on the most recent thread explaining that their basic assumption of LGPL being incompatible is simply wrong.

General rule; anyone not altering your sources can use your LGPL stuff. If they say otherwise they are 99.9% likely wrong.

[MrNaif2018]

I have read it, thank you for clarification. Then it is probably fine unless some issue occurs in the future. For now we can just focus on new updates just like the today's one (:

[justinmclean]

The Apache Software Foundation policy doesn't allow a project to have GPL code or a GPL dependancy, so by changing this license to GPL would stop any ASF project from being able to use this code. For more details see:
https://www.apache.org/legal/resolved.html#category-x
https://www.apache.org/licenses/GPL-compatibility.html.

More permissive licenses like BSD and MIT are compatible with the Apache license.

[MrNaif2018]

Hello @justinmclean! Just wondering: is Apache Software Foundation considering the use of BitcartCC in one of its' projects, or did you find this issue by some automated tools?
In general about the licenses, this has always been the most painful, not fun and not understandable part about maintaining opensource project for me. Choice of license, claims that project was forked and so on.
Initially I created it with MIT license because it is the default one suggested and is pretty popular. For me (in my interpretation) license is a text that protects software authors from any issues with the software legally (:
It was suggested in this issue that GPL is better, we've discussed why, and decided to apply GPL license to main repository and LGPL license to our libraries. Other misc repos remained MIT.
At that time I asked around the people I know and they all said GPL is a great license.
Our users by the poll have also agreed:
https://t.me/bitcartcc/3012

Could you please clarify what's the main issue with GPL license? I mean you can re-use the software in any way possible, but from my understanding GPL license protects the original (this) software from a case when some company takes it's code, then sells this as a different project (with same code) without opensourcing it, which is bad for the project & OSS community.
I've also partially (the conversation is too long) seen the conversation about chardet, chardet-normaliser and GPL license with ASF issues. Many libs have migrated, mostly because of just the license? That is a bit weird to me.
Also on your site it tells that Apache license is compatible with the GPL v3 (not v2) which we use, so doesn't that allow using it? Also may this be just a misinterpretation of the license or something, considering that both Apache, MIT and GPL licenses have similar goals to be licenses for open source projects and to protect them? Because the reasons outlined here and in other places tell nothing wrong about GPL.

Also don't get me wrong, I just don't like licensing at all. I want is to be protected by that license and not limit the users in any way, and just focus on improving the project itself. Why can't I just say that? :D

[justinmclean]

There's no ASF projects that I'm aware of that use BitcartCC, but there's lot of projects and I'm not familiar with them all. I found this as it was linked to a similar issue that did involve an ASF project because of the chardet license issues. The main issue is that the GPL license in not compatible with the Apache license as it places more restrictions on the software than the Apache license does. The Apache license is compatible with the GPL3 license, so for instance this project would use Apache licensed code, but the reverse is not true, and an Apache licensed project can't use GPL(v3) licensed code. It looks like your community has agreed that the GPL license is best for them (and that's great), but just be aware that the license has more restrictions over a more permissive license like MIT or the Apache license. Depending on your point of view that may be a good thing, but it does mean that some projects won't be able to use your software.

[zander]

The main issue is that the GPL license in not compatible with the Apache license as it places more restrictions on the software than the Apache license does.

This is a fair observation, though the wording is a bit biased.

Is it really a "restriction" that the author and copyright holder grants themselves more protections against known attacks? I think you are on the wrong side of history here, arguing that others are not willing to give you stuff for free and THEY are somehow wrong.

You are, in actual fact, completly free to use this software and the millions of pieces of software out there released under the GPL range of software. You writing here is not shining a good light on you after you got the explanation how GPL is protecting authors better.

it does mean that some projects won't be able to use your software.

This is not true, everyone can choose to use Free/Libre Software, provided they are honest and follow the values of FOSS. So companies that have no intention of giving back are out of lock. This is about creating a lasting community, not about enrichiching leaches.

If this confuses you, please read the issue history as it expains the checks and balances many believe are needed in open source.

[justinmclean]

I'm not confused, its ASF policy to not allow a dependancy or code with the GPL license in one of it's projects. I should know as I have reviewed 100's of ASF releases and I'm a long time volunteer at the ASF including helping out with license issues. The GPL license is a great open source license, and if it works for this community that is also great. I certianlly don't want to cause offence or get into an argument on which open source license is "better". I'm just pointing out that some people or projects can't use software under a GPL license, as it's not compatible with some other open source licenses.

[zander]

I'm just pointing out that some people or projects companies can't use software under a GPL license, as it's not compatible with some other open source licenses.

Fixed that for you.

There are a lot more companies out there writing software today compared to 20 - 30 years ago. And this is great, and for them a BSD style license is wonderful. And it benefits the open source community as a whole.

It should, however, not be any surprise that volunteer projects doing open source may prefer a license that disqualifies those companies that demand a license like the Apache one from benefitting from the work of these volunteer developers in a way that hurts those volunteers.
Again, Apache licensed projects can in actual FACT use GPL software by simply honouring freedom software and ensuring that the code will always stay open. Their Apache-license released code can be relicensed into anything, including GPL.

So you are missing the point by digging in and saying that some people can't use it. They can, it is their choice. Probably not under your foundation, but that is not a discussion that belongs here.

[justinmclean]

I assume you're aware the ASF is 20 year old non profit charity for the public good run entirely by volunteers?

Is the Apache License compatible with the GPL license? Sure you can freely mix the code that's released under these two licenses. The resulting software, however, must be released under GPL license not the Apache one. So if an Apache license project wanted to use GPL licensed code it would need to relicense itself as GPL and would no linger be an Apache licensed project. A guess that's a choice of sorts.

Anyway you don't have to take my word for it, here's a good summary on the topic https://www.gnu.org/licenses/license-compatibility.en.html

[MrNaif2018]

Hi @justinmclean! Sorry for raising such an old issue, I just wanted your thought about some license. I am currently re-educating myself on the licensing topic (amazing book by Heather Meeker), and now I understand why the ASF for example disallows GPL licenses in the code, and I would probably do the same. Now I know how exactly GPL is limiting our users (:
I wanted to ask your opinion, what do you/or the ASF think about such novel licenses such as the Business Source License (or SSPL license, not sure) used in mongodb, or sentry for example:
https://github.com/getsentry/sentry/blob/master/LICENSE
To my mind it's a pretty good license which will protect the software from some other actors (like in their case AWS was providing hosted versions of sentry/elasticsearch/etc without almost any contribution to the project) using it for their own good, while it will allow the project owners to use profits from a hosted service to expand the opensource team, and after some time (2-3 years) the older releases get converted into some license, in this case apache 2.0, making it a fully opensource one
Or is it a bad license choice? I know it wasn't OSI-approved, though some weird licenses were approved by OSI in the past. I am seriously considering re-licensing in any case anyway

By the way, what's the main difference between MIT and Apache 2.0? Apache 2.0 includes more protection of patents rights?

[justinmclean]

What you choose a license is really going to depend on your community values or business model or objectives. In general, the ASF doesn't mind if people don't contribute back, and the Apache 2.0 license allows that. The ASF is a charity for a public good so you can see why that approach may work for them but it may not suit some other businesses. Licenses like the Business Source License are not compatible with the Apache 2.0 license so cannot be used in an Apache project. (See https://www.apache.org/legal/resolved.html#category-x.). As you say the OSI doesn't recognise the Business Source License as an open source license and IMO would be unlikely to approve it. One of the issues with a license like that is that 2 to 3 year old software may include multiple known security issues. Re MIT and Apache 2.0 they are both permissive licenses but yes Apache 2.0 includes more protection of patents rights is the main difference. TLDR = Use what license works for you.