Licensing difference of SELint vs other SELinux tools
Closed this issue · 18 comments
I just found out about SELint today, and this tool looks awesome!
However, I noticed something that's odd about this. It's licensed completely differently from the rest of the SELinux tools. Unlike every other SELinux tool (which are licensed GPL-2.0-or-later), this one is licensed Apache-2.0.
Is there a reason for this difference? This seems to be a weird break from the general convention for SELinux userspace software being under GNU licenses (LGPL for libraries, GPL for applications).
Actually, parts of SELinux are not GPL. For example, libselinux is public domain, and all the code in libsepol/src/cil is 2-clause BSD. But you are correct that most of the rest of SELinux is GPL based.
To the original question, we chose Apache v2.0 mainly because it is generally considered less restrictive than GPL (e.g. there's no requirement to provide source code changes upon distribution) and we didn't see any benefit in those additional restrictions that GPL puts in place. We'd rather this project be considered as "free" as possible, and we think ALv2 provides that.
We are aware that it is generally accepted that ALv2 and GPL-2 are incompatible, so if there is a desire to use code from selint in a GPL project but there are incompatibility concerns, we're happy to discuss it and find a solution. But so far that hasn't been an issue.
To the original question, we chose Apache v2.0 mainly because it is generally considered less restrictive than GPL (e.g. there's no requirement to provide source code changes upon distribution) and we didn't see any benefit in those additional restrictions that GPL puts in place. We'd rather this project be considered as "free" as possible, and we think ALv2 provides that.
I see. My thought process here would have been to align it along the community expectation or consider that you'd want people to make their improvements public so that they can always be incorporated back into the project to benefit all users of the tool. But I can see the perspective of licensing it this way if you thought it would help spread it further.
We are aware that it is generally accepted that ALv2 and GPL-2 are incompatible, so if there is a desire to use code from selint in a GPL project but there are incompatibility concerns, we're happy to discuss it and find a solution. But so far that hasn't been an issue.
I don't know if there's exactly a desire right now (mostly because the tool isn't known yet), but I definitely foresee it being one in the future. I know I could come up with a couple of use-cases where integrating SELint with the other tools would come in handy.
Would you consider relicensing it to something like LGPL-2.1-or-later?
While we prefer that changes are provided back to the project, we don't necessarily want to require it. The Apache Software Foundation has been pretty successful with this license, and I don't see it as limiting the projects succes.
I don't think we would consider relicensing, but we can certainly consider other options if there concerns. Perhaps we could dual license. I've also seen projects create addendums to the ALv2 that aim to mitigate the incompatibility (IANAL so I don't know of legitimate those are). Though, I'd rather not make those changes until there is an actual case so that we can ensure the solution actuall resolves the issue.
Also note that inorder to make such a change, we would need to get approval of all copyright holders. There are only a handful of copyright holders so it's doable, but requires extra work that is best to avoid until it's truely needed.
While we prefer that changes are provided back to the project, we don't necessarily want to require it. The Apache Software Foundation has been pretty successful with this license, and I don't see it as limiting the projects succes.
While it's true the ASF has been somewhat successful in this regard, it's only because most (if not all) ASF projects are of significant enough complexity that the license means a lot less. And even in that situation there are still folks who do not contribute back to the project.
I don't think we would consider relicensing, but we can certainly consider other options if there concerns. Perhaps we could dual license. I've also seen projects create addendums to the ALv2 that aim to mitigate the incompatibility (IANAL so I don't know of legitimate those are). Though, I'd rather not make those changes until there is an actual case so that we can ensure the solution actuall resolves the issue.
Also note that inorder to make such a change, we would need to get approval of all copyright holders. There are only a handful of copyright holders so it's doable, but requires extra work that is best to avoid until it's truely needed.
I don't have an actual need for this right now, but I brought it up now because the project is young and you can easily get in contact with all the copyright holders to adjust the licensing currently. Right now, we're (kinda) lucky in that the ecosystem does not know about SELint just yet, so it's not a huge issue. But given the need for integrating a tool like this into policy development and software development, I think that it's going to become a problem in the near future when people want to integrate it into GPL and LGPL software.
Myself, I would like to have it as an LGPL library to integrate into something like KDevelop IDE as plugin (which is GPL-licensed).
I just found out about SELint today, and this tool looks awesome!
Glad you like it!
Also note that inorder to make such a change, we would need to get approval of all copyright holders. There are only a handful of copyright holders so it's doable, but requires extra work that is best to avoid until it's truely needed.
We should bear in mind that much of the code in this project was produced as a "Work for Hire" for contributors respective employers, meaning that the list of copyright holders includes at least two companies (possibly more). IANAL, but I believe this means that relicensing isn't as simple as just getting an okay from the four individuals that have contributed. It would need to get approved by the legal departments of their employers, which is a much larger headache.
And even in that situation there are still folks who do not contribute back to the project.
IANAL, I'm not sure a copyleft license would help much in this case. My understanding is that source code is only required to be released to consumers of the binary under GPL style licenses. This means that a company that used SELint internally and made improvements would not be required to release them back to the community under GPL or Apache.
I would obviously like to receive contributions back, but in my personal opinion, encouraging use of the software is a greater goal. I think there is value in contributing back to a project you make changes to in terms of receiving free ongoing maintenance for those changes, and I hope that people continue to see that more going forward.
Myself, I would like to have it as an LGPL library to integrate into something like KDevelop IDE as plugin (which is GPL-licensed).
This would be really cool! I am very much not a software licensing expert. I'm wondering if there's any creative way to make this happen under the Apache license? Again, I am very much not a lawyer, and I know there has been extensive discussion on this topic that I'm not fully aware of the implications of, but I think that there may be options to create an LGPL wrapper library that interacts with Apache licensed SELint code, and is itself usable in KDevelop?
Do note, BTW that according to both The Apache Foundation and GNU This issue is specific to GPLv2. If KDevelop were GPLv3, I believe you would be allowed to use Apache licensed code in it. I could definitely be wrong, but as I read the GNU documentation around GPLv3, I think a similar problem would exist if SELint was GPLv3. (And, GNU does in fact specifically recommend the use of the Apache license for certain use cases (https://www.gnu.org/licenses/license-recommendations.html#software))
We should bear in mind that much of the code in this project was produced as a "Work for Hire" for contributors respective employers, meaning that the list of copyright holders includes at least two companies (possibly more). IANAL, but I believe this means that relicensing isn't as simple as just getting an okay from the four individuals that have contributed. It would need to get approved by the legal departments of their employers, which is a much larger headache.
I generally assume this to be the case these days anyway. That said, Tresys and Microsoft are semi-prolific contributors to software licensed under GNU licenses, so I assume they don't have problems with it.
IANAL, I'm not sure a copyleft license would help much in this case. My understanding is that source code is only required to be released to consumers of the binary under GPL style licenses. This means that a company that used SELint internally and made improvements would not be required to release them back to the community under GPL or Apache.
I'm obviously not a lawyer either, but that's my understanding as well. Most FOSS licenses trigger on distribution, not use.
Do note, BTW that according to both The Apache Foundation and GNU This issue is specific to GPLv2
It is definitely only GPLv2-specific. KDevelop is licensed under the GPLv2. While most KDE software is dual licensed (L)GPL v2/v3, this one seems to not be.
Again, I am very much not a lawyer, and I know there has been extensive discussion on this topic that I'm not fully aware of the implications of, but I think that there may be options to create an LGPL wrapper library that interacts with Apache licensed SELint code, and is itself usable in KDevelop?
This gets into sketchy territory, so I don't particularly want to go down that avenue if we don't have to.
And, GNU does in fact specifically recommend the use of the Apache license for certain use cases (https://www.gnu.org/licenses/license-recommendations.html#software)
I am aware of this recommendation, and I normally don't have much of a problem with the Apache Software License. My issue with it in this case is the inconsistency with the rest of the userspace tooling and the blockage in integrating it with various Free Software development environments under GNU licenses.
Note that if we relicensed to LGPL, due the the incompatibility we would have this same issue with any Apache licensed projects that want to use it. ASF explcitly disallows use of GPL/LGPL licensed code in their projects. So I don't think a relicense is a viable solution. Dual license might be an option.
One potential solution used by other ALv2 projects to deal with this incompatibility is to add an optional exception that attempts to resolve the issue. Some examples:
- https://github.com/apple/cups/blob/master/NOTICE#L37-L51
- https://llvm.org/LICENSE.txt
- https://github.com/michaelrsweet/mxml/blob/master/NOTICE#L6-L16
Note that I've had discussions with ASF legal and this exception must be made optional, as they consider it incompatible with ALv2, but they're fine with it if it's optional. According to the author of mxml, Apple lawyers have looked at and approved the CUPS NOTICE exception, so it doesn't seem totally unreasonable to adopt this as well. But it is then up to any projects like Kdevelop whether they are okay with this exception.
For reference, discussions I've had with MXML and ASF Legal:
I would honestly be surprised if any ASF project would do anything with SELinux stuff, since they live several layers above. 😛
In general, I'm fine with such an exception, and I'm pretty sure that's acceptable across the board. At least from my perspective, that should make it possible to integrate SELint with the existing ecosystem of tooling and prevent a gap forming between existing and new SELinux tools.
ASF does include the NetBeans IDE. It's certainly pluasible that someone could add SELinux policy development support to this, so being Apache licensed could help with that.
I can talk to my company to see if they would be okay with this exception if it seems reasonable to other copyright holders.
Does this exception seem reasonable to you?
ASF does include the NetBeans IDE. It's certainly pluasible that someone could add SELinux policy development support to this, so being Apache licensed could help with that.
Right, that did recently just happen. I still remember NetBeans IDE being licensed under the GPL. 😉
Though it does seem that the transition to Apache NetBeans also resulted in several features being dropped because of the license. 😢
My preference is to allow usage by the most use-cases possible, so adding such an exception would be fine from my personal perspective as long as everyone is comfortable that it's legally in the clear.
To be honest, I'm not even sure what the process for getting something like this cleared by Microsoft is. I can look into it, but don't expect anything resembling a quick turnaround. I assume that the portions of my contributions that are copyright Tresys would fall under Steve's discussion with them?
Definitely want to hear @cgzones thoughts. We would also need approval from @jbrindle or possibly his employer for commit efdd7d2.
Yeah, any decision made by Tresys (now Owl) would only apply to contributions made by @dburgener or me while working at Tresys.
Agreed about @cgzones and @jbrindle. I won't start any discussions with my Tresys/Owl until it's decided that this is a resaonble way forward.
This is nonsense. There is no reason to relicense this tool IMO. Apache license has nothing to do with ASF projects, there is no reasoning above that makes any sense to me.
The only reason some parts of the SELinux userspace are licensed as GPL is because Redhat pushed that early on. Anything new in the last decade has been BSD, APL, public domain, or similar.
The genreal consensus, not jut from ASF, is that the ALv2 license is not compatible with GPLv2. This issue has sort of evolved to figure out a way to adjust the license of selint so that it could be used with GPLv2 licensed software.
The proposed solution is to do something similar to what CUPS does, by addting a license exception to the NOTICE file:
[preamble: IANAL]
I am fine with adding a license exception, to allow SELint being used in a GPLv2 environment.
p.s.: does the ALv2-GPLv2 conflict apply to IDE's? Normally IDE's have plug-ins, wrapping 3rd party applications (like SELint) by calling them, and not by linking with them.
If the IDE is GPLv2 across the board, yes. Previously NetBeans was like this, KDevelop is mostly like this today, and others exist like this, too.
wrapping 3rd party applications (like SELint) by calling them, and not by linking with them.
Is this not a reasonable solution that would also be lower effort and more maintainable than reworking things into a library? I think it would involve all the legal questions around LGPL wrappers as well.
The whole reason for Apple pushing Clang/LLVM so much is precisely to avoid that kind of thing. Lots of developer experience tooling integration operates over program interfaces rather than human interfaces.