GPL-2: GPL-3, MPL-1.1should be:
LGPL-3: MPL-1.1should be:
hello Debian legal folks,
I'm looking for an up-to-date compatibility matrix of /usr/share/common-licenses[...]
(modulo documentation licenses).
I've prepared the following, where the license before the colon may
be combined
with any common license *except* the ones listed right of the colon.
do you see any mistakes? have I missed anything?
Apache-2.0:
Artistic:
BSD:
GPL-2: GPL-3, MPL-1.1
GPL-2+: MPL-1.1
GPL-3: GPL-2, MPL-1.1
LGPL-2: MPL-1.1
LGPL-2.1: MPL-1.1
LGPL-3: MPL-1.1
MPL-1.1: GPL-2, GPL-2+, GPL-3, LGPL-2+, LGPL-2.1, LGPL-3
MPL-2.0:
OpenSSL: (GPL licenses ommitted here due to https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException)
thanks,
Serafeim
On Sun, 30 Jun 2024 22:37:22 +0200 Serafeim Zanikolas wrote:[..]
If I understand correctly, we are talking about linking-compatibility
here.
I think some incompatibilities are missing.
At least the following ones:
Apache-2.0: GPL-2
[*] Please note that the compatibility status of MPL-2.0 is more
complicated than a simple yes or no: it is compatible with "Secondary Licenses", unless it is explicitly made incompatible with the notice described in Exhibit B or the covered software was previously available
under MPL-1.1 or earlier, but not also dual-licensed under a "Secondary License".
"Secondary Licenses" are: GPL-2+, LGPL-2.1+, AfferoGPL-3.0+
On Sun Jun 30, 2024 at 11:50 PM CEST, Francesco Poli wrote:[...]
On Sun, 30 Jun 2024 22:37:22 +0200 Serafeim Zanikolas wrote:
[...]I think some incompatibilities are missing.
At least the following ones:
Apache-2.0: GPL-2
the image I've originally linked to in wikipedia suggests that apache-2 is compatible with MPL-2 which in turn is compatible with all GPL licenses.
what am I missing?
[*] Please note that the compatibility status of MPL-2.0 is more complicated than a simple yes or no: it is compatible with "Secondary Licenses", unless it is explicitly made incompatible with the notice described in Exhibit B or the covered software was previously available under MPL-1.1 or earlier, but not also dual-licensed under a "Secondary License".
"Secondary Licenses" are: GPL-2+, LGPL-2.1+, AfferoGPL-3.0+
right, I guess that's why the wikipedia diagram distinguishes between MPL-2 and
MPL-2-no-copyleft-exception. I think that we don't have to worry about that because spdx.org/licenses defines a distinct license identifier for the -no-copyleft-exception variant, and dep5 requires the use of spdx identifiers.
(which is to say that we can assume that MPL-2 is in fact MPL-2 without the copyleft exception and therefore GPL compatible)
anyway, I do expect that we might have to iterate a bit on this, and I don't trust myself to accurate copy things manually from one place to another, so I've put the
revised matrix with all the context over at:
https://salsa.debian.org/debian/adequate/-/blob/tech-notes/license-incompatibility.md
please do feel free to include patches in any follow ups here (e.g with
git format-patch)
I would say that the missing detail is that license compatibility is
not a transitive relation!
Well, before I start sending patches (for instance to reintroduce GPL-2
in the Apache-2.0 row), some questions:
* are you going to completely ignore GPL-1 (assuming it's no longer so
widely adopted)? I am asking because I see that you included it in
the Artistic row, but not in other rows (such as GPL-3 or MPL-2.0
or ...)
* why did you drop LGPL-3 from the GPL-2 row? they are incompatible...
* why did you introduce LGPL-2+, LGPL-2.1, and LGPL-3 in the MPL-1.1
row? as far as I know, the LGPL licenses are (linking-)compatible
with MPL-1.1 ...
[..]right, I guess that's why the wikipedia diagram distinguishes between MPL-2 and
MPL-2-no-copyleft-exception. I think that we don't have to worry about that because spdx.org/licenses defines a distinct license identifier for the -no-copyleft-exception variant, and dep5 requires the use of spdx identifiers.
(which is to say that we can assume that MPL-2 is in fact MPL-2 without the copyleft exception and therefore GPL compatible)
Would you please provide a citation for this update, because it looks to
me like DEP 5 only prohibits the redefinition of "a standard short
name", as well as defining the "trailing dot-zeroes" case. "Standard
please send me a patch, if you don't mind.[...]
If I correctly understand the design philosophy, risking a false
negative is better than risking a false positive.
So I can agree that, when in doubt, adequate should assume there's no
license incompatibility to report...
Francesco, thanks for the patch!
applied and pushed (and additionally added you as an author)
Nicholas, Francesco, you're now both set as reviewers. can I ask you to both let
me know whether you're happy for me to change the review status to completed?
sidenote: I'm toying with the idea of proposing certain markdown conventions to
improve discoverability/visibility of team-local and cross-team proposals, in a
way that's less scary/formal than DEPs, and compatible with email. I'l do a write up about it at some point; please do let me know if you'd like to be an early reviewer
On Sun, 07 Jul 2024 15:50:59 +0200 Serafeim Zanikolas wrote:
Not yet, because I made a mistake.
See the attached patch, which fixes the mistake (basically, when I was writing the various LGPL rows, I was inadvertently thinking about combine-compatibility, rather than link-compatibility, which is the
focus of the matrix...).
can I ask you to both let me know whether you're happy for me to change the review status to completed?
sidenote: I'm toying with the idea of proposing certain markdown conventions to
improve discoverability/visibility of team-local and cross-team proposals, in a
way that's less scary/formal than DEPs, and compatible with email. I'l do a write up about it at some point; please do let me know if you'd like to be an
early reviewer
I don't know much about this topic, but, just a question: have you
considered stuffing these metadata into a YAML metadata block? It is supported by [pandoc] and it also seems to be supported by [Gitlab]...
can I ask you to both let me know whether you're happy for me to change the >> review status to completed?
Do you mean Salsa/github reviewers? To be honest I don't have time to
do a full review...Sorry.
On Mon Jul 8, 2024 at 11:39 PM CEST, Francesco Poli wrote:
On Sun, 07 Jul 2024 15:50:59 +0200 Serafeim Zanikolas wrote:
thanks again Francesco!
[...]the attached patch
[...]fixes the mistake
applied and pushed. which brings me back to:[...]
can I ask you to both let me know whether you're happy for me to
change the review status to completed?
People are going to use this
instead of spending time (and extensive energy) manually checking for
license compat, thus the reviewer[s] sign-off indicates that the matrix
is a trusted shortcut.
...this is much more work than 50 lines. People are going to use this[..]
I don't have time to check the proposed compatibility matrix for
correctness, I haven't checked it, so it's wrong to say that I reviewed
If this is an actual concern (on a second thought, I personally think[..]
it could be!), some more explicit warning could be added to the
Perhaps the background section should be clearer on this.
And a FAQ could be added.
Personally, I cannot see anything else that needs to be fixed
in the [current] version of the technical note. I think it is
'adequately' fit for its purpose... ;-)
I hope that the technical note, once finalized, gets included in
package 'adequate', under the same license as the rest of package
(Expat).
Also, do you plan to automatically extract the incompatibility matrix
from the technical note itself? That would prevent the matrix (as used
by the "adequate" command) from ever becoming inconsistent with the documented matrix (as found in the technical note)...
On Tue Jul 16, 2024 at 12:10 AM CEST, Francesco Poli wrote:
[..]
If this is an actual concern (on a second thought, I personally think[..]
it could be!), some more explicit warning could be added to the
Perhaps the background section should be clearer on this.
And a FAQ could be added.
I've added a note in the background, a comment in the MPL-2 entry, and an additional FAQ entry.
Personally, I cannot see anything else that needs to be fixed
in the [current] version of the technical note. I think it is
'adequately' fit for its purpose... ;-)
thanks, changed your review status to approved.
I hope that the technical note, once finalized, gets included in
package 'adequate', under the same license as the rest of package
(Expat).
I haven't thought about licensing (the irony!). Expat sgtm.
Also, do you plan to automatically extract the incompatibility matrix
from the technical note itself? That would prevent the matrix (as used
by the "adequate" command) from ever becoming inconsistent with the documented matrix (as found in the technical note)...
I guess I could move it to the main branch, although I'm not sure that I'd bother with technically enforcing the consistency. the nice thing of having it
in a separate branch is that one can subscribe to the branch RSS feed from salsa
without having to be notified about changes in the adequate code.
On Sat Jul 20, 2024 at 6:00 PM CEST, Francesco Poli wrote:[...]
I think that writing "on-behalf-of: debian-legal@" could give the wrong impression that I have been officially appointed as a spokesperson of
the debian-legal mailing list.
I see, I understand your concern. I've now changed this to
"review-context: debian-legal@"
to highlight that the review didn't happen in the dark nor in an off-topic place
I hope that the technical note, once finalized, gets included in package 'adequate', under the same license as the rest of package (Expat).
it's now in adequate's master branch and shipped in /usr/share/doc. I did not add a license field in the markdown file itself, because debian/copyright already covers that.
But debian/copyright does not have a stanza for that file (license-incompatibility.md)...[..]
If you really consider me as a co-author (despite the very little contribution I provided), then you should create a separate stanza in
the debian/copyright:
Also, I would suggest to not repeat the Expat license text multiple
times, it's probably better, if you put the license text into a stanza
on its own...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 22:18:17 |
| Calls: | 12,105 |
| Calls today: | 5 |
| Files: | 15,006 |
| Messages: | 6,518,126 |
