kee-org
MS-PL not compatible with GPL
The package for keepassRPC was rejected from Debian because the file Jayrock/src/Jayrock.Json/Dynamic/DynamicMetaObject.cs is licensed under the MS-PL. Paragraph 3D of this license is not compatible with GPL.
(D) If you distribute any portion of the software in source code form, you may do so only under this license by including a complete copy of this license with your distribution. If you distribute any portion of the software in compiled or object code form, you may only do so under a license that complies with this license.
Do you think you could update/patch your sources to work without this file & license? Is it actually really required for KeepassRPC?
Freeze for new packages in the next stable release of Debian starts on 15/Apr. If you have a very quick fix, we could consider trying a new submission. Otherwise, we might would have to wait the next stable release, probably in approx. 2 years.
It builds with this patch but I don't know if this is appropriate and how (if) it alters keepassrpc. https://github.com/tenzap/keepassrpc/commit/af664a7ed96aed69d2a40b222ad7498524fe6f1b
Can I safely use this?
Jayrock/src/Jayrock.Json/Dynamic/DynamicMetaObject.cs is licensed under GPL. I don't know where "MS-PL" is coming from but suspect a mistake during the rejection process since the file mentions "Microsoft .NET". I know nothing about submitting things to Debian but if you can try a new submission that would be good - or use whatever process there is for pointing out mistakes in the approval/rejection process if that's easier/faster for the maintainers to deal with at such short notice.
As for the change suggested, I can't say what impact it will have - it's been almost a decade since I last worked with this code so I'd need longer than 2 days to re-assess how it works and confirm any impact. In theory, if it compiles and all functions are tested successfully it'll be fine, but I'm not confident taking that approach with a security-critical plugin like this.
I don't know where "MS-PL" is coming from but suspect a mistake during the rejection process since the file mentions "Microsoft .NET"
Actually the file clearly mentions the MS-PL license. I don't think this could be a mistake. Package was submitted for review about 5 months ago and we got the outcome today (a rejection for this reason).
https://github.com/kee-org/keepassrpc/blob/6fd3031fbc4d08a8155e9998f3721cd42916a640/Jayrock/src/Jayrock.Json/Dynamic/DynamicMetaObject.cs#L128-L141
In the original author's repo it is the same: https://github.com/atifaziz/Jayrock/blob/master/src/Jayrock.Json/Dynamic/DynamicMetaObject.cs
To have this package in the official Debian repo, the options I can imagine at the moment are:
- completely drop the file (this is what was suggested in the email that rejects the package) and update the code to work without it
- rewrite the file in a way that it isn't MS-PL licensed anymore.
As for the change suggested, I can't say what impact it will have - it's been almost a decade since I last worked with this code so I'd need longer than 2 days to re-assess how it works and confirm any impact. In theory, if it compiles and all functions are tested successfully it'll be fine, but I'm not confident taking that approach with a security-critical plugin like this.
Totally agreed.
And there is also this https://github.com/kee-org/keepassrpc/blob/6fd3031fbc4d08a8155e9998f3721cd42916a640/Jayrock/src/Jayrock.Json/Dynamic/DynamicMetaObject.cs#L156-L161
Ah, I see now that it is hidden in the middle of the file rather than at the top along with the main file license. So presumably the original author incorrectly claimed that the library is licensed under GPL, despite using code that could not be included under such a license? I've not got time to remind myself of the details of MS-PL but it sounds like this is what the Debian maintainers are saying and I have no reason to doubt that interpretation.
Unless Debian have already done this, we might have to search every file for other instances where this same mistake has occurred.
I will try to work out if we can safely make either of those changes in the next couple of days but I can't promise I'll be able to find the time. If it took 5 months for the initial review, how confident are we that this rushed effort will be able to result in an approval with only a day or less notice before this freeze point?
Unless Debian have already done this, we might have to search every file for other instances where this same mistake has occurred.
I already did that in https://salsa.debian.org/bastif/keepass2-plugin-keepassrpc/-/blob/master/debian/copyright?ref_type=heads
We usually have to check all files thoroughly to create the copyright file, and then only submit for review. But I missed that specific paragraph '3D' of ms-pl licence.
If it took 5 months for the initial review, how confident are we that this rushed effort will be able to result in an approval with only a day or less notice before this freeze point?
It is completely unpredictable. It can take less than one day or much more. Just see the new queue, and how long some packages have been waiting for. Usually resubmission goes faster since they mention what to address and probably have a trace of their initial review. But I admit I can't tell what the chances are.
I've taken a look at this and actually think that a resubmission is not even required.
The MS-PL code in question is included only if the NET_2_0 constant is not set. We always build with that constant set (so the library works in .NET 2.0 as well as newer versions), and therefore the compiled DLL and distributed PLGX never includes anything related to this source code (PLGX can't build linked projects so we build the Jayrock DLL when creating the PLGX file, unlike the source code of the main project which gets included in the PLGX file and built on the user's system by KeePass).
Granted, it would be clearer for a review process if this source code was not even present but I think this means we are not actually submitting any MS-PL licensed content and thus the original submission can be approved by Debian maintainers without any changes to the file in question.
I suspect there is not expert knowledge among Debian maintainers of how PLGX files are compiled and distributed so it's totally understandable that the subtle differences compared to a more typical "source only" or "object only" package would cause issues from time to time.
I'll still look into deleting the source code entirely since we never use it, and having it entirely absent from the source code repository would make the Debian maintainers' and other license reviewer's jobs easier in future. I'm not able to build it from where I am right now though and am not sure I'll get it done much before the freeze deadline so hopefully this additional information will be enough for them to just approve the existing package submission as is.
I already did that
Cool. Thanks :-)
Just to precise the wording: I prepared the Debian package and will maintain it although I'm not officially a DM (Debian Maintainer), so I don't have the rights to upload any package. For this, I have to ask a sponsor (ie. a Debian Developer) to do it for me. They check my work before upload. Once uploaded, and if a package is NEW in Debian it enters the NEW queue. This is where Debian's FTP-masters drop in to review thoroughly the package and check if it fit for Debian. In this case, FTP-masters rejected the package (ie. not the debian maintainer) with the reason I mentioned. After rejection, a re-submission is mandatory, and if it as is, the outcome would be same.
I'm not sure I understand your comment. As per the section 3-D:
(D) If you distribute any portion of the software in source code form, you may do so only under this license by including a complete copy of this license with your distribution. If you distribute any portion of the software in compiled or object code form, you may only do so under a license that complies with this license.
Doesn't this mean that if you distribute the binary (like you do in a PGLX, or like Debian would do as a .dll) it has to have a license compatible with MS-PL, which is not the case of GPL? Even though the compiler doesn't use the piece of code? Anyway... Since
The MS-PL code in question is included only if the NET_2_0 constant is not set. We always build with that constant set (so the library works in .NET 2.0 as well as newer versions)
then https://github.com/tenzap/keepassrpc/commit/af664a7ed96aed69d2a40b222ad7498524fe6f1b is valid. The code commented out in that commit is wrapped around #if !NET_1_0 && !NET_1_1 && !NET_2_0, like the one of the MS-PL file.
Granted, it would be clearer for a review process if this source code was not even present but I think this means we are not actually submitting any MS-PL licensed content and thus the original submission can be approved by Debian maintainers without any changes to the file in question.
If I leave the file in the package, FTP-masters would certainly reject it anyway as they did this time. So I'll drop it, and patch the code to work without it since that wouldn't change the resulting binary on .Net >= 2, which is the case on Debian. Then I can ask my sponsor for a new submission.
Just for information, I had to perform some rearrangement of the code you ship. Typically:
- add the source code of your two other repos (because all binaries shipped by Debian must be built from sources only)
- delete some files that don't have a DFSG-compatible license
- delete all binaries (they are forbidden in the source package).
If I leave the file in the package, FTP-masters would certainly reject it anyway as they did this time. So I'll drop it, and patch the code to work without it since that wouldn't change the resulting binary on .Net >= 2, which is the case on Debian. Then I can ask my sponsor for a new submission.
Sounds good. I think this is the best chance of getting it sorted before the deadline. Afterwards, we can look at incorporating the change into this main repo (along with any other feasible adjustments to make your Debian-specific adjustments easier in future).
Doesn't this mean that if you distribute the binary (like you do in a PGLX, or like Debian would do as a .dll) it has to have a license compatible with MS-PL, which is not the case of GPL? Even though the compiler doesn't use the piece of code?
As far as I'm concerned, we never "distribute" this - the source code is present in the project but the compiler never compiles it and thus it never makes it into a binary and is thus never distributed within the PLGX file (the conditional compilation excludes it from the binary entirely rather than just checking for ".NET 2" at runtime). I'm not familiar enough with Debian package distribution system to know whether what they require you to do for submission would lead to distribution of the source code from MS-PL perspective, but I expect that getting clarity on that sort of legal detail is going to be unlikely by tomorrow! In any case, since we can eventually just remove the code from our project entirely, the answer would become academic if your patching approach succeeds.
Thanks for the details about the process that you provided earlier. I'll keep my fingers crossed that the patch deleting the code in question can get approved in time.
I think that given that the file and project is on a public repo it is considered as distributing the source code. I would say Debian distributes the source and the binaries related to those sources, since they can be downloaded from the Debian Archive by anyone.
Eventually it was too late to enter Debian trixie (due in a few months). But it will automatically be part of the next release of Ubuntu Questing which is due in 2025-10.