Community edition package (RainLoop goes Open Source)

[RainLoop]

As you know RainLoop uses a CC license.
It is not an open source license and many users don't like it.

I have decided to split the project into two parts:

• Standard package (Current package/CC)

and

• Community package (Open Source license/ Apache2, MIT, GPL 3 - I have not decided yet)

What is removed in Community version?

• RainLoop update in one click (and version checking)
• Plugins installation in one click.

Since this package will be used in completely different packages,
the possibility of updating must be turned off (removed).
In addition, it will reduce traffic to the repository.

I understand that it's cool features, but they do not fit into the concept of community package (IMHO).

What do you think about this?
Which license would like to choose?

[RainLoop]

reference: #8

[ervee]

Hi,

As far as my knowledge on licensing goes, I agree with moving away from the CC license. But I'm no expert and I think there are other people who can assist in choosing a license type.

Now, first of all, this is your project so you should do what you want to do. I am just really grateful for this piece of software!

If you want my opinion...

• I don't really understand the split. Why not keep it simple and just switch the license and have people buy a license for support/branding/commercial use? I'm no expert, but I think this should be possible.
• If you do the split. I would really dislike the removal of the update mechanism. You could easily keep this and source the update files from the correct repo. I'm sure you can ;-) Remove the branding option, remove the easy plug-in install, but not the update mechanism. This is one of the main reasons I use RainLoop.

Whatever you decide is up to you though. It's your project.

Ralf

[RainLoop]

I don't really understand the split. Why not keep it simple and just switch the license
and have people buy a license for support/branding/commercial use?

I don't think that it is possible.
OS licenses cann't forbid branding or commercial use.

but not the update mechanism. This is one of the main reasons I use RainLoop.

I understand that it is a cool feature. But, community package will be integrated into
other packages and it is not good to allow update functionality in this case. For example: ownCloud package: you may update RainLoop inside ownCloud package, but it is not correct way. You should update the whole package at once, not just a part (RainLoop).

[heubergen]

Good Idea and also a good proposal for the splitting.

[pietroalbini]

I know I'm a bit late on this, but this month was really busy for me (I'll update the translation when I'll have some free time).

I'm not a lawyer, but I think this license change isn't really valid from a legal point of view. The fact is, you've the right to change the license of your own code (obviusly), but you can't change the license on others' code or translations, because they have the copyright on it, not you.

Don't get me wrong, I've no problem for a switch to the AGPL license (over the italian translation I made), but someone else might be aganist this change (especially about the commercial license). And anyway, if someone makes a patch to the AGPL code, you've no rights to change the license of that patch.

What you should have done (and I think you should do this anyway) was to ask to each contributor the authorization to switch the license, and if someone refuses to do so, remove or rewrite in a different way his contributions, like what bootstrap did for the Apache -> MIT switch
And also, you should do that everytime you move something from the community version to the standard one.

I highly recommend you to setup a contributors license agreement, to avoid troubles in the future.

[RainLoop]

Interesting, thanks!

I think I should do something like that:
RoundCube Request for Agreement (https://roundcube.net/license/)

[pietroalbini]

Yeah, a thing like that. You should ask each one who makes contributions to the project to give you the right to re-license their work, else you can't release the standard version (which has a different license).

For the important Ubuntu-related projects Canonical runs, they require contributors to sign the Harmony CLA, which I recommend you because it keeps the copyright ownership to the original contributors, but gives you the right to use the contributions as you want, including relicensing it. But I'm not the one who makes the final decisions there :)

I also think (remember I'm not a lawyer) you must anyway contact all the ones who contributed to the project in the past, and ask them if they're ok with the double-license change. Maybe requireing them to sign the CLA, so you won't have problems in the future. If they don't accept that, or they don't reply, unfortunately you must remove or rewrite the things they added.

It would be a nice thing to set up a contributing.md, in which you explain the CLA and the double-licensing thing, so you can link it to new contributors, and they can find there all the things they need to know.

You can see the migration of bootstrap on twbs/bootstrap#2054.

[pietroalbini]

Also, maybe you can re-open this issue so you can get input from others too :)

[pietroalbini]

Soo, no one is replying... What you should start to do, is preparing the CLA, and then send an email to all contributors requiring them to sign to the CLA for their previus commits.

You can easily get the list of all the email addresses with:

git log --format="%ae" | sort | uniq