PacketDotNet LGPL Compatibility with Single File Deployments about packetnet HOT 21 CLOSED

@enclave-alistair sounds good! @PhyxionNL you good with MPL here and SharpPcap (not sure if you've contributed there?)? If so I'll initiate emails to the largest contributors and start the process.

from packetnet.

For .NET Core 3.x this is a bit of a gray area as it unpacks all files to a temporary folder and runs it from there (in which you can replace the DLL). In .NET 5.0 this no longer happens so that would likely be a violation of the license.

I have made some comments to move this library to Apache 2.0: #103 (comment), but for now it seems as-is.

from packetnet.

Ok, thanks @PhyxionNL. So the thinking is that we're OK until we migrate to .NET 5? That was one of the things at the front of my mind, because as you say, all the assemblies are extracted in-memory in .NET 5.

from packetnet.

@enclave-alistair the intent is that PacketDotNet, and SharpPcap, can be used for commercial purposes and that commercial users are required by the license to distribute code improvements. This was born out of my own use of the libraries for commercial products.

Imo this seemed like a fair approach.

With .net 5.0 this doesn't appear to be compatible but I'd like to say that this is entirely a mistake on the part of the license, it was never intended to protect against swapping the library out for a new rev. That's a nice feature of the license but the intent is entirely to both let companies use the library and to encourage them to contribute their changes back. I never considered this issue as .net didn't have a way to do this single file approach until now (and I had no idea about it until you mentioned it above.)

@enclave-alistair is there a license that you are aware of that continues the spirit of commercial use and requires contributing back in the case of changes but otherwise allows for bundling into a single executable?

from packetnet.

@PhyxionNL apache could be an option. I do like to be a bit more firm with the idea that you get these thousands of hours of improvements back, we'd really like you to contribute your fixes and improvements back. Again, whatever we do has to go with the .net ecosystem. It would be dumb for example to have LGPL for a golang module because go almost entirely builds single executable applications (unless you intentionally flag otherwise). It's the same here, we've just been caught behind because I'm not keeping up on .net innovations. We need to resolve this in the near future.

from packetnet.

Yes, sharing back is certainly useful. That doesn't mean that projects with MIT/Apache have no contributions through. I think the preferred way is to keep stuff in the original package rather than maintaining thousands of forks. I think a license between Apache 2.0 and LGPL is MPL 2.0, but INAL and might be wrong about this:
https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licences
https://choosealicense.com/licenses/

from packetnet.

@enclave-alistair does MPL look suitable to you?

@PhyxionNL yeah MPL appears to relax that static linking requirement. You and I are likely the largest copyright holders and of course we'll need signoff from anyone we can get in touch with if we'd like to change the license. If we can agree on a change I'll kick off the signoff process at that time.

from packetnet.

Thanks for the quick reply @chmorgan; I can imagine that 10 years ago proper single-file deployment was barely a glint in the eye of the .NET team! So the LGPL makes total sense until we come up against this wall.

The MPL looks fine to me, but basically any license you choose that works for you in terms of encouraging contribution back, and allows us to distribute the PacketDotNet binary in it's unmodified (from NuGet) form in a single-file-deployment, with proper attribution to your project, will be just fine.

from packetnet.

Yeah, sounds good to me. I don't use SharpPcap and haven't contributed there.

from packetnet.

@chmorgan Can you start that? 👍

from packetnet.

from packetnet.

.NET Core 3.x just unpacked everything into a folder, which you could easily replace, but that doesn't happen in .NET 5 anymore. It's not just a simple replacement anymore and you need to make some considerable changes as they're baked into the executable. Even if you place a library inside the executing folder, it won't pick it up:

The probe ordering will be in the order (https://github.com/dotnet/designs/blob/main/accepted/2020/single-file/design.md#dependency-resolution):

Servicing location
The single-file bundle
App directory
Framework directory(s) from higher to lower
Shared store
Additional specified probing paths.`

--> The best way forward is to change to MPL. There should only be a limited number of contributors to ask for this.

from packetnet.

from packetnet.

Gotcha. Imo not easy isn’t the same as not possible. Can we fairly say it’s possible now, with difficulty, so we can unblock the earlier user asking for compatibility while we consider or work on relicensing?

Not unless you modify the application itself, which is a gray area and I do not think that would match with the license either.

from packetnet.

Alright. Let me send out the email to get things kicked off!

from packetnet.

@chmorgan I've not received an email yet, or did you skip me? 👍

from packetnet.

from packetnet.

Ah, alright, no need, how is progress? Most contributors here (https://github.com/chmorgan/packetnet/graphs/contributors) seem trivial changes only.

from packetnet.

Looks like everyone has approved. Let me put together a pull request for the change in license.

from packetnet.

Closing, is done now 👍

from packetnet.

Thanks all 👍

from packetnet.