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

License is too restrictive #7

Closed
cao opened this issue Jan 9, 2015 · 13 comments
Closed

License is too restrictive #7

cao opened this issue Jan 9, 2015 · 13 comments

Comments

@cao
Copy link
Contributor

cao commented Jan 9, 2015

The current license, GPLv3, is too restrictive for widespread adoption.

A move to a less restrictive license, so that others can incorporate idalink more easily into proprietary software and then improve idalink naturally instead of being forced to GPL-license it or not use idalink at all might be a good idea. Under the current GPLv3 license, many of the companies that use IDA (which clearly is a requirement) might not be using idalink because they cannot easily distribute it as part of their own proprietary software. A too restrictive license can be cause for software not being adopted (carmaa/inception#105). We should preemptively improve on this situation.

I'd love to see idalink move to BSD (or MIT), or at least LGPL.

@zardus
Copy link
Owner

zardus commented Jan 9, 2015

LGPL probably makes sense. I'm hesitant to go less restrictive -- if they want to use it, they can contribute back. I'll look into relicensing; I'm guessing just a change of the LICENSE file and an explanatory commit message should do it.

In general, the idea that this thing is going to get widespread adoption under any circumstances is rather wild :-)

@cao
Copy link
Contributor Author

cao commented Jan 10, 2015

Wild ideas are awesome though!

My assumption is that it is going to get significant less attention under GPLv3 than it would under LGPL or BSD/MIT considering the problems that GPL (in particular v3) is bringing in terms of using it in proprietary software, company policies, licensing issues, lawyer fun, etc.

Regarding changing the license: confirmation from contributors (if their contribution is still part of the code) and then changing the license with an explicit commit should be enough.

@cao cao mentioned this issue Sep 15, 2016
@zachriggle
Copy link

+1 on changing the license to any of those mentioned (LGPL/BSD/MIT), the current license is preventing usage of Angr in commercial applications since Angr includes this code.

@zardus
Copy link
Owner

zardus commented Sep 15, 2016

I have no objection to BSD as long as:

  1. @zachriggle spells "Angr" in lowercase ("angr"), like it's supposed to be spelled!
  2. @cao, @rhelmot, and @adrianherrera, as the other idalink contributors agree. I take it that cao, as the guy that opened this issue, agrees.

I'd also point out that angr includes VEX, which is GPL and which we have no control over, and which is currently (although this may not always be the case) absolutely critical. Compared to VEX, idalink is a quite trivial component...

@cao
Copy link
Contributor Author

cao commented Sep 15, 2016

To put in writing: I do agree. I would prefer BSD, but have no objections to MIT or LGPL. Using the same license as angr would probably be the easiest.

@rhelmot
Copy link
Collaborator

rhelmot commented Sep 15, 2016

I'd agree to any of the licensed cao mentioned above.

We should really, like, get a lawyer and determine how the licenses actually interact and what restrictions actually apply for various use-cases?

@adrianherrera
Copy link
Contributor

I have no issue with any license change. If I had to choose I would choose
either BSD or MIT.

On Thu, 15 Sep 2016, 8:20 AM Andrew Dutcher notifications@github.com
wrote:

I'd agree to any of the licensed cao mentioned above.

We should really, like, get a lawyer and determine how the licenses
actually interact and what restrictions actually apply for various
use-cases?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#7 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIOhkqMMZKR6D9z9xInJKfGjbLBpnVWRks5qqOO9gaJpZM4DQQCY
.

@zardus zardus closed this as completed in 72ba4ab Sep 15, 2016
@zardus
Copy link
Owner

zardus commented Sep 15, 2016

Done!

@zachriggle
Copy link

@zardus In which of the various libraries, and in what form, are the dependencies on VEX -- and were they existing implementations?

@rhelmot
Copy link
Collaborator

rhelmot commented Sep 15, 2016

@zardus can you pull from gitlab and push to here, I just pushed something to change the license field in setup.py to 'BSD'

@zardus
Copy link
Owner

zardus commented Sep 15, 2016

@zachriggle, moving the VEX discussion to the pwntools issue.

@zachriggle
Copy link

👍

@zachriggle
Copy link

Also, I concede henceforth to always use angr instead of Angr ❤️

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

5 participants