fswatch
fswatch copied to clipboard
emcrisostomo
dual license?
Any chance to dual license the code base as MIT/BSD/Apache? Given it's all getting statically linked I don't see how I could use the lib with a MIT/BSD/Apache based code base.
Hi @tcurdt, I'm definitely thinking about dual licensing using GPL3 and the 3-clause BSD license. Let me figure it out.
Any chance this could be made LGPL or something less restrictive for commercial use? I'd like to use this in a commercial application and our source cannot be released publicly. If fswatch was LGPL, dynamically linking to an unmodified version of fswatch would be ideal.
GPL3+BSD would be OK. LGPL (and dynamic linking) does not sound very applicable to the standard go project use case. FWIW - the Apache License (not sure about BSD/MIT) is compatible with the GPL. Just not the other way around. So that might be an easy choice as well.
https://www.apache.org/licenses/GPL-compatibility.html
Are you saying GPL3+BSD would work for commercial product that just dynamically links to fswatch?
@aaronovz1 Why do you insist on the dynamic linking? Especially on a go project?
Disclaimer: IANAL - but...
When you choose to go down the BSD route it also allows even static linking in a commercial context. Of course you would need to follow the BSD rules:
https://opensource.org/licenses/BSD-3-Clause
@jakirkham not more than go projects often go down the static linking route. (no pun intended)
Just trying to get an idea of whether there’s a use case for it. Sounds like no?
Hi,
I'm a little confused since licensing and legal is really not my domain. When I started the project I used GPL3 (as suggested by GNU, even for libraries), and that's in line with the spirit with which I've written fswatch and libfswatch.
Now, I really have no issues in re-licensing it with a license that's in line with my principles, and LGPL seems to meet that criteria. Even BSD 3-clause does.
Now I'm not sure about the execution: are there incompatibilities between these licenses? Can I just updated the licensing statement and that's it? I'll have to have a look into it.
@emcrisostomo IANAL but....
GPL + LGPL works for in world with dynamic linking. In a go world where I create a single static binary even the LGPL is a blocker - because the user cannot replace the library him/herself. That's why even the LGPL is (by many) considered incompatible in that scenario.
If you are the rights holder and other contributors did not contribute more than little patches you can just change the license or add a second one as you wish. If there are other bigger contributions it's a little more complicated. In theory you'd need to get consent for their contributions.
Unless you add or change to a BSD/ASL/MIT style license no other project but GPL/LGPL projects will want to use your library. You need to figure out whether that's what you want. For my libraries I am usually fine with just a credit.
MPL-2.0 https://en.wikipedia.org/wiki/Mozilla_Public_License provides similar benefits to GPL in terms of encouraging contribution, protecting from patent trolling and "tivoization" but allows both static and dynamic linking like BSD/MIT and is compatible with all the most popular licenses.
by 
I suggest that you can change libfswatch's license to dual license (Apache License2 and GPL3)
Hey, I'm working on a better version of rmate called "CodeFS" https://github.com/MisterTea/CodeFS
I would like CodeFS to be BSD/Apache licensed, but I can't do that because it depends on fswatch. I'm going to have to replace fswatch if we can't change the license :-(.
Please let me know if you plan on having a dual license, thanks!
You don't need to explicitly do anything regarding a dual-license. One would usually do development of their portable library / component under a single "simple" license with few terms such as MIT or ISC, where the license terms are either a subset of, or non-conflicting with the license terms used by other projects / components that utilize it as part of a system.
The "n-license" effect happens as a consequence of your code being effectively re-licensed by downstream consumers of the library which have copyleft components that require linked code or derivative works to be released under same license. The interoperability of upstrem work is unaffected by incompatibilities introduced by downstream licensing requirements, so it can continue being utillzed by any project regardless of the license requirements of its components.
When conflicts occur, downstream developers cannot use your code as is. They must choose to either a) use a different library, b) (re)develop new code under a compatible license, or c) replace and/or relicense all of their project's legally incompatible existing code to comply with both your license requirements and those of all other 3rd party code.
For large projects, option c is usually infeasible, and potentially harmful as new license requirements impact the ability for further downstream software to use the project. So the choice is usually a or b. Importantly, choice of a or b will often be proprietary, have an incompatible API / implementation, incompatible license, or all of the above, with predictable consequenceses.
It's been almost two years now. It seems like a) or b) are the only options fow now. So if someone finds an alternative project - please leave a link!
This would also be relevant for me to be able to use libfswatch in a MIT-licensed lib (statically linked)
consider using facebook/watchman which is Apache licensed and is also cross-platform with multiple backends, kqueue on OSX/MacOS and *BSD, inotify on Linux, Solaris, Microsoft Windows and a stat()-based backend.
C++ client library usage example
@tcurdt @extrawurst
I'm dual-licensing all this repository (including fswatch and libfswatch) using GPL v. 3.0 and the Apache License v. 2.0. I'm mentioning it in the README.md, and I'll be updating all the relevant files shortly. As far as I'm concerned, the dual license is effective as of now.
Great to hear, also you might want to use a SPDY expression like: (GPLv3 OR Apache-2.0)
