SEL-only files being in git means distributing or modifying the official git repository is not allowed

[programmerjake]

I suggest changing the SEL to be like GitLab's enterprise-edition license (which explicitly permits modifications and distribution for development and testing), moving all SEL-only code into a separate top-level directory, making sure the code still works if that directory is missing completely, and also providing a separate repo with only the open-source parts.

[williamdes]

See #601

[programmerjake]

yes, but being a cargo feature doesn't change the restrictions on distributing source code

[williamdes]

Yes, but in some way it will help pruning out the code I think. Not entirely sure.

[programmerjake]

one big way that the current state causes problems is that the standard process of forking, pushing commits to your fork (even if only changing the open-source parts), and submitting a PR violates the license afaict (disclaimer: I'm not a lawyer), since the license doesn't permit distributing the non-open-source parts.

[programmerjake]

another major consideration is what happens if e.g. debian or arch wants to distribute a packaged version, they distribute the source code and prefer to not have to manually remove/replace all proprietary files (e.g. currently they'd have to replace the se-licensing and se-common crates with open-source stub code to make cargo happy), if they can just git clone a working repo with only the open-source parts, I'd assume that's what they'd prefer.

[williamdes]

This is exactly what did happen haha, I did the Debian packaging for my company. And saw the code. For now I just ignored the problem and wrote an issue.
But as a Debian maintainer (I am one) I would prefer not to have to patch the code, as maintaining and rebasing patches is very time consuming

[mdecimus]

Thanks, an exception was added to the license to allow copying for testing/development purposes.