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

Nexylan namespace move (used by slack-bundle) #95

Open
soullivaneuh opened this issue Jan 17, 2018 · 11 comments
Open

Nexylan namespace move (used by slack-bundle) #95

soullivaneuh opened this issue Jan 17, 2018 · 11 comments

Comments

@soullivaneuh
Copy link

FYI, we move a copy of this abandoned library under the Nexylan namespace: https://github.com/nexylan/slack

The 1.x branch is not touched, with same code and release so the migration will be smooth.

The unreleased change of this library plus other ones are under the v2.0.0.

The nexylan/slack-bundle now require this package and the v2.0 release support is in progress.

Ref: https://twitter.com/soullivaneuh/status/953671333279354880

@maknz I let you update the README to add the reference if you want to.

Regards.

@maknz
Copy link
Owner

maknz commented Jun 1, 2018

@soullivaneuh in your fork you've removed the original license. Please re-read LICENSE.md in this project to understand your obligations by reproducing. Thanks.

@soullivaneuh
Copy link
Author

Hi @maknz,

The LICENCE was changed on a new major version as it was done on other project like swiftmailer. The older one was untouched.

What is missing to permit us to use our license and complain with the old one?

Thanks.

@Gummibeer
Copy link

Gummibeer commented Jun 1, 2018

The problem is that the code you published under the new licenses was licenses under BSD which requires you to name from where your code is and keep up the license. So far I got your redistribution also should be BSD.
To change the license you need the permit of all code contributors. See jrgp/linfo#82 for example.

You can't copy licensed code, remove license file and think that the code is license free now.

So even if @maknz allows you to switch to MIT also all contributors have to allow it. Cause they contributed to this repo under BSD and not your MIT copy.

@maknz
Copy link
Owner

maknz commented Jun 4, 2018

Yeah, even though you've got a new major version, that doesn't excuse you from the license which governs the code you forked (even if it's modified). You'll need to change the license back to the one from this repo.

@soullivaneuh
Copy link
Author

@Gummibeer https://github.com/swiftmailer/swiftmailer/blob/5adaf8247f6fc219378fa2df1e6d9e4eee2d221d/CHANGES#L192-L195

As you can see, it's not the same appliance fore everyone. Here, this was changed without this kind of issue and the new major was especially for it. It's the model I did follow.

Still, I understand your PoV and no, I'm not a licence changing expert.

But what is the limit @Gummibeer? What about new php file for example, or even complete rewrite of the main logic of the code? If I don't want to release the changes under this licence, what are my options?

So I would like to open an issue on my repo to ask contributors about the licence change if I don't get a consensus, I'll revert the change OFC. But before that, @maknz would ou accept the MIT change? If no, I assume I don't have to loose time making an issue of this kind.

@Gummibeer
Copy link

The current license clearly says:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

So @maknz has to allow a license change at all. After this: every line of code has a Copyright owner (contributor) and a license under it was pushed.
To change the license for existing code you need the allowance of the package maintainer, in this case, and the contributors.
There is one limitation: you don't need the allowance of a contributor who just changed a typo or added a "no other way"/"this is the way how to do" feature. Code itself isn't protected if there is no unique idea behind it. This is a pretty not lawyer conclusion

And even after everyone allowed you to change it you have to link to this repo and that you've used it as the base.

@maknz
Copy link
Owner

maknz commented Jun 6, 2018

@soullivaneuh I'm personally not averse to MIT and I don't want to discourage people from improving on the original work. However, getting permission from contributors to change the license is probably in the too-hard basket.

Is there a particular reason you want MIT over BSD-2? According to Github's license helpers, there are only "minute differences" between MIT and BSD-2. The easiest solution here would be to re-instate the original license and copyright notice from this repository, and then add your own for your new work as maintainer.

Here is an example of someone who has forked and correctly maintained the license: https://github.com/php-slack/slack/blob/master/LICENSE.md

@soullivaneuh
Copy link
Author

Is there a particular reason you want MIT over BSD-2?

Nothing expect the ease of maintenance. I have a plan to make common file update and dispatch easier, including the licence file.

If you are not against, I'll open an issue on my project. There is not so many contributors, maybe I'll be able to have a quite quick return.

@soullivaneuh
Copy link
Author

@maknz Sorry for the delay, but the issue is here: nexylan/slack#41

Thanks for your patience.

@soullivaneuh
Copy link
Author

@maknz I still need your agreement. :-)

Also, the other not responding people seems to not be active anymore. What should I do about this?

@soullivaneuh
Copy link
Author

@maknz Since the new licence is accepted, would you consider README.md update?

Thanks!

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

No branches or pull requests

3 participants