search

jsakamoto / ipaddressrange

.NET Class Library for range of IP address, both IPv4 and IPv6.
Mozilla Public License 2.0
370 stars 71 forks source link

License question #3

Open nwhitaker opened 10 years ago

nwhitaker commented 10 years ago

Thank you for writing this and sharing it.

We are interested in using it in a commercial setting. However, the project doesn't seem to include a license. Can we use it? Are there any restrictions?

jsakamoto commented 9 years ago

However, the project doesn't seem to include a license.

OK, now, I add "LICENSE" file and it is LGLP v3.

You can use this library any purpose, and can use witout any credits.
Only if you modify code of this libray then that modified code must be public under LGPL or GPL.

If you using this library via PM> Install-Package IPAddressRange, you have to do nothing :)

Is it helpful for you?

Thanks.

yahorsi commented 9 years ago

Is it possible to change the license to something "not GPL"? Like Apache?

jsakamoto commented 9 years ago

The license is LGPL, not GPL.

Why do you prefer another license like Apache?

I would like to keep source codes are open, which is derived from this library to improve, fix bug, and so on.

But I have no interest about any other codes which using this library.

Then I chose LGPL instead of GPL license.

gregmac commented 9 years ago

I would actually prefer to see MIT or BSD license -- The useful difference being that the lib can be bundled/packaged with other software (closed source, or anything open including GPL software) in any relevant way. With LGPL, the distribution has to be done in a way that essentially allows an end-user to substitute in their own version of the library and have the original application use it (with LGPL, this doesn't mean source is necessary, but it means the binary must be able to read it).

The "danger" with these types of licenses is that someone can take the library and attempt to sell it -- but they still have to comply with the license (namely, including the license and mention of original copyright). If they've made no changes, why would anyone pay them? Especially with sites like Github, nuget.org, npmjs.com etc this really isn't effective anyway.

Even with LGPL, someone can still use the library in closed-source software provided they meet the conditions. In the case of this library, for example, someone could basically build a GUI on top of the library functions and charge people money for the result. The "hard work" is essentially entirely done by the library, but they make the money (well, if they can actually sell such a thing). If you are morally opposed to this hypothetical situation, the library should actually be licensed as something really copyleft, such as GPL or AGPL.

Frankly, I am looking at using this in a closed source commercial application (of which parsing and enumerating ipranges is not at all the primary concern). I am currently prototyping and haven't distributed any source, but as I move past prototyping, the fact this is LGPL will come up. If, for example, I wanted to ILMerge (or anything similar) my app into a single assembly to make it easier to deploy, I would not be able to do that and still comply with LGPL. I am not sure if it would also affect something like an auto-update (where a user-substituted library could be replaced with a new upstream one).

In all likelihood, if LGPL becomes an issue for me I'm not going to go to my company and say "hey, I think we should dramatically change our business model and open source all our stuff" -- I am going to rewrite the functions of the library that I need on my own and stop using the LGPL stuff. I don't actually plan on doing ILMerge or anything like that at this point, but I'm not 100% clear LGPL won't be an issue, either.

The way I see it, most people have interest in libraries like this being open-source and contributing (as I have done). By pushing my changes upstream, they will stay working as other new features are added, and this can be done while staying updated to new versions to take advantage of anything others have added/fixed. Plus most people are happy to give back in return for having a library that saves them a bunch of time.

Anyway if you have interest in actually changing to one of them, I am hereby permitting all my contributions to be re-licensed as MIT, BSD 2-clause, BSD 3-clause or Apache 2.0.

You'd also have to get permission from @M-Zuber (for #6). I'm not sure the other two PRs (#1, #4) are significant enough to actually have copyright claims (I would say they are not, but IANAL) and thus wouldn't need to grant permission.

M-Zuber commented 9 years ago

I'm happy to let my contributions be re-licensed as @jsakamoto sees fit

On Tue, Jun 30, 2015, 11:48 PM Greg MacLellan notifications@github.com wrote:

I would actually prefer to see MIT or BSD license -- The useful difference being that the lib can be bundled/packaged with other software (closed source, or anything open including GPL software) in any relevant way. With LGPL, the distribution has to be done in a way that essentially allows an end-user to substitute in their own version of the library and have the original application use it (with LGPL, this doesn't mean source is necessary, but it means the binary must be able to read it).

The "danger" with these types of licenses is that someone can take the library and attempt to sell it -- but they still have to comply with the license (namely, including the license and mention of original copyright). If they've made no changes, why would anyone pay them? Especially with sites like Github, nuget.org, npmjs.com etc this really isn't effective anyway.

Even with LGPL, someone can still use the library in closed-source software provided they meet the conditions. In the case of this library, for example, someone could basically build a GUI on top of the library functions and charge people money for the result. The "hard work" is essentially entirely done by the library, but they make the money (well, if they can actually sell such a thing). If you are morally opposed to this hypothetical situation, the library should actually be licensed as something really copyleft, such as GPL or AGPL.

Frankly, I am looking at using this in a closed source commercial application (of which parsing and enumerating ipranges is not at all the primary concern). I am currently prototyping and haven't distributed any source, but as I move past prototyping, the fact this is LGPL will come up. If, for example, I wanted to ILMerge (or anything similar) my app into a single assembly to make it easier to deploy, I would not be able to do that and still comply with LGPL. I am not sure if it would also affect something like an auto-update (where a user-substituted library could be replaced with a new upstream one).

In all likelihood, if LGPL becomes an issue for me I'm not going to go to my company and say "hey, I think we should dramatically change our business model and open source all our stuff" -- I am going to rewrite the functions of the library that I need on my own and stop using the LGPL stuff. I don't actually plan on doing ILMerge or anything like that at this point, but I'm not 100% clear LGPL won't be an issue, either.

The way I see it, most people have interest in libraries like this being open-source and contributing (as I have done). By pushing my changes upstream, they will stay working as other new features are added, and this can be done while staying updated to new versions to take advantage of anything others have added/fixed. Plus most people are happy to give back

in return for having a library that saves them a bunch of time.

Anyway if you have interest in actually changing to one of them, I am hereby permitting all my contributions to be re-licensed as MIT http://opensource.org/licenses/MIT, BSD 2-clause http://opensource.org/licenses/BSD-2-Clause, BSD 3-clause http://opensource.org/licenses/BSD-3-Clause or Apache 2.0 http://opensource.org/licenses/Apache-2.0.

You'd also have to get permission from @M-Zuber https://github.com/M-Zuber (for #6 https://github.com/jsakamoto/ipaddressrange/pull/6). I'm not sure the other two PRs (#1 https://github.com/jsakamoto/ipaddressrange/pull/1, #4 https://github.com/jsakamoto/ipaddressrange/pull/4) are significant enough to actually have copyright claims (I would say they are not, but IANAL) and thus wouldn't need to grant permission.

— Reply to this email directly or view it on GitHub https://github.com/jsakamoto/ipaddressrange/issues/3#issuecomment-117337830 .

jsakamoto commented 9 years ago

Thank you reponses for all. My English is no good, so it is hard to understanding what you want to say, then please let me few days.

It is my mistake that I don't care about contributors. I'll consider well about them in next chance.

I hope:

M-Zuber commented 9 years ago

You probably want MIT or Apache. Here are links with explanations: MIT APACHE

yahorsi commented 9 years ago

Guys just to confirm, legals afgaid even LGPL , e.g. I cannot use this lib because my legals refised it. MIT or Apache would be perfect

gregmac commented 9 years ago

I think that's the trade-off. LGPL enforces the source for derived works is always available.. but there are a whole bunch of people who won't touch it at all because it's LGPL (in other words, you're missing out on an audience and their potential contributions because of the copyleft license).

MIT/BSD allow people to create derived works without having to contribute the source back. Most people will contribute fixes back anyway, because it's in their interest (eg: as I said, I am working on proprietary software, may not even end up using this library anyway due to LGPL, but have already contributed improvements already).

With this library in particular, I'm not really sure where your fear is.. what other functions do you think people would build, but not contribute, that you'd want, that couldn't easily be done by you or anyone else anyways? I'm pretty sure I could build a VERY comprehensive "ip address/range/etc" library from scratch in a week.

If you really want to enforce any changes to the library are open, LGPL is probably the right choice. You'll just lose out in a different way, because people will skip the library entirely (and you won't get contributions anyway).

yahorsi commented 9 years ago

Any update, please? :)

yahorsi commented 9 years ago

Very friendly reminder

yahorsi commented 9 years ago

jsakamoto Could you pleaase comment?

jsakamoto commented 9 years ago

I'm sorry to late reply.
My private mission that is hard work was complete yesterday, so I'll be back soon.

jsakamoto commented 9 years ago

(... I'm translating comments/replies to Japanese ...)

jsakamoto commented 9 years ago

Hi everyone. Most important my concern is keeping this library and any changes are open.

@gregmac said, "people will skip the library", "stop using the LGPL stuff", "you're missing out on an audience and their potential contributions because of the copyleft license", etc...

What's so bad about LGPL? I feel sad. I could not figure out about why LGPL is worse only except using ILMerge scenario. It sounds like "LGPL is worse, because it is LGPL." for me. Is "LGPL is worse" common sense among programmers?

Of course, this library is very tiny, so anybody may can create the clone of this library from scratch in a few days. If someone does not agree the license of this library, they should recreate from scratch and apply any more closed license such as BSD, MIT, and so on.

By the way, the number of downloads of this library on nuget.org is 6,794 downloads. It is not a bad outcome for me. It looks not negligible acceptance for LGPL libraries.

But, I understand that LGPL is not perfect, and it has problem in some situations. I'm considering about relicense this library change from LGPL to MPL(Mozilla Public License).

@tom3m , if I relicense this library change from LGPL to MPL(Mozilla Public License), is it useful for you?

@gregmac , In my understanding, the Mozilla Public License allows you to using ILMerge or any static links without disclose another source codes.

nitinag commented 9 years ago

I think there is value in keeping the license simple and consistent with upstream projects such as .net itself.

For example, .NET Core is licensed under MIT (https://github.com/dotnet/corefx/blob/master/LICENSE) and ASP.NET under Apache (https://github.com/aspnet/Home/blob/master/LICENSE.txt).

More details at https://github.com/dotnet/core#license.

My vote would be licensing this under one of those. It sounds like that would also fix the problem some have mentioned with using this in their corporate environments.

yahorsi commented 9 years ago

@jsakamoto Thank you very much for not ignoring the issue. Apache is fine. I'll ask about MPL - will take few days to get answer from legals.

It sounds like "LGPL is worse, because it is LGPL." for me. Is "LGPL is worse" common sense among programmers? I have asked several times and did not get answer from legals. We're just not allowed to use any GPL/LGPL components and I have no way to change this. Looks like our company is not the only company who restricts GPL/LGPL.

yahorsi commented 9 years ago

UPDATE: MPL is fine! :)

jsakamoto commented 9 years ago

Hi everyone, I have overlooked the Section 4 of LGPL:

4. Combined Works. You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:

I guess, many people despise the Section 4 of LGPL in a case of using LGPL library, especially corporate using.

It is not what I want to do that enforce do not restrict reverse engineering. My concern is only keeping this library and it's changes are open.

So that, I should relicense this library from LGPL to another OSS license, which keep the source codes of OSS part to open, and allow link style both of static link and dynamic link.

I think, the OSS license which meet those requirements is Mozilla Public License.

@tom3m, Thank you for your reply, and it looks MPL is good for you. It is good news. Thanks.

@nitinag, Thank you for your friendly advice. But I could not compromise about allows to the changes of this library be closed. In my understanding, MIT and Apache license does not enforce open the changes of this library.

@gregmac, How about to change license of this library from LGPL to MPL?

@M-Zuber, @vkoppaka, @zanemayo, Could you please agree to change license of this library from LGPL to MPL?

M-Zuber commented 9 years ago

Permission granted

On Wed, Aug 12, 2015, 4:15 PM jsakamoto notifications@github.com wrote:

Hi everyone, I have overlooked the Section 4 of LGPL:

  1. Combined Works. You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:

I guess, many people despise the Section 4 of LGPL in a case of using LGPL library, especially corporate using.

It is not what I want to do that enforce do not restrict reverse engineering. My concern is only keeping this library and it's changes are open.

So that, I should relicense this library from LGPL to another OSS license, which keep the source codes of OSS part to open, and allow link style both of static link and dynamic link.

I think, the OSS license which meet those requirements is *Mozilla Public

License*.

@tom3m https://github.com/tom3m, Thank you for your reply, and it looks MPL is good for you. It is good news. Thanks.

@nitinag https://github.com/nitinag, Thank you for your friendly advice. But I could not compromise about allows to the changes of this library be closed. In my understanding, MIT and Apache license does not enforce open the changes of this library.

@gregmac https://github.com/gregmac, How about to change license of this library from LGPL to MPL?

@M-Zuber https://github.com/M-Zuber, @vkoppaka https://github.com/vkoppaka, @zanemayo https://github.com/zanemayo, Could you please agree to change license of this library from LGPL to MPL?

— Reply to this email directly or view it on GitHub https://github.com/jsakamoto/ipaddressrange/issues/3#issuecomment-130296954 .

jsakamoto commented 9 years ago

@M-Zuber, Thank you for your rapid replay, and I appreciate that you granted the permission. Thanks!

gregmac commented 9 years ago

@jsakamoto Also related to that is that effectively you must allow someone to be able to swap in a newer (eg their own) version of any LGPL libraries and have the software work. This is just not supportable by most organizations, and in the worst case, could allow someone to drastically modify how the original program operates.

Anyway, I am fine with MPL 2.0 (I didn't review 1.1), and all my contributions can be re-licensed as such.

jsakamoto commented 9 years ago

@gregmac Thank you for your reply. I understand about you accepted the changing license type from LGPL to MPL.

But, I'm sorry, my English skill is not good , so I could not understand what you want to say in 1st paragraph. I'm interested in "worst case" scenario. I appreciate if you tell me more details.

But it is not your responsive, so you do not have to reply to me.

Anyway, I'll promote the preparation of re-license.

yahorsi commented 9 years ago

@jsakamoto Hello! Any update on when you can change the license?

jsakamoto commented 9 years ago

@tom3m Thank you for waiting. I will do it soon, may be at this night (JST).

jsakamoto commented 9 years ago

I did it!

Thank you for all.

yahorsi commented 8 years ago

I know guys this may look stupid but could we: Or again change license to MIT 2.0 ? Or Perform "Black Duck wash" ?

I know this look stupid but legals has refused MPL ((( The problem with MPL according to legals is that: "The Mozilla wording allows for Contributors to use Contributions from others in their submission - that code may "infect" the Contribution (ipaddressrange) and result in the Confirmit Software becoming "freeware" despite anything to the contrary in the Mozilla Public License itself. We cannot take that risk."

yahorsi commented 8 years ago

UP

jsakamoto commented 8 years ago

Sorry to late.

It is hard for me to understand what the Legals said. In my understanding, MPL protect to keep open only under the licensed software, not using/linked software. (My understanding is not correct...?)

Anyway, I strongly hope to keep open contributions for this library, so that, I cannot accept MIT license.

njlittle commented 8 years ago

Am I the only one reading this thread who would prefer the library to remain LGPL?

As far as I know, there's no problem with using LGPL software in a commercial application.

gregmac commented 8 years ago

Yes, you are. LGPL is actually a fairly restrictive license -- not as much as GPL, but more than MIT/BSD/Apache/MPL and many others.

I already mentioned this above, but to re-iterate: LGPL library requires that it can be substituted out. The main effects this has:

As a very simple example, one of the apps I have that uses this library is a simple network scan tool, and I use ILBundle to provide it as a single exe so it's very portable and lightweight. If this library was LGPL it would mean I could no longer bundle it, and would have to instead build an MSI and lose portability. Frankly, it'd be less work to rewrite the library.

njlittle commented 8 years ago

I'm sorry but I think you're mistaken, firstly, in all your points you refer to your software but you need to understand that since you're using libraries from other sources, it's no longer just your software.

I'm not a lawyer but my interpretation of section 4 is that you can bundle or compress your software, you just have to give the user the option to bundle it himself which simply means providing the merged components separately along with the ones you expect him to actually use, i.e. the merged result.

On your point about obfuscation, as you say it's extra work for you as a distributor to ensure you don't obfuscate the LGPL component. It's a fair point, work involved to use a particular license is a factor. But, it is your choice to obfuscate and that's not really compatible with the free software ethos. Some might point out that security through obscurity is a fallacy.

I'll accept your point about digital signing, I haven't the knowledge to reply.

Your final point isn't really an argument, your software should work fine if I replace the functionality of this library with my own that is interface compatible. Even if it doesn't, you can place restrictions on what you support.

GPL and LGPL are Free software licenses, the others are merely Open Source, they have to be more restrictive to ensure the freedoms set out by the FSF are reflected in their terms. This does place more burden on you as a distributor but I think keeping the library free is more important.

JJ-M commented 3 years ago

My company also only want MIT/Apache/BSD 3 licensed OSS.

Anyone who has read this far may want to know that we used another github library "IPSec" that has similar functionality and is MIT licensed.

jsakamoto commented 3 years ago

@JJ-M I'm sorry, but I cannot accept the MIT license because I strongly hope to keep any contributions to this library is open.

For me, the Mozilla Public License ver.2.0 (MPL2) is the most balanced option between strict free software and more radical open-source software.

And also, please remember that If you can not accept the MPL2, you would easily reimplement the same feature of this library yourself.