jsakamoto
License question
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?
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.
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.
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.
I'm happy to let my contributions be re-licensed as @jsakamoto sees fit
On Tue, Jun 30, 2015, 11:48 PM Greg MacLellan [email protected] 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 .
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:
- I don't want to enforce disclosing souce codes that only links this library.
- I want to enforce disclosing source codes of this library and related changes (fixing, enhancing, etc.).
- I don't want to enforce showing credit.
- I don't mind anybody get money using by this library.
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
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).
I'm sorry to late reply.
My private mission that is hard work was complete yesterday, so I'll be back soon.
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.
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.
@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.
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?
Permission granted
On Wed, Aug 12, 2015, 4:15 PM jsakamoto [email protected] wrote:
Hi everyone, I have overlooked the Section 4 of LGPL:
- 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 .
@M-Zuber, Thank you for your rapid replay, and I appreciate that you granted the permission. Thanks!
@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.
@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.
@tom3m Thank you for waiting. I will do it soon, may be at this night (JST).
I did it!
- https://github.com/jsakamoto/ipaddressrange/commit/b62fff63b63e99373910dfe22e3d4e450d2c3720
- https://www.nuget.org/packages/IPAddressRange/
Thank you for all.
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."
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.
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.
