[CMakeLists.txt] Add source_groups; [README.md] cmake --build .

[SamuelMarks]

PS: Have you considered alternative license choices? Like (Apache-2.0 OR MIT)?

[paullouisageneau]

I'd like to keep the old-fashioned non-abstracted calls to build systems in the Readme (I think it shows better how cmake works to people not familiar with it), apart if there is a good reason to change.

[SamuelMarks]

I think in addition to it being more generic it can be overridden with CMAKE_MAKE_PROGRAM whereas the usual approach would require overriding the environment (with export or env).

[paullouisageneau]

Thank you for the addition to CMakeLists.txt!

PS: Have you considered alternative license choices? Like (Apache-2.0 OR MIT)?

Well, this is mostly a matter of political opinion. I believe you can't rely and goodwill alone to keep up the spirit of free software, as numerous companies basically pillage permissively-licensed code without contributing much in exchange. Therefore, I prefer a copyleft license, and LGPLv2 libraries can still be linked against software under basically any license.

[SamuelMarks]

My main reason for going open-source non-copyleft is to make it more accessible. I don't want anyone to have an excuse NOT to use my technology. Whether or not they contribute back is less of an issue. Famously Google, Microsoft, & others won't accept code under copyleft licenses; meaning engineers from those company's can't contribute back—without explicit approval from their hierarchy—even outside work hours. Also I'm hacking together multiple hierarchies of technologies, with modularity in mind, so I want others to be able to pick-and-choose just the parts they want. If there's a copyleft license then they might avoid the codebase entirely.

BTW: The specific (Apache-2.0 OR MIT) license I stole from the Rust project, as it allows for linking against the GPLv2 and GPLv3 family of licenses; in addition to every other stack (shared or static lib).

[paullouisageneau]

I understand your position, however I care about respecting users' freedoms and giving back to the free software community, not about pleasing big companies like Google or Microsoft (which ironically both use and contribute to Linux under GPL), so I'm not changing the license.

[Overcow]

Would you consider a static linking exception, such as the wxWidgets license?

[paullouisageneau]

@Overcow The wxWidgets license removes obligations for users distributing proprietary binaries, which to me defeats the purpose of free software. Besides, you may static link proprietary software against an LGPL dependency, you only need to provide a way for the user to relink it. See the GPL FAQ for more information.

[SamuelMarks]

I understand your position, however I care about respecting users' freedoms and giving back to the free software community, not about pleasing big companies like Google or Microsoft (which ironically both use and contribute to Linux under GPL), so I'm not changing the license.

My main argument for promoting these more permissive licenses is to encourage use; everywhere. In the history of BSD there was some large component—was it the TCP/IP stack?—that Microsoft took without acknowledgement. Rather than employ lawyers to fight this, the BSD folk explicitly allowed for it. There's something to be said for ensuring every actor on the network has a fully compatible networking stack.

Everything I build for my company, charity, and research is open-source under (Apache-2.0 OR MIT). Sometimes I have a client that won't [immediately be] open-source. In these circumstances I can reuse what I've been maintaining; sometimes years worth of ecosystem. Then, when I finally convince them to open-source what was created, it can be helpful to the wider community (including proprietary vendors).

Keeping libjuice under a less permissive "viral" license discourages—corporate and many smaller & individual—users/contributors. IMHO, libjuice, like UDP itself, should allow any vendor to work with it.

PS: This will also encourage folk to port to other platforms.

Anyway, hope these arguments make you reconsider, regardless nice work with libjuice =)

[paullouisageneau]

@SamuelMarks You seem to conflate protocols and protocol implementations.

If someone has a problem with the obligations of the LGPL license and wants to negotiate a custom proprietary license for libjuice, I'll be happy to consider it. Otherwise, libjuice stays under LGPL.

[paullouisageneau]

Merged a29b96d

[SamuelMarks]

Great (also weird it's not purple but red, was this merged?)

But then here: