sipsorcery
sipsorcery copied to clipboard
sipsorcery-org
Removal of AGPL code
Some of the files reference AGPL 3 code, this pull request attempts to remove and rewrite them under an MIT license.
Thanks for this! BTW did you upgrade the target dotnet version? (is this why the AppVeyor builds fail?). The AGPL dependency basically caught me by surprise. I never thought there would be AGPL'd code here. @sipsorcery, thanks for maintaining this quite big project; what's your view on this PR?
@Terricide: Are these contributions/changes in the PR commits under the MIT license? I would love to merge it to my own private repository and see how it works. Thank you very much.
Yes it is licensed under the MIT license. That's why I rewrote it was to make sipsocery not have the AGPL code.
Yes it is licensed under the MIT license. That's why I rewrote it was to make sipsocery not have the AGPL code.
Thank you very much for this, it merged well on the existing modifications (I only do .net 9).
@Terricide I also noticed, that some of the affected files actually link to source that is explicitly non-AGPL. I checked, and the only 2 files that are actually AGPL are DtlsSrtpServer and SrtpParameters
@sipsorcery this seems to be a major issue, which also affects all the previous versions of SIPSorcery
@sipsorcery this seems to be a major issue, which also affects all the previous versions of SIPSorcery
Do you mean for applications that want to use the library? Yes, if the AGPL terms don't suit your app it's potentially a major blocker.
As you yourself point about above this PR could not be considered a different enough implementation to remove the AGPL clause so doesn't fix hat particular problem.
It is a bit deceptive to provide a software package with a declared 3-Clause BSD license when said package also includes files with AGPLv3 license. The license text of AGPLv3 states:
`You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified it, and giving a relevant date.
b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to "keep intact all notices".
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.`
The 3-Clause BSD license terms allows distribution with GPL-like licenses, but the AGPL license requires that the entire work is distributed with an AGPL license.
So there is really only three ways to go from here.
- Either the AGPL licensed files need to be removed from the package
- or the entire package should be distributed with a declared AGPL license.
- or a permission is given by the copyright holders of the ported AGPL java sources to distribute the C# files with a BSD license.
Would some users miss those AGPL licensed files if removed? Yes, probably. Would some users stop using the software if the license changes from BSD3 to AGPLv3? Yes, probably. Will the original copyright holders of the java files be happy to see their ported work be distributed with a BSD license? No, probably not.
At the end of the day, the choice is up to the maintainer(s) of this software. If enough users get upset by the choice a fork of the project might occur.
A note for people who need compliance. My startup has a prototype that ditches the AGPL code and brings our own implementation of affected areas, but is it not production ready. We are too small to care about minor violations like this, but if another company needs compliance, we could add comprehensive tests and upstream it for a few $k
It is a bit deceptive to provide a software package with a declared 3-Clause BSD license when said package also includes files with AGPLv3 license.
That's a fair call. It was never intended to be deceptive. A contribution was added to the project in 2020 with a large number of files and I initially didn't notice some were derived works with a different license. At some point I did spot it and updated the file headers and the license blurb on the overall project to include the Apache license. I can't recall exactly what happened as to why I didn't specify AGPL but looking at the 7 files in question again now (all related to SRTP) I see they are from two java projects jitsi-srtp and media-core. i think it was me that added the original derived source links after doing a web search for prominent strings in the code.
The interesting thing about that is jitsi is apache licensed, which can work with BSD, whereas media-core is AGPL, however I suspect media-core may have originally used the jitsi source. In theory that would mean the AGPL licensed files could be attributed to the earilier jitsi apache ones.
I'll dig into this more when I get some time. In the meantime I've added an AGPL caveat to the license blurb for the project.
It is possible to take sources with a BSD license and distribute them in a project with another license (like AGPL) as long as you also fulfill re requirements of the BSD license (which basically only requires you to mention the original authors). However, it is not possible to take AGPL sources and apply a BSD license unless approved by the copyright holders.
Depending upon the amount of added work done by media-core, it might be possible to claim that your port to C# was done as a clean room implementation considering the AGPL sources and only built upon the original jitsi files with Apache license.
For now, it is good that the declared license warns about possible AGPL issues. Thanks for the quick response!
@henca in case you're still interested I did dig further into the origins of the Java DTLS/SRTP classes that were added to this library. The origins appear to have been:
- The minisip project with an LGPL license.
- The Jitsi project(s) derived portions from Minisip and use an Apache V2 license.
- The RestCom Media-Core project derived from Jitsi and used an AGPL 3.0 license.
So all in all a bit of a tangle but safe to say the derived code is GPL encumbered in some for or another and I've updated teh license file again to make it clearer.
A solution would be to port a non-GPL SRTP library such as Cisco's libsrtp or attempt a clean-room implementation (probably less than 5k lines of code). Neither of those tasks are on my own roadmap at the moment.
Good with a clarification! I must admit that I am not familiar with the build systems of C# projects, but there are other projects out there like ffmpeg which provide options (--enable-gpl) to their configure scripts to let the user choose which part to compile to affect the resulting licensing terms.
The AGPL license might by some people be considered "worse" than the GPL license.
Basically, the GPL and LGPL license require that any "user" installing a software like this on should also be told about the licensing terms and have the right to get access to the source code (LGPL only the source code of the LGPL-licensed part, GPL the entire source code that was linked to the GPL sources). Those "users" are then free to modify the sources and link and run the software with their modified libraries instead.
The AGPL license extends the term "user" to not only the people installing the software on their servers, but also anyone who later connects to the software on those servers.
I have not considered the practicalities of this, but I wonder if @sipsorcery would be comfortable with the idea of splitting the library into 2 in the short term. Maybe a SipSorcery.Aglp nuget package until a contributor has time to look into writing a new implementation of SRTP. Appreciate this might break binary compatibility for some users, but it would be a good way to clarify the license and for everybody. I'm not sure I have the time, but you're comfortable with the idea Aaron, I could try to look into it
I did toy with the idea of splitting the library up along functional lines #1271. That would potentially help in this case. The SIP/VoIP part of the library does not require DTLS/SRTP so it would be free of GPL encumberances. For a WebRTC library it can't work without DTLS/SRTP so it would be encumbered.
@sipsorcery
In fact, to this day, the lib is built as building block that allow to use SRTP with the RTPSession to send encrypted media in SIP sessions. As a result, the SIP/VoIP part can sometime (based on configurations) require SRTP.
That being said, given a new structure of projects, I agree that the SIP/VoIP part would preferably not be coupled directly to the DTLS/SRTP part whereas it should be a consumer decision to combine (or not) those two blocks together.
