Re: compatibility matrix for /usr/share/common-licenses

[Serafeim Zanikolas]

On Sat Jul 27, 2024 at 5:18 PM CEST, Francesco Poli wrote:
[..]
> 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...

done and done in 0.16.5

thanks,
Serafeim


signature.asc
Description: PGP signature

Question about BuSL / transform-on-time licenses

[Joe Brockmeier]

Hi all,

The Fedora Project is discussing how to properly represent code that
was originally licensed under the Business Source License (BuSL) and
other licenses that transform on time. [1]

Specifically - let's say there's a project that uses the Business
Source License (BuSL) and is supposed to convert to GPL after N years.
Obviously, the GPL is an acceptable license for Debian - but what steps
would be required to ensure the entire codebase had converted so that
no parts would still be under BuSL?

I'm wondering if the Debian Project has a position on this that's
documented somewhere, or if this has come up yet? I'm specifically
interested in how the project would address risk / confirm that the
whole codebase had transformed or if Debian would avoid a (formerly)
BuSL licensed project entirely. [2]

I'd skimmed through the archives but haven't found anything - which
doesn't mean it does not exist, I may just have failed in my searching. 

[1] 
https://lwn.net/ml/fedora-legal/CALC7GWw7F5Bz_+5GTGW1+3xz1DZg5RLn=bxi-r7rt_x0uqn...@mail.gmail.com/

[2] 
https://lwn.net/ml/fedora-legal/cac1cpgztsud5d5xo4aukpgypwvz+rze_pzvnmneb-_pkgg+...@mail.gmail.com/

-- 
Joe Brockmeier | Editor, LWN | j...@lwn.net | https://lwn.net

Re: compatibility matrix for /usr/share/common-licenses

[Francesco Poli]

On Mon, 22 Jul 2024 01:12:52 +0200 Serafeim Zanikolas wrote:

[...]
> 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

Good.

[...]
> > > > 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:

  Files: tech-notes/license-incompatibility.md
  Copyright: 2024 Serafeim Zanikolas 
 2024 Francesco Poli 
  License: Expat

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...

Thanks!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpcsaFqRTMGb.pgp
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Francesco Poli]

On Wed, 17 Jul 2024 00:38:57 +0200 Serafeim Zanikolas wrote:

> 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.

OK, that looks better.
I hope this is enough to clarify that manual license compatibility
checks should not stop, just because one can run 'adequate'...

> 
> > 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.

Just one nitpick about the metadata:

  reviewer: invernom...@paranoici.org
  review-status: approved
  on-behalf-of: debian-legal@

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 am not a spokesperson.
I am just one debian-legal participant, with my own opinions and
standpoint (which sometimes are similar to those of some other
debian-legal participants, sometimes are not!).

Please fix this line.
Thanks.

> 
> > 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.

Good, thanks for agreeing on the licensing for the technical note.

> 
> > 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.

I am convinced that the technical note really belongs to package
'adequate', so I would strongly encourage you to move the document
inside the package (probably to be installed
under /usr/share/doc/adequate/ ).

Extracting the matrix from the technical note at package build time (in
some sort of literate programming fashion) would ensure that one does
not forget to modify the documentation, when the matrix has to be
modified, or the other way round.
But I think I had already clarified the rationale behind my suggestion.
I acknowledge that it could be a bit tricky, but it would be nice to
have...



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpZHJvAuoaCD.pgp
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Serafeim Zanikolas]

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.

thanks,
Serafeim


signature.asc
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Serafeim Zanikolas]

On Tue Jul 16, 2024 at 12:27 AM CEST, Nicholas D Steeves wrote:
> ...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

that makes sense. I'll add you as a contributor and drop you as a reviewer.

thanks again,
Serafeim


signature.asc
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Francesco Poli]

On Mon, 15 Jul 2024 18:27:24 -0400 Nicholas D Steeves wrote:

[...]
> 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.

Well, I hope people will not skip any manual license compatibility
check, just because 'adequate' is able to complain about some simple
and well-known incompatibilities!

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
technical note, highlighting that the design philosophy is to allow for
a good number of false negatives, in order to try hard to avoid false
positives.
Perhaps the background section should be clearer on this.
And a FAQ could be added.

Serafeim, do you agree?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpuDhrPR5T7o.pgp
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Nicholas D Steeves]

"Serafeim Zanikolas"  writes:

> Hi Nicholas,
>
>>> 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.
>
> no, I really mean this in the simplest possible way: review the 50 lines of 
>
>   
> https://salsa.debian.org/debian/adequate/-/blob/tech-notes/license-incompatibility.md

...this is much more work than 50 lines.  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.

> and let me know if you approve of it. if you have changes to propose, either a
> patch or comments here are fine
>
> in any case, happy to drop you off the reviewers list if that sounds too much
> for you at this point

I only asked for clarification about the claims you made about DEP5
as well as unpacking it a bit.  If you'd like to make a note of that
somewhere, feel free to.

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
it.

Thanks,
Nicholas


signature.asc
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Francesco Poli]

On Sun, 14 Jul 2024 23:35:18 +0200 Serafeim Zanikolas wrote:

> 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!

You're welcome.   :-)

[...]
> > 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?
[...]

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...   ;-)

[current]: 


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)...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpbqZt9GBDic.pgp
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Serafeim Zanikolas]

Hi Nicholas,

>> 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.

no, I really mean this in the simplest possible way: review the 50 lines of 


https://salsa.debian.org/debian/adequate/-/blob/tech-notes/license-incompatibility.md

and let me know if you approve of it. if you have changes to propose, either a
patch or comments here are fine

in any case, happy to drop you off the reviewers list if that sounds too much
for you at this point

thanks again,
Serafeim


signature.asc
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Serafeim Zanikolas]

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!
> 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...).

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?

> > 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]...

thanks, I'll discuss this in the various options considered when I do get to
write that doc. for now though, my thinking is to keep it as simple as possible
(unobtrusive when presented as raw text, which yaml is, and keeping parsing
requirements to a minimum)


signature.asc
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Nicholas D Steeves]

Hi Serafeim,

"Serafeim Zanikolas"  writes:

> 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?
>

Do you mean Salsa/github reviewers?  To be honest I don't have time to
do a full review...Sorry.

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Francesco Poli]

On Sun, 07 Jul 2024 15:50:59 +0200 Serafeim Zanikolas wrote:

> Francesco, thanks for the patch!

You are welcome!

> applied and pushed (and additionally added you as an author)

Good.

> 
> 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?

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...).

> 
> 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]...

[pandoc]: 
[Gitlab]: 


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


license-incompatibility_2.diff.gz
Description: application/gzip


pgpdFcBnRPv0p.pgp
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Serafeim Zanikolas]

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 Jul 7, 2024 at 12:19 AM CEST, Francesco Poli wrote:
> 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...

that's right.

thanks again!


signature.asc
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Francesco Poli]

On Fri, 05 Jul 2024 23:17:04 +0200 Serafeim Zanikolas wrote:

[...]
> my inclination is
> to KISS and assume that all "License: MPL-2" is without the copyleft
> restriction

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...

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpX8jnLQhMmB.pgp
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Francesco Poli]

On Fri, 05 Jul 2024 22:27:41 +0200 Serafeim Zanikolas wrote:

[...]
> please send me a patch, if you don't mind.
[...]

I am attaching a patch that tries to improve the technical note.
I hope this helps.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


license-incompatibility.diff.gz
Description: application/gzip


pgpVqdHXgglTk.pgp
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Serafeim Zanikolas]

hi Nicolas,

thanks for the feedback!

On Tue Jul 2, 2024 at 10:24 PM CEST, Nicholas D Steeves wrote:
> > 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
[..]

no, you're right -- and I've only now read
https://wiki.debian.org/Proposals/CopyrightFormat which makes abundantly clear
that we care little about spdx.

that brings us back to the question of what to do with MPL-2. my inclination is
to KISS and assume that all "License: MPL-2" is without the copyleft
restriction, and only assume otherwise if we ever encounter
MPL-2-no-copyleft-exception (which does not seem to be used anywhere today,
according to codesearch.debian.net)

if that sounds reasonable to you, I'll update accordingly the relevant FAQ entry
in the tech note.


signature.asc
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Serafeim Zanikolas]

hi Francesco,

> I would say that the missing detail is that license compatibility is
> not a transitive relation!

indeed! I knew that but somehow it fell off my consciousness while looking at
that wikipedia diagram

> 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 ...

sorry, that's all sloppiness on my part, at the end of a long day. please send
me a patch, if you don't mind. as for GPL-1, either way is fine (it wasn't
included in adequate as of 8y ago, and I only see GPL-1+ references in my local
system, so it certainly seems reasonable to drop it)


signature.asc
Description: PGP signature

Re: Missing copyright clause of debian directory

[Soren Stoutner]

Xiyue,

On Tuesday, July 2, 2024 2:31:47 PM MST Xiyue Deng wrote:
> Actually I think this was the case for web-mode given Thomas' response
> in [1].  Also, when I asked in #debian-mentors, more people share the
> same view and they also choose not to add a separate license clause for
> "File: debian/*" as a result.  I think that suggests that omitting it
> may be a common practice, and if that is common enough, it could be
> considered intentional.

Having read Thomas’ response in the bug report, I can tell you that his 
opinions about copyright (that is it not important, and that Debian shouldn’t 
be so worried about it) does not reflect the general consensus in the Debian 
community.

I don’t have a conclusive answer as to how many packages do not have an 
explicit debian/* entry in their copyright file, but my personal experience is 
that it is not common.  I can’t think of a single package, besides this one, 
that does not have it.  Also, I can’t imagine you would find anyone on Mentors 
who would be willing to sponsor a package without an explicit debian/* 
copyright entry.

Despite whatever might be argued to the contrary as to how copyrightable the 
contents of debian/* are, the consensus of the Debian community is that they 
are copyrightable and that the copyright and licensing information should be 
explicitly stated.

-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: Missing copyright clause of debian directory

[Xiyue Deng]

Nicholas D Steeves  writes:

> [[PGP Signed Part:Undecided]]
> Hello,
>
> Soren Stoutner  writes:
>
>> On Wednesday, June 26, 2024 3:13:38 PM MST Nicholas D Steeves wrote:
>>> Soren Stoutner  writes:
>>
>> When debian/copyright contains a “Files: *” without a separate “Files: 
>> debian/*” section, it is 
>> making an explicit statement that the entire debian directory is licenses 
>> with the 
>> information listed in “Files: *”.  It is possible, even likely, that this 
>> was a typo, and doesn’t 
>> represent the intention of the author of the debian/* files, but it is what 
>> he wrote down.
>
> If "it is possible, even likely, that it is a typo", intention cannot be
> inferred, and due diligence and goodwill need to be demonstrated before
> proceeding; this is why we contact the people involved in such cases.
>
>> Unless there is some other written indication that the author of the 
>> original debian/* files 
>> intended a different license, **we have to assume he meant what he wrote** 
>> when he 
>> drafted debian/copyright.
>
> This is a conclusion of convenience, not one of necessity.  Legal
> battles cost money--even stupid and self-evident ones like trademarks
> where there was already prior art.  Our upstream copyright statements
> are one of convenience, but our debian/* statements are actual.
>
>> Soren
>>
>> PS. To fully flush out this discussion, this is what was written in 
>> debian/copyright:
>>
>> Files: *
>> Copyright: 2011-2019 François-Xavier Bois
>> License:   GPL-2+
>>
>> François-Xavier Bois is the upstream developer.  Thomas Koch 
>>  is the 
>> package maintainer who wrote debian/copyright.  If he had intended to 
>> license his 
>> contributions under the GPL-2+, I would have expected that he would have 
>> added his name 
>> to the copyright field (or, even better, created a separate debian/* 
>> section).  But, copyright 
>> law allows an author to transfer their copyright to another party.
>
> I agree, but this is not without pitfalls and ambiguities, particularly
> when looking at international cases.
>
>> So, imagine that Thomas 
>> Koch wanted to transfer his copyright for debian/* to François-Xavier Bois.  
>> If that was what 
>> he wanted to do, then he could indicate that by putting the following in 
>> debian/copyright:
>>
>> Files: *
>> Copyright: 2011-2019 François-Xavier Bois
>> License:   GPL-2+
>
> Comment: This is what the DEP5 comment field is for, and where the
>  intention to assign copyright may be unambiguously declared.
>  Alternatively, the author could say here that the work does not meet
>  the threshold for originality necessary for copyright to occur.

Actually I think this was the case for web-mode given Thomas' response
in [1].  Also, when I asked in #debian-mentors, more people share the
same view and they also choose not to add a separate license clause for
"File: debian/*" as a result.  I think that suggests that omitting it
may be a common practice, and if that is common enough, it could be
considered intentional.

Still, I think it would be good to have a policy or recommendation on
how a DD or DM should do here.  I don't see this addressed in the Debian
Policy or the Debian Developer Manual though.

>  Alternatively, a debian/* "License: CC0" could have been declared as an
>  "I don't care what you do with this" statement.
>
>> And because that is exactly what he did put in debian/copyright, we have to 
>> assume he 
>> meant what he wrote unless we have some other communication from him 
>> indicating 
>> otherwise.
>
> because -> therefore is neither valid nor true.
>
> All this aside, I think we can agree that it is wrong to write copyright
> statements on behalf of other people without their knowledge or consent;
> this was primarily why I sent my mentee here.  I'm also surprised that
> no one mentioned that the longer the list of copyright holders, the
> harder it is to ever change to a potentially better license (eg: The
> Linux kernel is likely to remain GPL-2-only forever, unless rewritten).
>
> Regards,
> Nicholas
>
> [[End of PGP Signed Part]]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074413#10

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Re: Missing copyright clause of debian directory

[Nicholas D Steeves]

Hello,

Soren Stoutner  writes:

> On Wednesday, June 26, 2024 3:13:38 PM MST Nicholas D Steeves wrote:
>> Soren Stoutner  writes:
>
> When debian/copyright contains a “Files: *” without a separate “Files: 
> debian/*” section, it is 
> making an explicit statement that the entire debian directory is licenses 
> with the 
> information listed in “Files: *”.  It is possible, even likely, that this was 
> a typo, and doesn’t 
> represent the intention of the author of the debian/* files, but it is what 
> he wrote down.

If "it is possible, even likely, that it is a typo", intention cannot be
inferred, and due diligence and goodwill need to be demonstrated before
proceeding; this is why we contact the people involved in such cases.

> Unless there is some other written indication that the author of the original 
> debian/* files 
> intended a different license, **we have to assume he meant what he wrote** 
> when he 
> drafted debian/copyright.

This is a conclusion of convenience, not one of necessity.  Legal
battles cost money--even stupid and self-evident ones like trademarks
where there was already prior art.  Our upstream copyright statements
are one of convenience, but our debian/* statements are actual.

> Soren
>
> PS. To fully flush out this discussion, this is what was written in 
> debian/copyright:
>
> Files: *
> Copyright: 2011-2019 François-Xavier Bois
> License:   GPL-2+
>
> François-Xavier Bois is the upstream developer.  Thomas Koch  
> is the 
> package maintainer who wrote debian/copyright.  If he had intended to license 
> his 
> contributions under the GPL-2+, I would have expected that he would have 
> added his name 
> to the copyright field (or, even better, created a separate debian/* 
> section).  But, copyright 
> law allows an author to transfer their copyright to another party.

I agree, but this is not without pitfalls and ambiguities, particularly
when looking at international cases.

> So, imagine that Thomas 
> Koch wanted to transfer his copyright for debian/* to François-Xavier Bois.  
> If that was what 
> he wanted to do, then he could indicate that by putting the following in 
> debian/copyright:
>
> Files: *
> Copyright: 2011-2019 François-Xavier Bois
> License:   GPL-2+

Comment: This is what the DEP5 comment field is for, and where the
 intention to assign copyright may be unambiguously declared.
 Alternatively, the author could say here that the work does not meet
 the threshold for originality necessary for copyright to occur.
 Alternatively, a debian/* "License: CC0" could have been declared as an
 "I don't care what you do with this" statement.

> And because that is exactly what he did put in debian/copyright, we have to 
> assume he 
> meant what he wrote unless we have some other communication from him 
> indicating 
> otherwise.

because -> therefore is neither valid nor true.

All this aside, I think we can agree that it is wrong to write copyright
statements on behalf of other people without their knowledge or consent;
this was primarily why I sent my mentee here.  I'm also surprised that
no one mentioned that the longer the list of copyright holders, the
harder it is to ever change to a potentially better license (eg: The
Linux kernel is likely to remain GPL-2-only forever, unless rewritten).

Regards,
Nicholas


signature.asc
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Nicholas D Steeves]

Hi,

Thanks for your work.

"Serafeim Zanikolas"  writes:

> 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
short name" presumably means that it is wrong to declare "License:
GPL-3+", but then use some-other license text; ie, well-known licenses
names cannot be redefined.  2.0.0 is equal to 2.0 and 2 for SPDX compat.
Other than that, I cannot see where DEP 5 necessitates the use of SPDX
identifiers.

In some cases, we actually prohibit SPDX idenfiers in Debian: For
example, "Licence: MIT" vs "License: Expat".  To the best of my
knowledge proponents of DEP5 retain the right to use Debian-specific
"standard short name[s]" rather than SPDX ones, and we don't have any
kind of official or unofficial SPDX-specific position other than the
"trailing dot-zeroes" case.

Did I miss something?
Nicholas


signature.asc
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Francesco Poli]

On Tue, 02 Jul 2024 00:01:54 +0200 Serafeim Zanikolas wrote:

[...]
> 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?
[...]

GPL-2 is compatible with BSD-3-clause
BSD-3-clause is compatible with a proprietary license

however, GPL-2 is incompatible with a proprietary license

I would say that the missing detail is that license compatibility is
not a transitive relation!

> 
> > [*] 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)

OK, so by "MPL-2.0" we are only referring to the MPL version 2.0
license applied in such a way to be compatible with "Secondary
Licenses".

> 
> 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)

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 ...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgppXEnsZ7b4_.pgp
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Serafeim Zanikolas]

hello Francesco! nice to read you too and thanks for the feedback :)

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:
[..]
> If I understand correctly, we are talking about linking-compatibility
> here.

that's right

I guess I should have specified that for the purposes of adequate, we need to
err on the side of false negatives (otherwise, I imagine that there'd be so many
false positives that people would stop paying attention).

> 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? (of course, it's possible that an apache-2 lib depends on
MPL-2-no-copyleft-exception, but we only need to enumerate direct binary/lib
relations here)

> [*] 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)

thanks again,
Serafeim



signature.asc
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Francesco Poli]

On Sun, 30 Jun 2024 22:37:22 +0200 Serafeim Zanikolas wrote:

> hello Debian legal folks,

Hello Serafeim,
nice to read you!

> 
> 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

If I understand correctly, we are talking about linking-compatibility
here.
Different compatibility relationships hold for mixing (that is to say,
taking parts of two works and merging them together to form a new work).

> 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)

I think some incompatibilities are missing.
At least the following ones:

  Apache-2.0: GPL-2
  Artistic: GPL-1, GPL-2, GPL-3
  BSD:
  GPL-2: Apache-2.0, Artistic, GPL-1, GPL-3, LGPL-3, MPL-1.1, MPL-2.0[*]
  GPL-2+: Artistic, GPL-1, MPL-1.1, MPL-2.0[*]
  GPL-3: Artistic, GPL-1, GPL-2, MPL-1.1, MPL-2.0[*]
  LGPL-2: GPL-1, MPL-1.1, MPL-2.0[*]
  LGPL-2.1: GPL-1, MPL-1.1, MPL-2.0[*]
  LGPL-3: GPL-1, GPL-2, MPL-1.1, MPL-2.0[*]
  MPL-1.1: GPL-1, GPL-2, GPL-2+, GPL-3
  MPL-2.0[*]: GPL-1, GPL-2, GPL-2+, GPL-3
  OpenSSL: (GPL licenses ommitted here due to 
https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException)

[*] 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+

A terrible headache?!? I think so, that's why I abhor MPL-2.0 ... 

> 
> thanks,
> Serafeim

You're welcome!

Anyway, let's wait for some other debian-legal participants'
take on the matter...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpE9FVmzzNid.pgp
Description: PGP signature

Re: compatibility matrix for /usr/share/common-licenses

[Serafeim Zanikolas]

I've missed the GPL-2/LGPL-3 incompatibility:

>   GPL-2: GPL-3, MPL-1.1
should be:
GPL-2: GPL-3, MPL-1.1, LGPL-3

>   LGPL-3: MPL-1.1
should be:
LGPL-3: MPL-1.1, GPL-2

ps. please cc me on replies


signature.asc
Description: PGP signature

compatibility matrix for /usr/share/common-licenses

[Serafeim Zanikolas]

hello Debian legal folks,

I'm looking for an up-to-date compatibility matrix of /usr/share/common-licenses
(modulo documentation licenses). I've recently taken over the Debian-native
package adequate, which among other things checks for binaries that link in
libraries that are available under an incompatible license, and its
compatibility logic is rather outdated.

based on:
https://en.wikipedia.org/wiki/File:Floss-license-slide-image.svg
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

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


signature.asc
Description: PGP signature

Re: Missing copyright clause of debian directory

[Xiyue Deng]

Soren Stoutner  writes:

> Xiyue,
>
> On Thursday, June 27, 2024 9:50:18 PM MST Xiyue Deng wrote:
>> Thanks for your reply.  I agree it is important to clear this situation.
>> I think regardless of how the current situation should be interpreted,
>> contacting Thomas for confirmation about licensing his packaging work
>> under a GPL compatible license (preferably the same license) would be a
>> good step forward.  I'll try to open a bug and initiate from there.
>
> That is by far the preferred solution.
>  

Thomas has kindly replied in bug#1074413[1] and granting permission to
handle copyright of packages he maintained according to current
practice.

I'm now CCing David to ask for permission to clarify copyright of
web-mode as he also worked on it.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074413#10

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Re: Missing copyright clause of debian directory

[Soren Stoutner]

Xiyue,

On Thursday, June 27, 2024 9:50:18 PM MST Xiyue Deng wrote:
> Thanks for your reply.  I agree it is important to clear this situation.
> I think regardless of how the current situation should be interpreted,
> contacting Thomas for confirmation about licensing his packaging work
> under a GPL compatible license (preferably the same license) would be a
> good step forward.  I'll try to open a bug and initiate from there.

That is by far the preferred solution.
 
> Also I have a few questions to help myself understand the situation.
> I'd like to have the following assumption: I intend to believe that when
> Thomas worked on packaging web-mode, he probably forgot to add the
> copyright justification for `debian/*' by mistake, as we see that he did
> it for the package lsp-treemacs[1].  Now, as the upstream uses GPL (v2
> initially, upgraded to v3 later), it requires that all derivative works
> should be covered by the same license, so AIUI the packaging work should
> be covered by GPL by default, but without a clear copyright holder.
> With the current "Files: *" wildcard, it should cover the derivative
> work under `debian/' (though by mistake).  So my question is: does that
> really make this code not DFSG-free?

If we are not able to get a response from Thomas (and David), I think there is 
enough information to create the following debian/copyright entry:

Files:  debian/*
Copyright:  2019-2020 Thomas Koch 
 2019 David Bremner 
License:  GPL-2+

The GPL-2+ license comes from the existing debian/copyright file[1], which 
states that all files are under the GPL-2+.  The copyright holders come from 
the changelog[2], and is a list of everyone who edited files in debian/*.

[1] https://sources.debian.org/src/web-mode/17.0.2-1/debian/copyright/
[2] https://sources.debian.org/src/web-mode/17.0.2-1/debian/changelog/

-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: Missing copyright clause of debian directory

[Xiyue Deng]

Hi Nicholas,

Nicholas D Steeves  writes:

> Soren Stoutner  writes:
>
>> As an additional followup, as the original debian/* files were licensed 
>> GPLv2+, 
>> if you edit a file you can choose to make your contribution GPLv3+, which 
>> would 
>> convert the entire file to GPLv3+.  If you end up editing all of the files 
>> in 
>> debian/* at least once, you could convert the entire copyright entry to 
>> GPLv3+.
>>
>
> Soren, would you please provide evidence for "the original debian/*
> files were licensed GPLv2+"?  It looks to me like:
>
> 1. Thomas Koch gained copyright on fixation (ie: automatic in Berne
> Convention countries)
> 2. Thomas Koch did not license his work
> :. Thomas Koch retains "all rights reserved" and our web-mode has never
> actually been dfsg-free
>
> 3. Alternatively one could argue this: The initial packaging is not
> sufficiently original for debian/* to be copyrightable; however, this is
> a question for lawyers, because it varies by jurisdiction.
>
>   
> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4620875#:~:text=Originality%20is%20a%20pre%2Dcondition,been%20copied%20from%20another%20work.
>   https://academic.oup.com/jiplp/article-pdf/13/8/597/25099746/jpy084.pdf
>
> 4. Also, if this is the case than it is *wrong* to declare Koch's
> copyright and speculative license.
>
> In conclusion, Thomas Koch needs to be contacted and a record needs to
> exist on Debian infrastructure.  So either on-list, or on the BTS, or
> the method I had to use in src:muse-el, which is a package Xiyue Deng
> (manphiz) maintains and must therefore be familiar with.
>
> Regards,
> Nicholas
>

Thanks for your reply.  I agree it is important to clear this situation.
I think regardless of how the current situation should be interpreted,
contacting Thomas for confirmation about licensing his packaging work
under a GPL compatible license (preferably the same license) would be a
good step forward.  I'll try to open a bug and initiate from there.

Also I have a few questions to help myself understand the situation.
I'd like to have the following assumption: I intend to believe that when
Thomas worked on packaging web-mode, he probably forgot to add the
copyright justification for `debian/*' by mistake, as we see that he did
it for the package lsp-treemacs[1].  Now, as the upstream uses GPL (v2
initially, upgraded to v3 later), it requires that all derivative works
should be covered by the same license, so AIUI the packaging work should
be covered by GPL by default, but without a clear copyright holder.
With the current "Files: *" wildcard, it should cover the derivative
work under `debian/' (though by mistake).  So my question is: does that
really make this code not DFSG-free?

Thanks.

P.S. For the handling of src:muse-el, I notice that you removed the
copyright section for `File: debian/*', wait until all the relevant
copyright holders to declare their work to be compatible by email,
record them in debian/COPYING.emails[2], before restoring the section of
`File: debian/*'.  I think getting a confirmation from Thomas on one of
the mailing list should serve the same purpose and adding a link to the
email in debian/copyright should suffice in that case.

P.P.S. Just saw Soren's reply before sending this mail, which seems to
align with my speculation.

[1] 
https://salsa.debian.org/emacsen-team/lsp-treemacs/-/blob/6989a183622eab889dc9c0d40d0853378d069439/debian/copyright
[2] 
https://salsa.debian.org/emacsen-team/muse-el/-/blob/master/debian/COPYING.emails?ref_type=heads

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Re: Missing copyright clause of debian directory

[Soren Stoutner]

On Wednesday, June 26, 2024 3:13:38 PM MST Nicholas D Steeves wrote:
> Soren Stoutner  writes:
> > As an additional followup, as the original debian/* files were licensed
> > GPLv2+, if you edit a file you can choose to make your contribution GPLv3+,
> > which would convert the entire file to GPLv3+.  If you end up editing all
> > of the files in debian/* at least once, you could convert the entire
> > copyright entry to GPLv3+.
> 
> Soren, would you please provide evidence for "the original debian/*
> files were licensed GPLv2+"?  It looks to me like:

This is based on the statement in the original email.

>I start working on adopting web-mode whose previous maintainer Thomas
>Koch[1] became MIA (see Bug#1019031).  When working on d/copyright, it
>turns out that there was only one copyright section that covered "Files:
>*" with upstream copyright owners but no separate section for "debian/*"
>(see also the d/copyright of the snapshot of version 17.0.2-1[2]).
>After checking the upstream copyright[3], I don't see the previous
>maintainer in the list of copyright owners, therefore I believe the
>current d/copyright is at mistake by covering the content in debian
>directory under "Files: *".

When debian/copyright contains a “Files: *” without a separate “Files: 
debian/*” section, it is 
making an explicit statement that the entire debian directory is licenses with 
the 
information listed in “Files: *”.  It is possible, even likely, that this was a 
typo, and doesn’t 
represent the intention of the author of the debian/* files, but it is what he 
wrote down.

Unless there is some other written indication that the author of the original 
debian/* files 
intended a different license, **we have to assume he meant what he wrote** when 
he 
drafted debian/copyright.

Soren

PS. To fully flush out this discussion, this is what was written in 
debian/copyright:

Files: *
Copyright: 2011-2019 François-Xavier Bois
License:   GPL-2+

François-Xavier Bois is the upstream developer.  Thomas Koch  
is the 
package maintainer who wrote debian/copyright.  If he had intended to license 
his 
contributions under the GPL-2+, I would have expected that he would have added 
his name 
to the copyright field (or, even better, created a separate debian/* section).  
But, copyright 
law allows an author to transfer their copyright to another party.  So, imagine 
that Thomas 
Koch wanted to transfer his copyright for debian/* to François-Xavier Bois.  If 
that was what 
he wanted to do, then he could indicate that by putting the following in 
debian/copyright:

Files: *
Copyright: 2011-2019 François-Xavier Bois
License:   GPL-2+

And because that is exactly what he did put in debian/copyright, we have to 
assume he 
meant what he wrote unless we have some other communication from him indicating 
otherwise.


signature.asc
Description: This is a digitally signed message part.

Re: Missing copyright clause of debian directory

[Nicholas D Steeves]

Soren Stoutner  writes:

> As an additional followup, as the original debian/* files were licensed 
> GPLv2+, 
> if you edit a file you can choose to make your contribution GPLv3+, which 
> would 
> convert the entire file to GPLv3+.  If you end up editing all of the files in 
> debian/* at least once, you could convert the entire copyright entry to 
> GPLv3+.
>

Soren, would you please provide evidence for "the original debian/*
files were licensed GPLv2+"?  It looks to me like:

1. Thomas Koch gained copyright on fixation (ie: automatic in Berne
Convention countries)
2. Thomas Koch did not license his work
:. Thomas Koch retains "all rights reserved" and our web-mode has never
actually been dfsg-free

3. Alternatively one could argue this: The initial packaging is not
sufficiently original for debian/* to be copyrightable; however, this is
a question for lawyers, because it varies by jurisdiction.

  
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4620875#:~:text=Originality%20is%20a%20pre%2Dcondition,been%20copied%20from%20another%20work.
  https://academic.oup.com/jiplp/article-pdf/13/8/597/25099746/jpy084.pdf

4. Also, if this is the case than it is *wrong* to declare Koch's
copyright and speculative license.

In conclusion, Thomas Koch needs to be contacted and a record needs to
exist on Debian infrastructure.  So either on-list, or on the BTS, or
the method I had to use in src:muse-el, which is a package Xiyue Deng
(manphiz) maintains and must therefore be familiar with.

Regards,
Nicholas


signature.asc
Description: PGP signature

Re: Request for feedback: licensing a public specification

[Francesco Poli]

On Mon, 24 Jun 2024 15:34:35 +0100 Simon McVittie wrote:

[...]
> Perhaps consider using
> , the legal terms
> of the RFC that describes Vorbis-over-RTP:
> 
>The authors agree to grant third parties the irrevocable right to
>copy, use, and distribute the work, with or without modification, in
>any medium, without royalty, **provided that, unless separate
>permission is granted, redistributed modified works do not contain
>misleading author, version, name of work, or endorsement information.**
> 
> (my emphasis)
[...]

I fully agree with Simon's reasoning about the importance of the
permission to modify the specification (and, more generally, about the
importance for the specification document to be Free Software).

I would personally suggest the [zlib] license for such a document.
It explicitly requires that altered versions be plainly marked as such,
and not be misrepresented as being the original.

[zlib]: 



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpruGiiGRFEw.pgp
Description: PGP signature

Re: Request for feedback: licensing a public specification

[Simon McVittie]

On Mon, 24 Jun 2024 at 14:44:18 +0100, Nathan Willis wrote:
> And those factors would need to interact predictably with a specification
> document that is free to read, implement, and share ... but the specification
> should not be forked or modified (since that would defeat the purpose:
> interoperability).

I don't think enforcing "no derivative works" via copyright
law (like Creative Commons CC-ND) is the right way to ensure
interoperability. Instead, I think the right way is to require modified
versions to be clearly marked as not being the original - more like
the approach taken by Creative Commons CC-BY.

Consider this scenario: you publish your standard, version 1.0;
time passes; you disappear and cannot be contacted any more; more time
passes; now I want to produce a compatible version 1.1 of the standard
containing clarifications or extensions, or an incompatible version 2.0
with significant changes (like HTTP -> HTTP2), or correcting a design
mistake that cannot be fixed without a compatibility break.

I think the legal situation that the community would want in that
scenario is that I can modify and share draft copies of what I want to
put in version 1.1 or 2.0, or even fork the specification to make my
own intentionally incompatible specification under a different name if I
really need to, but I have to label them as something clearly different
(unless/until my changes have been agreed on and accepted by whatever
is the most appropriate standards body that controls the "branding"
on your behalf).

A document that enforces "no derivative works" via copyright law is also
likely to be forbidden from inclusion in Debian, because we require that
everything we ship is Free Software (not just code, like e.g. Fedora,
but also non-code like data and documentation, unlike Fedora). And if
copy/pasting spec text into Free Software source code is a use-case
for you, that is not a context where modifications can be disallowed,
because if they were, it wouldn't be Free Software.

Perhaps consider using
, the legal terms
of the RFC that describes Vorbis-over-RTP:

   The authors agree to grant third parties the irrevocable right to
   copy, use, and distribute the work, with or without modification, in
   any medium, without royalty, **provided that, unless separate
   permission is granted, redistributed modified works do not contain
   misleading author, version, name of work, or endorsement information.**

(my emphasis)

If you want stronger protection against passing off an incompatible
not-quite-Opentype-Shaping specification as being genuine Opentype Shaping,
then trademarks rather than copyright are probably a better tool:
not allowing "counterfeits" to harm your reputation or inappropriately
benefit from your reputation is literally the purpose of trademarks!

smcv

Request for feedback: licensing a public specification

[Nathan Willis]

Hi all,

I am interested in hearing some genuine feedback on a new license that I
was in a position to need and have therefore drafted.

It is specifically for a "functional specification", which individual
implementers might implement separately in their own environments or
software stacks, but which (unlike, say, a network protocol) are not going
to directly interface with other implementations. And to be usable for free
software, naturally (although not requiring every implementer to swear to
any particular software licensing ethos).

By way of background, I did a thorough search of other licensing options
before heading down the path of making a bespoke one and, although I see a
lot of commonality in the licenses used on specifications and standards
like IS/IETF or W3C publications, the actual licenses employed there are
specific to those works and to e.g. the W3C itself and, as a result, not
reusable.

Conversely, I think it is evident on even a cursory evaluation that a
boilerplate "document license" like the GFDL or the crop of CC licenses do
not fit several of the specific requirements for a specification license
that software will have to implement. Nor, of course, do software licenses.
I don't want to head into an endless tangent on those points, but if you're
interested in the reasons I enumerated during that survey, please do feel
free to email me privately (or perhaps fork the thread?). I also did a
session in the legal & policy devroom at FOSDEM 2023 about this project; I
can dig up a link to the video I'm sure.

The point is, though, that when exploring it there were a few needs that
stuck out as being peculiar to an "independent functional spec" use case.
The big ones were:

- Implementations need to be able to quote from the spec, even sometimes in
big chunks, in comments and such, but still not be roped in as derivative
works
- Code snippets like algorithms, regular expression sets, and even variable
or structure names need to be freely reusable, but not rope the
implementation in as a derivative work
- Translations should be permitted but must be designated as unofficial
(due to the fact that translating human language is always ambiguous)

And those factors would need to interact predictably with a specification
document that is free to read, implement, and share ... but the
specification should not be forked or modified (since that would defeat the
purpose: interoperability).

All that preamble now out of the way, the actual draft license in question
is accessible here:
https://github.com/n8willis/opentype-shaping-documents/blob/license/LICENSE.md

You'll note that it is in a WIP draft and not yet committed. I believe it
is readable at that URL even if you don't use JavaScript etc, but let me
know.

I don't mind going into further details about the preceding project that
has spawned this license scenario, but that could get pretty tangential. It
was work that I was hired to do back in 2018 (and have updated periodically
since then), to do with how font shaping works. Basically, the gap between
the Unicode and Opentype specs, and which HarfBuzz implements. So most of
the writing work was tracing & understanding HarfBuzz's logic and
translating that into documentary form. The company that hired me to do
that then used the doc to develop their own free-software shaping engine.

I would be most interested in anyone's analysis about the license and how
it would interact with other free-software elements in the ecosystem at
large, as well as whether they think it reads clearly, says what it intends
to, and is reasonable.

It might be a bridge too far to ask whether it sounds like something that
another standards/specification effort could use, but I did try to be
general when writing it, in the hopes of it being useful in the future (and
applying it to another effort as a thought experiment might prove
informative).

But any reaction or feedback at all would be welcome (although "you
shouldn't write a license / you must have done your research wrong" is not
likely to make it high on the list of comments that warrant a reply I
also found it surprising that there were not good off-the-shelf options,
but here we are).

Thanks,
Nate

PS - I also know that the functional-spec case is not universal; other
standards might care a LOT about interoperability, but it wasn't in scope
here and adds, potentially, a lot of machinery, from compliance to testing
to certification, and that was neither required nor doable, so not
desirable.
-- 
nathan.p.willis
nwil...@glyphography.com 

Re: Compatibility of LGPL-3+ and LGPL-2.1 in same library.

[Andreas Metzler]

On 2024-06-06 Arun Kumar Pariyar  wrote:
> Dear Legal Team,

> Can LGPL-3+ and LGPL-2.1 licensed code be used together in the same
> library, or is re-licensing required?
> Your guidance on their compatibility would be greatly appreciated.

Hello,

AFAIK, please doublecheck:

LGPL 2.1 (3) allows relicensing under GPL-2+, so the combined work would
effectively be GPL-3+.

cu Andreas

Re: Compatibility of LGPL-3+ and LGPL-2.1 in same library.

[Soren Stoutner]

According to the GNU compatibility matrix

https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility[1]

the answer is that, without permission from the original copyright owners, you 
can 
combine the code if you re-license the combination as either GPLv3 or GPLv3+.  
If you want 
the combined code to be LGPLv3+, you would need the permission of the copyright 
holders 
of the LGPLv2.1 to re-license it.  (This is described in the top part of the 
chart in the link 
above.)

Note that this answer is specific to the situation of mixing code that is 
LGPLv3+ and 
LGPLv2.1 in the same library.  In the different scenario of having one library 
that is LGPLv2.1 
and another that is LGPLv3+ in the same project, you can mix them without any 
issues or 
the need to re-license any code.  (This is described in the bottom of the chart 
in the link 
above.)

On Thursday, June 6, 2024 6:53:32 AM MST Arun Kumar Pariyar wrote:
> Dear Legal Team,
> 
> Can LGPL-3+ and LGPL-2.1 licensed code be used together in the same library,
> or is re-licensing required?
> Your guidance on their compatibility would be
> greatly appreciated.
> 
> Regards,
> ~ Arun Kumar Pariyar
> 

-- 
Soren Stoutner
so...@debian.org


[1] https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility


signature.asc
Description: This is a digitally signed message part.

Compatibility of LGPL-3+ and LGPL-2.1 in same library.

[Arun Kumar Pariyar]

Dear Legal Team,

Can LGPL-3+ and LGPL-2.1 licensed code be used together in the same library, or 
is re-licensing required?
Your guidance on their compatibility would be greatly appreciated.

Regards,
~ Arun Kumar Pariyar



OpenPGP_0x4B542AF704F74516.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Updating the PHP license

[Ben Ramsey]

> On May 25, 2024, at 10:03, Francesco Poli  wrote:
> 
> Some minor nitpicks (once again, by a non-native speaker, so they could
> be wrong...): it's not the PHP License, version 4.0, which adopts the
> 3-clause BSD license; it's the PHP Group which adopts the 3-clause BSD
> license as the new version (4.0) of the PHP License.


I think it could be worded either way in English and still make sense, but I’ve 
made the changes to make clear your distinction that it’s not the documents 
themselves adopting the BSD 3-Clause License but the organizations who maintain 
the documents. :-)

Cheers,
Ben




signature.asc
Description: Message signed with OpenPGP

Re: Updating the PHP license

[Francesco Poli]

On Fri, 24 May 2024 00:11:39 -0500 Ben Ramsey wrote:

> > On May 23, 2024, at 13:40, Francesco Poli  wrote:
> > 
> > On Wed, 22 May 2024 23:13:13 -0500 Ben Ramsey wrote:
> > 
> > [...]
> >> I’ve updated the RFC according to your suggestions.
> > 
> > Good!   :-)
> > Thanks for taking the time to do so.
> > 
> >> You may find a diff of the changes here:
> >> 
> >> https://wiki.php.net/rfc/php_license_update?do=diff%5B0%5D=1716433712%5B1%5D=1716437291=sidebyside
> >>  
> >> 
> >> Please let me know if you have any feedback on these changes.
> > 
> > After a short review, they look OK to me.
> > 
> > The only thing that I would emphasize more is: the PHP License, version
> > 4.0 should not just have the text identical to the 3-clause BSD
> > license, it should *be* the 3-clause BSD license. In other words, the
> > PHP Group would not merely publish a new license with a text identical
> > to the text of another license: the PHP Group would *designate*[^NOTE]
> > the 3-clause BSD license as the new version of the PHP License (i.e.:
> > version 4.0).
> > 
> > [^NOTE]: or *elect*, or *adopt*, the most suitable word should be
> >chosen by an English native speaker (which I am not) with legal
> >training (which I do not have)...
> > 
> > I think that, this way, clause 5 of the PHP License, version 3.01,
> > would be triggered, but there would be no need to explicitly mention
> > "PHP License, version 4.0" in the source code of a project that decides
> > to upgrade its license (from PHP License, version 3.01 to its
> > successor, the 3-clause BSD license).
> > The reason would that "PHP License, version 4.0" would become an alias
> > of "3-clause BSD license"...
> > 
> > Similarly for the Zend License, of course.
> > 
> > This is how I see it, but, clearly, it has to be checked with someone
> > more knowledgeable than me about the legal aspects.
> 
> 
> Again, great suggestions, Francesco. Many thanks!

You are welcome!  :-)

> 
> I’ve made a few small changes that make it clear that the PHP License, 
> version 4, and Zend Engine License, version 3, both adopt the 3-clause BSD 
> License.
> 
> Changes here: 
> https://wiki.php.net/rfc/php_license_update?do=diff%5B0%5D=1716438337%5B1%5D=1716527050=sidebyside

Yeah, I think this is an improvement.


Some minor nitpicks (once again, by a non-native speaker, so they could
be wrong...): it's not the PHP License, version 4.0, which adopts the
3-clause BSD license; it's the PHP Group which adopts the 3-clause BSD
license as the new version (4.0) of the PHP License.
If you agree with this reasoning, then I would change the following
sentences:

- This proposal addresses a longstanding issue within the open source
- community by publishing new versions of the PHP License and the Zend
- Engine License. The PHP License, version 4, and Zend Engine License,
- version 3, will adopt the BSD 3-Clause License.

into:

+ This proposal addresses a longstanding issue within the open source
+ community by publishing new versions of the PHP License and the Zend
+ Engine License. The BSD 3-Clause License is adopted as The PHP
+ License, version 4, and as The Zend Engine License, version 3.

and:

- Publish the PHP License, version 4, and Zend Engine License, version
- 3, both adopting the BSD 3-Clause License, and deprecate the PHP
- License and Zend Engine License, as proposed in the Proposal section?

into:

+ Publish the PHP License, version 4, and Zend Engine License, version
+ 3, by adopting the BSD 3-Clause License as the new version of both,
+ and deprecate the PHP License and Zend Engine License, as proposed in
+ the Proposal section?


I hope this helps.
Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpUWfjS4_WeA.pgp
Description: PGP signature

Re: Updating the PHP license

[Ben Ramsey]

> On May 23, 2024, at 13:40, Francesco Poli  wrote:
> 
> On Wed, 22 May 2024 23:13:13 -0500 Ben Ramsey wrote:
> 
> [...]
>> I’ve updated the RFC according to your suggestions.
> 
> Good!   :-)
> Thanks for taking the time to do so.
> 
>> You may find a diff of the changes here:
>> 
>> https://wiki.php.net/rfc/php_license_update?do=diff%5B0%5D=1716433712%5B1%5D=1716437291=sidebyside
>>  
>> 
>> Please let me know if you have any feedback on these changes.
> 
> After a short review, they look OK to me.
> 
> The only thing that I would emphasize more is: the PHP License, version
> 4.0 should not just have the text identical to the 3-clause BSD
> license, it should *be* the 3-clause BSD license. In other words, the
> PHP Group would not merely publish a new license with a text identical
> to the text of another license: the PHP Group would *designate*[^NOTE]
> the 3-clause BSD license as the new version of the PHP License (i.e.:
> version 4.0).
> 
> [^NOTE]: or *elect*, or *adopt*, the most suitable word should be
>chosen by an English native speaker (which I am not) with legal
>training (which I do not have)...
> 
> I think that, this way, clause 5 of the PHP License, version 3.01,
> would be triggered, but there would be no need to explicitly mention
> "PHP License, version 4.0" in the source code of a project that decides
> to upgrade its license (from PHP License, version 3.01 to its
> successor, the 3-clause BSD license).
> The reason would that "PHP License, version 4.0" would become an alias
> of "3-clause BSD license"...
> 
> Similarly for the Zend License, of course.
> 
> This is how I see it, but, clearly, it has to be checked with someone
> more knowledgeable than me about the legal aspects.


Again, great suggestions, Francesco. Many thanks!

I’ve made a few small changes that make it clear that the PHP License, version 
4, and Zend Engine License, version 3, both adopt the 3-clause BSD License.

Changes here: 
https://wiki.php.net/rfc/php_license_update?do=diff%5B0%5D=1716438337%5B1%5D=1716527050=sidebyside

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP

Re: Updating the PHP license

[Francesco Poli]

On Wed, 22 May 2024 23:13:13 -0500 Ben Ramsey wrote:

[...]
> I’ve updated the RFC according to your suggestions.

Good!   :-)
Thanks for taking the time to do so.

> You may find a diff of the changes here:
> 
> https://wiki.php.net/rfc/php_license_update?do=diff%5B0%5D=1716433712%5B1%5D=1716437291=sidebyside
>  
> 
> Please let me know if you have any feedback on these changes.

After a short review, they look OK to me.

The only thing that I would emphasize more is: the PHP License, version
4.0 should not just have the text identical to the 3-clause BSD
license, it should *be* the 3-clause BSD license. In other words, the
PHP Group would not merely publish a new license with a text identical
to the text of another license: the PHP Group would *designate*[^NOTE]
the 3-clause BSD license as the new version of the PHP License (i.e.:
version 4.0).

[^NOTE]: or *elect*, or *adopt*, the most suitable word should be
chosen by an English native speaker (which I am not) with legal
training (which I do not have)...

I think that, this way, clause 5 of the PHP License, version 3.01,
would be triggered, but there would be no need to explicitly mention
"PHP License, version 4.0" in the source code of a project that decides
to upgrade its license (from PHP License, version 3.01 to its
successor, the 3-clause BSD license).
The reason would that "PHP License, version 4.0" would become an alias
of "3-clause BSD license"...

Similarly for the Zend License, of course.

This is how I see it, but, clearly, it has to be checked with someone
more knowledgeable than me about the legal aspects.


Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2YhtpMKSg8.pgp
Description: PGP signature

Re: Updating the PHP license

[Ben Ramsey]

> On May 21, 2024, at 19:58, Ben Ramsey  wrote:
> 
> This is something that didn’t cross my mind while I was putting together the 
> RFC, so I’m glad I posted to this list.
> 
> Thank you for the suggestions! I’ll update the RFC and will reply here when 
> I’ve made the changes.


I’ve updated the RFC according to your suggestions. You may find a diff of the 
changes here:

https://wiki.php.net/rfc/php_license_update?do=diff%5B0%5D=1716433712%5B1%5D=1716437291=sidebyside
 

Please let me know if you have any feedback on these changes.

Cheers,
Ben






signature.asc
Description: Message signed with OpenPGP

Re: Updating the PHP license

[Ben Ramsey]

> On May 21, 2024, at 16:32, Francesco Poli  wrote:
> 
> On Sun, 19 May 2024 14:53:48 -0500 Ben Ramsey wrote:
> 
>> On May 19, 2024, at 11:42, Francesco Poli  wrote:
> [...]
>>> If the PHP Group decides to elect the 3-clause BSD license as the next
>>> version (4.0) of the PHP License, then clause 5 of the PHP License version
>>> 3.01 will kick in and any piece of software currently licensed under
>>> the terms of the PHP License version 3.01 will *instantly* be also
>>> available under the terms of the 3-clause BSD license, at the
>>> recipient's choice.
>>> 
>>> A similar reasoning should hold for the Zend Engine License, as well…
>> 
>> I want to be clear that this RFC does not exert any control over other
>> projects that use the PHP License.
> 
> I would not call it "control".
> 
> Nobody will be forced to stop copying/modifying/redistributing other
> projects under the terms of the PHP License version 3.01 .
> 
> It's just a license-upgrade clause that can be triggered by the license
> steward, which decides to publish a new version of the license.
> 
> People who released their own projects under the terms of the PHP
> License version 3.01 were (or should have been...) aware of the
> existence of that license-upgrade clause: they decided to trust the PHP
> Group as license steward.
> They should not be surprised, if, at some point in time, that
> license-upgrade clause is actually triggered.
> 
> [...]
>> One of my goals with the RFC is to get rid of the idea of a “PHP License,”
> 
> I agree with this goal.
> 
>> so it deprecates the PHP License and *replaces* it with the
>> BSD 3-Clause License. I don’t want there to be a “PHP License,
>> version 4.0.” I think that will continue to cause confusion
>> in the community.
> 
> If the PHP Group decides to adopt the 3-clause BSD license as the new
> PHP License, version 4.0, there will be no obligation, I think, to
> mention the term "PHP License, version 4.0" in each PHP source code
> file.
> It will be possible to mention the 3-clause BSD license in each source
> file and to state that PHP will be released under the terms of the
> 3-clause BSD license.
> 
> At the same time, somewhere on the php.net website, there will be a
> page that explicitly says that the PHP Group has adopted the 3-clause
> BSD license as the PHP License, version 4.0.


After thinking this over, I like your suggestions and approach. I’ll start 
working on updating the relevant sections of the RFC to call attention to this 
and to also mention this as the “PHP License, version 4.0,” even if we don’t 
put that name in any of the source files, etc.


>> Is there a reading of clause 5 (specifically “You may also choose
>> to use such covered code under the terms of any subsequent version
>> of the license published by the PHP Group.”) that would allow
>> projects using the PHP License to switch to the BSD 3-Clause License,
>> even if a subsequent version 4.0 of the PHP License is not published?
> 
> First off, and I should have stated this more explicitly from the
> beginning, IANAL, TINLA.


Understood. :-)


> That being said, I personally don't see how the license-upgrade clause
> could be triggered, without actually publishing a new version of the
> license.


This is how I understand it, as well.


> AFAICT, the strategy to "adopt" the 3-clause BSD license as the new
> version 4.0 of the PHP License would trigger the license-upgrade
> clause, while at the same time deprecating the use of the PHP License.
> The web page on the php.net website could even explicitly say that the
> PHP License is now deprecated and that the PHP Group has designated the
> 3-clause BSD license as its successor (PHP License, version 4.0).


+1. I like this approach.


> In addition, triggering the license-upgrade mechanism would make it
> much clearer that there's no need to ask for permission to all the
> external contributors and that the license change can be performed just
> with a vote within the PHP Group.


I think this was my biggest concern: I didn’t want to advise others that they 
could update their licenses, only to piss off a bunch of contributors, but if 
we adopt the 3-clause BSD as the next version of the PHP License, then I agree 
with you that it would trigger the license-upgrade mechanism and allow other 
projects to seamlessly upgrade the license, which doesn’t affect any of the 
terms or rights their contributors granted anyway.

This is something that didn’t cross my mind while I was putting together the 
RFC, so I’m glad I posted to this list.

Thank you for the suggestions! I’ll update the RFC and will reply here when 
I’ve made the changes.


> To a layman like me, the reasoning that no contributors, other than
> representatives of the PHP Group, are able to grant or assert clauses
> 4, 5, and 6, looks convincing. But I don't know whether it would
> actually hold water in a court.
> So, maybe, it's better, if the license-upgrade mechanism is also
> triggered.
> 
> Or at least, 

Re: Updating the PHP license

[Ben Ramsey]

> On May 21, 2024, at 11:49, Richard Laager  wrote:
> 
> On 2024-05-19 14:53, Ben Ramsey wrote:
>> One of my goals with the RFC is to get rid of the idea of a “PHP License,” 
>> so it deprecates the PHP License and *replaces* it with the BSD 3-Clause 
>> License. I don’t want there to be a “PHP License, version 4.0.” I think that 
>> will continue to cause confusion in the community.
> 
> You (the copyright holders) could do both. That is, the PHP 4.0 license would 
> be the same wording (other than the name) as BSD 3-Clause. That way, you 
> trigger the "any subsequent version" clause, but then you also subsequently 
> relicense PHP itself under BSD 3-Clause directly. This would indicate a clear 
> intention that the PHP License is deprecated, while still getting the "any 
> subsequent version" benefits for existing software.
> 
> Of course, this assumes that you WANT to trigger that option for third-party 
> projects, which you may or may not. (I think you should want that, but it's 
> not my code, so my opinion doesn't really matter.)


Honestly, I hadn’t considered this option before mailing this list, so I’m glad 
I mailed this list. :-)

After thinking it over, I do think we want to trigger this option for 
third-party projects, so that they have a clear path to upgrade the BSD 
3-Clause license.

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP

Re: Updating the PHP license

[Francesco Poli]

On Sun, 19 May 2024 14:53:48 -0500 Ben Ramsey wrote:

> On May 19, 2024, at 11:42, Francesco Poli  wrote:
[...]
> > If the PHP Group decides to elect the 3-clause BSD license as the next
> > version (4.0) of the PHP License, then clause 5 of the PHP License version
> > 3.01 will kick in and any piece of software currently licensed under
> > the terms of the PHP License version 3.01 will *instantly* be also
> > available under the terms of the 3-clause BSD license, at the
> > recipient's choice.
> > 
> > A similar reasoning should hold for the Zend Engine License, as well…
> 
> I want to be clear that this RFC does not exert any control over other
> projects that use the PHP License.

I would not call it "control".

Nobody will be forced to stop copying/modifying/redistributing other
projects under the terms of the PHP License version 3.01 .

It's just a license-upgrade clause that can be triggered by the license
steward, which decides to publish a new version of the license.

People who released their own projects under the terms of the PHP
License version 3.01 were (or should have been...) aware of the
existence of that license-upgrade clause: they decided to trust the PHP
Group as license steward.
They should not be surprised, if, at some point in time, that
license-upgrade clause is actually triggered.

[...]
> One of my goals with the RFC is to get rid of the idea of a “PHP License,”

I agree with this goal.

> so it deprecates the PHP License and *replaces* it with the
> BSD 3-Clause License. I don’t want there to be a “PHP License,
> version 4.0.” I think that will continue to cause confusion
> in the community.

If the PHP Group decides to adopt the 3-clause BSD license as the new
PHP License, version 4.0, there will be no obligation, I think, to
mention the term "PHP License, version 4.0" in each PHP source code
file.
It will be possible to mention the 3-clause BSD license in each source
file and to state that PHP will be released under the terms of the
3-clause BSD license.

At the same time, somewhere on the php.net website, there will be a
page that explicitly says that the PHP Group has adopted the 3-clause
BSD license as the PHP License, version 4.0.

> 
> Is there a reading of clause 5 (specifically “You may also choose
> to use such covered code under the terms of any subsequent version
> of the license published by the PHP Group.”) that would allow
> projects using the PHP License to switch to the BSD 3-Clause License,
> even if a subsequent version 4.0 of the PHP License is not published?

First off, and I should have stated this more explicitly from the
beginning, IANAL, TINLA.

That being said, I personally don't see how the license-upgrade clause
could be triggered, without actually publishing a new version of the
license.
AFAICT, the strategy to "adopt" the 3-clause BSD license as the new
version 4.0 of the PHP License would trigger the license-upgrade
clause, while at the same time deprecating the use of the PHP License.
The web page on the php.net website could even explicitly say that the
PHP License is now deprecated and that the PHP Group has designated the
3-clause BSD license as its successor (PHP License, version 4.0).

In addition, triggering the license-upgrade mechanism would make it
much clearer that there's no need to ask for permission to all the
external contributors and that the license change can be performed just
with a vote within the PHP Group.

To a layman like me, the reasoning that no contributors, other than
representatives of the PHP Group, are able to grant or assert clauses
4, 5, and 6, looks convincing. But I don't know whether it would
actually hold water in a court.
So, maybe, it's better, if the license-upgrade mechanism is also
triggered.

Or at least, this is how I personally see it.

Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpdDB3FKTMxI.pgp
Description: PGP signature

Re: Updating the PHP license

[Richard Laager]

On 2024-05-19 14:53, Ben Ramsey wrote:

One of my goals with the RFC is to get rid of the idea of a “PHP License,” so 
it deprecates the PHP License and *replaces* it with the BSD 3-Clause License. 
I don’t want there to be a “PHP License, version 4.0.” I think that will 
continue to cause confusion in the community.


You (the copyright holders) could do both. That is, the PHP 4.0 license 
would be the same wording (other than the name) as BSD 3-Clause. That 
way, you trigger the "any subsequent version" clause, but then you also 
subsequently relicense PHP itself under BSD 3-Clause directly. This 
would indicate a clear intention that the PHP License is deprecated, 
while still getting the "any subsequent version" benefits for existing 
software.


Of course, this assumes that you WANT to trigger that option for 
third-party projects, which you may or may not. (I think you should want 
that, but it's not my code, so my opinion doesn't really matter.)



Is there a reading of clause 5 (specifically “You may also choose to use such 
covered code under the terms of any subsequent version of the license published 
by the PHP Group.”) that would allow projects using the PHP License to switch 
to the BSD 3-Clause License, even if a subsequent version 4.0 of the PHP 
License is not published?


IMHO (IANAL, etc.), no.

--
Richard



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Updating the PHP license

[Ben Ramsey]

> On May 19, 2024, at 11:42, Francesco Poli  wrote:
> 
> Here's some feedback about version 0.3 of your RFC.
> 
>> The proposed changes for the PHP software repository will not affect
>> the PHP Manual. The PHP Manual will remain licensed under the Creative
>> Commons Attribution 3.0 License or later.
> 
> How unfortunate!
> Creative Commons licenses are also controversial (although this one,
> CC-by-v3.0, is accepted by the Debian Project, I personally disagree).
> 
> Anyway, the general recommendation is to license the documentation
> under the same legal terms as the documented program or library.
> Hence, I would suggest to also switch the PHP Manual to the 3-clause
> BSD license... this would be absolutely great (although it would
> probably require to seek approval among its copyright holders).

The PHP manual is not distributed with the PHP source code, and it is managed 
by a separate team of volunteers. While related to the PHP source code, it can 
be thought of as a separate project, owned by a separate community. I called 
this out specifically in the RFC to alleviate any concerns that the RFC 
oversteps this invisible boundary by applying itself more broadly.

>> External extensions currently licensed under the PHP License may
>> continue to use the PHP License. There is no need to change extension
>> licenses.
> 
> I don't think so.
> 
> If the PHP Group decides to elect the 3-clause BSD license as the next
> version (4.0) of the PHP License, then clause 5 of the PHP License version
> 3.01 will kick in and any piece of software currently licensed under
> the terms of the PHP License version 3.01 will *instantly* be also
> available under the terms of the 3-clause BSD license, at the
> recipient's choice.
> 
> A similar reasoning should hold for the Zend Engine License, as well…

I want to be clear that this RFC does not exert any control over other projects 
that use the PHP License. This is important. PHP is not one, single unified 
project, despite how it might appear from the outside; it’s a bunch of small, 
independent projects with no single unifying body that can claim control over 
any one of the projects. For this reason, the scope of the RFC is narrow.

One of my goals with the RFC is to get rid of the idea of a “PHP License,” so 
it deprecates the PHP License and *replaces* it with the BSD 3-Clause License. 
I don’t want there to be a “PHP License, version 4.0.” I think that will 
continue to cause confusion in the community.

Is there a reading of clause 5 (specifically “You may also choose to use such 
covered code under the terms of any subsequent version of the license published 
by the PHP Group.”) that would allow projects using the PHP License to switch 
to the BSD 3-Clause License, even if a subsequent version 4.0 of the PHP 
License is not published?

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP

Re: Updating the PHP license

[Francesco Poli]

On Sat, 18 May 2024 15:18:36 -0500 Ben Ramsey wrote:

> Hi, all!

Hello Ben!

> 
> Over the years, the open source community, including Debian, has had
> a few lengthy discussions and disagreements regarding the PHP
> license.[^1][^2][^3] The TL;DR sentiment of all these discussions
> amounts to: change the license to something well-understood and less
> problematic.

Indeed, I have personally voiced my disappointment with the PHP License
for a long time. See, for instance, my [analysis] of the PHP License,
version 3.01, and an additional [comment] about another issue.

[analysis]: 
[comment]: 

And I have also attempted to persuade the PHP Group to switch to a well
known and widely adopted general purpose (DFSG-compliant) license.
I got in touch with the PHP Group back in 2016 and tried to convince
them to switch to the 3-clause BSD license, but my attempt was
unfortunately unsuccessful...

> 
> So, that’s what I’m proposing to do in a new RFC I’ve drafted for the
> PHP project: https://wiki.php.net/rfc/php_license_update 

Given what I said above, you may guess I am really happy about your RFC!
Thanks a lot for drafting it and for stewarding this proposal.

> 
> I’ve not opened this up for discussion within the PHP project yet,
> since I’m still collecting feedback, and that’s why I’m sharing it
> here. I’ve put a lot of work into presenting what I think is a sound
> and well-reasoned argument for this change, and I’m asking for
> feedback from this group regarding the method and theory I’m using to
> go about it.

Here's some feedback about version 0.3 of your RFC.

| The proposed changes for the PHP software repository will not affect
| the PHP Manual. The PHP Manual will remain licensed under the Creative
| Commons Attribution 3.0 License or later.

How unfortunate!
Creative Commons licenses are also controversial (although this one,
CC-by-v3.0, is accepted by the Debian Project, I personally disagree).

Anyway, the general recommendation is to license the documentation
under the same legal terms as the documented program or library.
Hence, I would suggest to also switch the PHP Manual to the 3-clause
BSD license... this would be absolutely great (although it would
probably require to seek approval among its copyright holders).

| External extensions currently licensed under the PHP License may
| continue to use the PHP License. There is no need to change extension
| licenses.

I don't think so.

If the PHP Group decides to elect the 3-clause BSD license as the next
version (4.0) of the PHP License, then clause 5 of the PHP License version
3.01 will kick in and any piece of software currently licensed under
the terms of the PHP License version 3.01 will *instantly* be also
available under the terms of the 3-clause BSD license, at the
recipient's choice.

A similar reasoning should hold for the Zend Engine License, as well...

> 
> Thanks in advance!

You're welcome.
Thanks to you for sharing this draft document!

> 
> Cheers,
> Ben

Bye!   :-)

> 
> 
> [^1]: 
> https://duckduckgo.com/?q=site%3Ahttps%3A%2F%2Flists.debian.org%2Fdebian-legal%2F+php
> [^2]: https://lwn.net/Articles/604630/
> [^3]: https://ftp-master.debian.org/php-license.html
> 


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpiFo3xMP9_N.pgp
Description: PGP signature

Re: Updating the PHP license

[Andrew M.A. Cater]

On Sat, May 18, 2024 at 03:18:36PM -0500, Ben Ramsey wrote:
> Hi, all!
> 
> Over the years, the open source community, including Debian, has had a few 
> lengthy discussions and disagreements regarding the PHP license.[^1][^2][^3] 
> The TL;DR sentiment of all these discussions amounts to: change the license 
> to something well-understood and less problematic.
> 

This seems like a simplification that's long overdue: your methodology
and justification seem eminently sensible: go for it!

[Disclaimer: IANAL, like most others in this group, but would be very
interested in anything that made licensing more understandable or simpler]

> So, that’s what I’m proposing to do in a new RFC I’ve drafted for the PHP 
> project: https://wiki.php.net/rfc/php_license_update 
> 
> I’ve not opened this up for discussion within the PHP project yet, since I’m 
> still collecting feedback, and that’s why I’m sharing it here. I’ve put a lot 
> of work into presenting what I think is a sound and well-reasoned argument 
> for this change, and I’m asking for feedback from this group regarding the 
> method and theory I’m using to go about it.
> 

See above: all looks good.

> Thanks in advance!
> 

Thanks to you for proposing this

> Cheers,
> Ben
> 

All the very best, as ever,

Andy Cater
(amaca...@debian.org)
> 
> [^1]: 
> https://duckduckgo.com/?q=site%3Ahttps%3A%2F%2Flists.debian.org%2Fdebian-legal%2F+php
> [^2]: https://lwn.net/Articles/604630/
> [^3]: https://ftp-master.debian.org/php-license.html
> 

Updating the PHP license

[Ben Ramsey]

Hi, all!

Over the years, the open source community, including Debian, has had a few 
lengthy discussions and disagreements regarding the PHP license.[^1][^2][^3] 
The TL;DR sentiment of all these discussions amounts to: change the license to 
something well-understood and less problematic.

So, that’s what I’m proposing to do in a new RFC I’ve drafted for the PHP 
project: https://wiki.php.net/rfc/php_license_update 

I’ve not opened this up for discussion within the PHP project yet, since I’m 
still collecting feedback, and that’s why I’m sharing it here. I’ve put a lot 
of work into presenting what I think is a sound and well-reasoned argument for 
this change, and I’m asking for feedback from this group regarding the method 
and theory I’m using to go about it.

Thanks in advance!

Cheers,
Ben


[^1]: 
https://duckduckgo.com/?q=site%3Ahttps%3A%2F%2Flists.debian.org%2Fdebian-legal%2F+php
[^2]: https://lwn.net/Articles/604630/
[^3]: https://ftp-master.debian.org/php-license.html



signature.asc
Description: Message signed with OpenPGP

Re: Request for Permission to Use Logo for Merchandise

[Daniel Lange]

Hi Rodrigo,

the samples that you have sent look fine and are inline with the general 
usage permissions as granted by the Debian trademark policy at 
https://www.debian.org/trademark.en.html


Kind regards,
Daniel
for the Debian treasurers


Am 10.05.24 um 09:02 schrieb Rodrigo Vega Cruz:

Hello!

As I have been talking to your colleague Walter Landry, I would like to 
include the Debian logo in a series of articles related to Linux and 
various distributions, including yours.


Therefore, I would like to know what procedure and requirements there 
are to obtain permission from the brand to do so.


These are some designs so you can see the direction we would like to take:

image.png
image.png
image.png
image.png

We would like to make more designs, show them to our community and let 
them decide the ones they like the most.


Please let me know your thoughts and the steps to follow in order to get 
the right permissions to do such.


Thank you very much.

Best Regards,

Rodrigo.

PD: I also attach previous messages of my conversation with Walter so 
you get the full context:


El dom, 5 may 2024 a las 23:42, Walter Landry (>) escribió:


Rodrigo Vega Cruz mailto:rodriveg...@gmail.com>> writes:
 > Dear Debian Team,
 > I hope this message finds you well. My name is Rodrigo, and I am
writing to seek your permission to use the Debian logo on a
 > series of themed merchandise, specifically t-shirts. These
products are intended for sale and will feature both your iconic
 > logo and related community memes.
 >
 > Our goal is to celebrate and promote Debian within the community
through these t-shirts. We believe that this merchandise
 > will not only raise awareness of your distribution but also
foster a stronger connection among its users and enthusiasts.
 >
 > I would like to assure you that these products are intended for
commercial purposes, and we plan to conduct this initiative
 > with the utmost respect for your brand and its values.
Additionally, should this venture generate significant profits, we are
 > committed to contributing a portion of these earnings back to
your project to support and further its development.
 >
 > Please let me know the steps we need to follow to obtain your
permission, or if there are any specific conditions or licensing
 > agreements required for using the logo in this manner.
 >
 > Thank you for considering our request. I look forward to your
positive response and hopefully collaborating closely to make
 > this project beneficial for both parties.
 >
 > Best regards,
 >
 > Rodrigo Vega Cruz
 > Instagram: @danklinuxmemes

The policy on logo use is spelled out here.

https://www.debian.org/logos/ 

Hope that helps,
Walter Landry


El vie, 10 may 2024 a las 8:03, Walter Landry (>) escribió:


Rodrigo Vega Cruz mailto:rodriveg...@gmail.com>> writes:
 > Hi!
 >
 > So, just to make it clear and clarify that I have understood
 > correctly, I just have to include in my webpage Legal/Terms of
Service
 > that the products using the Debian logo follow the CC BY-SA 3.0 DEED
 > Attribution-ShareAlike 3.0 Unported, right?

According to

https://www.debian.org/trademark 

it looks like you can get a definitive answer by emailing

tradem...@debian.org 

Cheers,
Walter Landry

Re: Request for Permission to Use Logo for Merchandise

[Walter Landry]

Rodrigo Vega Cruz  writes:
> Hi!
>
> So, just to make it clear and clarify that I have understood
> correctly, I just have to include in my webpage Legal/Terms of Service
> that the products using the Debian logo follow the CC BY-SA 3.0 DEED
> Attribution-ShareAlike 3.0 Unported, right?

According to

  https://www.debian.org/trademark

it looks like you can get a definitive answer by emailing

  tradem...@debian.org

Cheers,
Walter Landry

Re: Request for Permission to Use Logo for Merchandise

[Rodrigo Vega Cruz]

Hi!

So, just to make it clear and clarify that I have understood correctly, I
just have to include in my webpage Legal/Terms of Service that the products
using the Debian logo follow the *CC BY-SA 3.0 DEED Attribution-ShareAlike
3.0 Unported*, right?

Thanks in advance,

BR,

Rodrigo.

El dom, 5 may 2024 a las 23:42, Walter Landry ()
escribió:

> Rodrigo Vega Cruz  writes:
> > Dear Debian Team,
> > I hope this message finds you well. My name is Rodrigo, and I am writing
> to seek your permission to use the Debian logo on a
> > series of themed merchandise, specifically t-shirts. These products are
> intended for sale and will feature both your iconic
> > logo and related community memes.
> >
> > Our goal is to celebrate and promote Debian within the community through
> these t-shirts. We believe that this merchandise
> > will not only raise awareness of your distribution but also foster a
> stronger connection among its users and enthusiasts.
> >
> > I would like to assure you that these products are intended for
> commercial purposes, and we plan to conduct this initiative
> > with the utmost respect for your brand and its values. Additionally,
> should this venture generate significant profits, we are
> > committed to contributing a portion of these earnings back to your
> project to support and further its development.
> >
> > Please let me know the steps we need to follow to obtain your
> permission, or if there are any specific conditions or licensing
> > agreements required for using the logo in this manner.
> >
> > Thank you for considering our request. I look forward to your positive
> response and hopefully collaborating closely to make
> > this project beneficial for both parties.
> >
> > Best regards,
> >
> > Rodrigo Vega Cruz
> > Instagram: @danklinuxmemes
>
> The policy on logo use is spelled out here.
>
>   https://www.debian.org/logos/
>
> Hope that helps,
> Walter Landry
>

Re: Re: LGPLv2+ depending on (LGPLv3+ or GPLv2+)

[Con Trung Nhỏ]

Hữu 

Re: Request for Permission to Use Logo for Merchandise

[Walter Landry]

Rodrigo Vega Cruz  writes:
> Dear Debian Team,
> I hope this message finds you well. My name is Rodrigo, and I am writing to 
> seek your permission to use the Debian logo on a
> series of themed merchandise, specifically t-shirts. These products are 
> intended for sale and will feature both your iconic
> logo and related community memes.
>
> Our goal is to celebrate and promote Debian within the community through 
> these t-shirts. We believe that this merchandise
> will not only raise awareness of your distribution but also foster a stronger 
> connection among its users and enthusiasts.
>
> I would like to assure you that these products are intended for commercial 
> purposes, and we plan to conduct this initiative
> with the utmost respect for your brand and its values. Additionally, should 
> this venture generate significant profits, we are
> committed to contributing a portion of these earnings back to your project to 
> support and further its development.
>
> Please let me know the steps we need to follow to obtain your permission, or 
> if there are any specific conditions or licensing
> agreements required for using the logo in this manner.
>
> Thank you for considering our request. I look forward to your positive 
> response and hopefully collaborating closely to make
> this project beneficial for both parties.
>
> Best regards,
>
> Rodrigo Vega Cruz
> Instagram: @danklinuxmemes

The policy on logo use is spelled out here.

  https://www.debian.org/logos/

Hope that helps,
Walter Landry

Request for Permission to Use Logo for Merchandise

[Rodrigo Vega Cruz]

Dear Debian Team,
I hope this message finds you well. My name is Rodrigo, and I am writing to
seek your permission to use the Debian logo on a series of themed
merchandise, specifically t-shirts. These products are intended for sale
and will feature both your iconic logo and related community memes.

Our goal is to celebrate and promote Debian within the community through
these t-shirts. We believe that this merchandise will not only raise
awareness of your distribution but also foster a stronger connection among
its users and enthusiasts.

I would like to assure you that these products are intended for commercial
purposes, and we plan to conduct this initiative with the utmost respect
for your brand and its values. Additionally, should this venture generate
significant profits, we are committed to contributing a portion of these
earnings back to your project to support and further its development.

Please let me know the steps we need to follow to obtain your permission,
or if there are any specific conditions or licensing agreements required
for using the logo in this manner.

Thank you for considering our request. I look forward to your positive
response and hopefully collaborating closely to make this project
beneficial for both parties.

Best regards,

Rodrigo Vega Cruz
Instagram: @danklinuxmemes

Re: Missing copyright clause of debian directory

[Xiyue Deng]

Soren Stoutner  writes:

> "that’s the beauty of using GPLv2+ instead of GPLv2: it can be converted to 
> later versions 
> *WITHOUT* any additional permission from the copyright holders”
>
> That was an egregious enough typo that I felt compelled to send another 
> email.  I 
> apologize for the noise.

Thanks very much Soren for the detailed explanations!  And your
suggestions match what Richard suggested as well!

I think in this case I'll keep the debian/* under GPL-2+ for now, as in
our team we are not recommended to be added to copyright holders with
incremental improvements until we have done a more substantial
contribution.  But I'll keep in mind the possibility to upgrade GPL-2+
to GPL-3+ given their compatibility.

Thanks again to you and Richard both!

>
> On Friday, April 12, 2024 12:48:20 PM MST Soren Stoutner wrote:
>> As an additional followup, as the original debian/* files were licensed
>> GPLv2+, if you edit a file you can choose to make your contribution GPLv3+,
>> which would convert the entire file to GPLv3+.  If you end up editing all of
>> the files in debian/* at least once, you could convert the entire copyright
>> entry to GPLv3+.
>> 
>> I can’t do that with Electrum because there is no automatic conversion from
>> GPLv3+ to Expat.  But it is an option that is open to you if you would like 
>> to
>> pursue it.  It also isn’t a problem if you decide to leave all your
>> contributions to debian/* as GPLv2+, as any GPLv2+ file can be contributed to
>> an upstream GPLv3+ project (that’s the beauty of using GPLv2+ instead of
>> GPLv2: it can be converted to later versions with any additional permission
>> from the copyright holders).
>> 
>> On Friday, April 12, 2024 12:40:55 PM MST Soren Stoutner wrote:
>> > As an additional comment, I currently maintain Electrum.  Upstream is
>> 
>> licensed
>> 
>> > Expat. Previous maintainers licensed their debian/* contributions GPLv3+.
>> > When I took over the package, I started working closely with upstream and
>> > wanted to contribute patches and other files, like AppSream metainfo to
>> > them.
>> > 
>> > To do this, I wanted all of my new contributions to debian/* to be licensed
>> > under Expat when I was the sole author of the file, and dual licensed under
>> > GPLv3+ and Expat when I was editing an existing file.  I indicated that in
>> > the following way:
>> > 
>> > Files: debian/*
>> > Copyright: 2013-2015 Vasudev Kamath 
>> > 
>> >2013 Gregor Herrmann 
>> >2013-2021 Tristan Seligmann 
>> >2019-2020 Laurent Bigonville 
>> >2022 Bastian Germann 
>> >2022-2024 Soren Stoutner 
>> > 
>> > License:   GPL-3+
>> > 
>> > Comment:
>> >  The following copyright holders additionally license their
>> >  contributions to debian/* under the Expat license so that
>> >  if all other listed contributors agree it can be relicensed
>> >  under Expat, which is the license used by upstream and makes it
>> >  easier for contributions to be upstreamed when appropriate:
>> >  Soren Stoutner, Bastian Germann.
>> > 
>> > Files: debian/electrum.1
>> > Copyright: 2023-2024 Soren Stoutner 
>> > License:   Expat
>> > 

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Re: Missing copyright clause of debian directory

[Xiyue Deng]

Richard Laager  writes:

> I've only looked at this situation for a total of five minutes prior
> to writing this email, so take this with a grain of salt. But to help
> you make forward progress...
>
> Upstream seems to use GPL-3+ (not GPL-3). For example:
> https://github.com/fxbois/web-mode/blob/a9d21841224da3295f2dd0a90022f5e435e48046/web-mode.el#L13
>
> The existing copyright says GPL-2+ (not GPL-2).
>

Ack.  I should have used the more precise terms.

> On 2024-04-10 23:05, Xiyue Deng wrote:
>> 1. whether I can add the new copyright section to cover debian/*, and
>
> I think it is pretty typical to have a debian/* section. And if the
> licenses differ (see below), then you would _have_ to have separate
> sections.
>
>> 2. whether I should use GPL-2 as when the previous maintainer last
>> worked on this or I can use GPL-3 to match upstream version as well?
>
> If that is what you believe applies to the debian files (which is what
> debian/copyright says today), then I would keep it as that. GPL-2+ is,
> of course, compatible with GPL-3+.
>
> So I think you end up with something like this:
>
> Files: *
> License: GPL-3+
> Copyright: fill in the upstream copyright holders
>
> Files: debian/*
> License: GPL-2+
> Copyright: previous maintainer, you

Thanks for the suggestions Richard!

-- 
Xiyue Deng


signature.asc
Description: PGP signature

Re: Missing copyright clause of debian directory

[Soren Stoutner]

"that’s the beauty of using GPLv2+ instead of GPLv2: it can be converted to 
later versions 
*WITHOUT* any additional permission from the copyright holders”

That was an egregious enough typo that I felt compelled to send another email.  
I 
apologize for the noise.

On Friday, April 12, 2024 12:48:20 PM MST Soren Stoutner wrote:
> As an additional followup, as the original debian/* files were licensed
> GPLv2+, if you edit a file you can choose to make your contribution GPLv3+,
> which would convert the entire file to GPLv3+.  If you end up editing all of
> the files in debian/* at least once, you could convert the entire copyright
> entry to GPLv3+.
> 
> I can’t do that with Electrum because there is no automatic conversion from
> GPLv3+ to Expat.  But it is an option that is open to you if you would like to
> pursue it.  It also isn’t a problem if you decide to leave all your
> contributions to debian/* as GPLv2+, as any GPLv2+ file can be contributed to
> an upstream GPLv3+ project (that’s the beauty of using GPLv2+ instead of
> GPLv2: it can be converted to later versions with any additional permission
> from the copyright holders).
> 
> On Friday, April 12, 2024 12:40:55 PM MST Soren Stoutner wrote:
> > As an additional comment, I currently maintain Electrum.  Upstream is
> 
> licensed
> 
> > Expat. Previous maintainers licensed their debian/* contributions GPLv3+.
> > When I took over the package, I started working closely with upstream and
> > wanted to contribute patches and other files, like AppSream metainfo to
> > them.
> > 
> > To do this, I wanted all of my new contributions to debian/* to be licensed
> > under Expat when I was the sole author of the file, and dual licensed under
> > GPLv3+ and Expat when I was editing an existing file.  I indicated that in
> > the following way:
> > 
> > Files: debian/*
> > Copyright: 2013-2015 Vasudev Kamath 
> > 
> >2013 Gregor Herrmann 
> >2013-2021 Tristan Seligmann 
> >2019-2020 Laurent Bigonville 
> >2022 Bastian Germann 
> >2022-2024 Soren Stoutner 
> > 
> > License:   GPL-3+
> > 
> > Comment:
> >  The following copyright holders additionally license their
> >  contributions to debian/* under the Expat license so that
> >  if all other listed contributors agree it can be relicensed
> >  under Expat, which is the license used by upstream and makes it
> >  easier for contributions to be upstreamed when appropriate:
> >  Soren Stoutner, Bastian Germann.
> > 
> > Files: debian/electrum.1
> > Copyright: 2023-2024 Soren Stoutner 
> > License:   Expat
> > 

signature.asc
Description: This is a digitally signed message part.

Re: Missing copyright clause of debian directory

[Soren Stoutner]

As an additional followup, as the original debian/* files were licensed GPLv2+, 
if you edit a file you can choose to make your contribution GPLv3+, which would 
convert the entire file to GPLv3+.  If you end up editing all of the files in 
debian/* at least once, you could convert the entire copyright entry to 
GPLv3+.

I can’t do that with Electrum because there is no automatic conversion from 
GPLv3+ to Expat.  But it is an option that is open to you if you would like to 
pursue it.  It also isn’t a problem if you decide to leave all your 
contributions to debian/* as GPLv2+, as any GPLv2+ file can be contributed to 
an upstream GPLv3+ project (that’s the beauty of using GPLv2+ instead of 
GPLv2: it can be converted to later versions with any additional permission 
from the copyright holders).

On Friday, April 12, 2024 12:40:55 PM MST Soren Stoutner wrote:
> As an additional comment, I currently maintain Electrum.  Upstream is 
licensed
> Expat. Previous maintainers licensed their debian/* contributions GPLv3+. 
> When I took over the package, I started working closely with upstream and
> wanted to contribute patches and other files, like AppSream metainfo to them.
> 
> To do this, I wanted all of my new contributions to debian/* to be licensed
> under Expat when I was the sole author of the file, and dual licensed under
> GPLv3+ and Expat when I was editing an existing file.  I indicated that in
> the following way:
> 
> Files: debian/*
> Copyright: 2013-2015 Vasudev Kamath 
>2013 Gregor Herrmann 
>2013-2021 Tristan Seligmann 
>2019-2020 Laurent Bigonville 
>2022 Bastian Germann 
>2022-2024 Soren Stoutner 
> License:   GPL-3+
> Comment:
>  The following copyright holders additionally license their
>  contributions to debian/* under the Expat license so that
>  if all other listed contributors agree it can be relicensed
>  under Expat, which is the license used by upstream and makes it
>  easier for contributions to be upstreamed when appropriate:
>  Soren Stoutner, Bastian Germann.
> 
> Files: debian/electrum.1
> Copyright: 2023-2024 Soren Stoutner 
> License:   Expat
> 
> Files: debian/patches/*
> Copyright: 2022-2024 Soren Stoutner 
> License:   Expat
> 
> Files: debian/patches/Improve-message-about-PyQt5.patch
> Copyright: 2020 Tristan Seligmann 
> License:   GPL-3+
> 
> https://sources.debian.org/src/electrum/4.5.4%2Bdfsg-1/debian/copyright/[1]
> 
> On Friday, April 12, 2024 12:10:43 PM MST Richard Laager wrote:
> > I've only looked at this situation for a total of five minutes prior to
> > writing this email, so take this with a grain of salt. But to help you
> > make forward progress...
> > 
> > Upstream seems to use GPL-3+ (not GPL-3). For example:
> > https://github.com/fxbois/web-mode/blob/
a9d21841224da3295f2dd0a90022f5e435e4
> > 80 46/web-mode.el#L13
> > 
> > The existing copyright says GPL-2+ (not GPL-2).
> > 
> > On 2024-04-10 23:05, Xiyue Deng wrote:
> > > 1. whether I can add the new copyright section to cover debian/*, and
> > 
> > I think it is pretty typical to have a debian/* section. And if the
> > licenses differ (see below), then you would _have_ to have separate
> > sections.


-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: Missing copyright clause of debian directory

[Soren Stoutner]

As an additional comment, I currently maintain Electrum.  Upstream is licensed 
Expat.  
Previous maintainers licensed their debian/* contributions GPLv3+.  When I took 
over the 
package, I started working closely with upstream and wanted to contribute 
patches and 
other files, like AppSream metainfo to them.

To do this, I wanted all of my new contributions to debian/* to be licensed 
under Expat 
when I was the sole author of the file, and dual licensed under GPLv3+ and 
Expat when I 
was editing an existing file.  I indicated that in the following way:

Files: debian/*
Copyright: 2013-2015 Vasudev Kamath 
   2013 Gregor Herrmann 
   2013-2021 Tristan Seligmann 
   2019-2020 Laurent Bigonville 
   2022 Bastian Germann 
   2022-2024 Soren Stoutner 
License:   GPL-3+
Comment:
 The following copyright holders additionally license their
 contributions to debian/* under the Expat license so that
 if all other listed contributors agree it can be relicensed
 under Expat, which is the license used by upstream and makes it
 easier for contributions to be upstreamed when appropriate:
 Soren Stoutner, Bastian Germann.

Files: debian/electrum.1
Copyright: 2023-2024 Soren Stoutner 
License:   Expat

Files: debian/patches/*
Copyright: 2022-2024 Soren Stoutner 
License:   Expat

Files: debian/patches/Improve-message-about-PyQt5.patch
Copyright: 2020 Tristan Seligmann 
License:   GPL-3+

https://sources.debian.org/src/electrum/4.5.4%2Bdfsg-1/debian/copyright/[1]

On Friday, April 12, 2024 12:10:43 PM MST Richard Laager wrote:
> I've only looked at this situation for a total of five minutes prior to 
> writing this email, so take this with a grain of salt. But to help you 
> make forward progress...
> 
> Upstream seems to use GPL-3+ (not GPL-3). For example:
> https://github.com/fxbois/web-mode/blob/a9d21841224da3295f2dd0a90022f5e435e480
> 46/web-mode.el#L13
 
> The existing copyright says GPL-2+ (not GPL-2).
> 
> On 2024-04-10 23:05, Xiyue Deng wrote:
> 
> > 1. whether I can add the new copyright section to cover debian/*, and
> 
> 
> I think it is pretty typical to have a debian/* section. And if the 
> licenses differ (see below), then you would _have_ to have separate 
> sections.
> 

signature.asc
Description: This is a digitally signed message part.

Re: Missing copyright clause of debian directory

[Richard Laager]

I've only looked at this situation for a total of five minutes prior to 
writing this email, so take this with a grain of salt. But to help you 
make forward progress...


Upstream seems to use GPL-3+ (not GPL-3). For example:
https://github.com/fxbois/web-mode/blob/a9d21841224da3295f2dd0a90022f5e435e48046/web-mode.el#L13

The existing copyright says GPL-2+ (not GPL-2).

On 2024-04-10 23:05, Xiyue Deng wrote:

1. whether I can add the new copyright section to cover debian/*, and


I think it is pretty typical to have a debian/* section. And if the 
licenses differ (see below), then you would _have_ to have separate 
sections.



2. whether I should use GPL-2 as when the previous maintainer last
worked on this or I can use GPL-3 to match upstream version as well?


If that is what you believe applies to the debian files (which is what 
debian/copyright says today), then I would keep it as that. GPL-2+ is, 
of course, compatible with GPL-3+.


So I think you end up with something like this:

Files: *
License: GPL-3+
Copyright: fill in the upstream copyright holders

Files: debian/*
License: GPL-2+
Copyright: previous maintainer, you

--
Richard



OpenPGP_signature.asc
Description: OpenPGP digital signature

Missing copyright clause of debian directory

[Xiyue Deng]

Hi,

I start working on adopting web-mode whose previous maintainer Thomas
Koch[1] became MIA (see Bug#1019031).  When working on d/copyright, it
turns out that there was only one copyright section that covered "Files:
*" with upstream copyright owners but no separate section for "debian/*"
(see also the d/copyright of the snapshot of version 17.0.2-1[2]).
After checking the upstream copyright[3], I don't see the previous
maintainer in the list of copyright owners, therefore I believe the
current d/copyright is at mistake by covering the content in debian
directory under "Files: *".

I'd like to change this situation by adding a separate section covering
"File: debian/*" and attribute the copyright to the previous maintainer,
but currently there are some complications I am not sure how to handle.
Upstream changed their license from GPL-2 to GPL-3 in 2022, while the
previous maintainer last worked on this back in 2020, so I believe I am
obliged to update upstream license to GPL-3.  Following suggestions from
my reviewer Nicholas, I'm here to consult debian-legal@l.d.o for
suggestions.  So at high level I currently have 2 questions:

1. whether I can add the new copyright section to cover debian/*, and

2. whether I should use GPL-2 as when the previous maintainer last
worked on this or I can use GPL-3 to match upstream version as well?

Looking forward to any suggestions.  TIA!

-- 
Xiyue Deng

[1] https://qa.debian.org/developer.php?email=thomas%40koch.ro
[2] https://sources.debian.org/src/web-mode/17.0.2-1/debian/copyright/
[3] https://github.com/fxbois/web-mode/blob/master/web-mode.el


signature.asc
Description: PGP signature

Files with unknown license

[Håvard F . Aasen]

Hi,

Currently coinutils [1] is shipping files in
'/usr/share/coin/Data/Samples/', this has been going on for the entire
lifetime of the package, since June 2008. During this time the files has
been assumed to retain the license of the rest of the package, EPL-1.

Upstream has done some changes in which files being shipped in the
tarball, we now have to get them from a separate repository [2]. The
intention was to introduce this as a separate package, by working on this,
the issue with which license the files was under became evident.

Upstream don't know which license the files has, as such, they have left
them unlicensed, the license file has this at it's top:

> The following license terms apply to the Data-Sample build system
> (configure*, Makefile*, etc.).
> 
> Eclipse Public License - v 2.0

Reading Debian policy 2.3 it seems that these files can't even go into
non-free, since they are missing license and copyright notice.

I'm not sure if it would help to have these files in non-free, but it
would be nice to know what our options are regarding the license, or lack
of it.

I have just uploaded a new version of coinutils to experimental where the
files in '/Data/Samples/' is removed. They are used during testing of
several of the coinor packages, so expect some breakage because of this
change.


Regards,
-- 
Håvard

[1] https://tracker.debian.org/pkg/coinutils
[2] https://github.com/coin-or-tools/Data-Sample

Allan Rey Quiban allanrey...@networkingluxurymasterpiece.vom

[Allan Rey Quiban]

Sent from Outlook for Android

Unieważnieniem umów kredytowych CHF

[Kamil Bodak]

Szanowni Państwo,

zwracam się w sprawie możliwości anulowania Państwa zobowiązań finansowych.

Jako kancelaria prawna na co dzień skutecznie zajmujemy się zawieszaniem spłat 
i unieważnieniem kredytów frankowych. Z naszą pomocą Klienci odzyskali łącznie 
blisko 130 000 00 zł. 

Chętnie przeanalizujemy Państwa sytuację i przedstawimy plan działania. Są 
Państwo zainteresowani?


Pozdrawiam
Kamil Bodak

Re: Another 2-clause BSD or a mistake?

[Charles Plessy]

Le Sat, Mar 16, 2024 at 10:40:16PM -0700, Soren Stoutner a écrit :

> License: BSD-custom-2-clause

I would recommend a different abbreviation.  BSD-custom-2-clause may
give the false impression that this is a standard BSD 2-clause license
where the copyright holders are not the regents of the university of
California.  BSD-custom-with-endorsement-restriction for instance will
convey the message much more clearly and will stimulate the reader to
pay attention to the details and consequences of this clause.

Have a nice Sunday,

Charles

Re: Another 2-clause BSD or a mistake?

[Soren Stoutner]

I do not know if this is a variant that has a common name or has been used in 
other places, but if not you would simply give it a custom name and include 
the full text, perhaps with a comment to make it easy for others to 
understand.  For example:

Files: buf.c
Copyright: 2003 Jean-Francois Brousseau 
 2006, 2007, 2008 Niall O'Higgins 
License: BSD-custom-2-clause
Comment:
 The copyright holders reserve all rights.
 They use a custom BSD 2-clause license that has the first and third clauses
 from the standard BSD-3-clause license.

License: BSD-custom-2-clause
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
 .
 1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
 2. The name of the author may not be used to endorse or promote products
derived from this software without specific prior written permission.
 .
 THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
 AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
 THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
 OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
 WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
 ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

On Saturday, March 16, 2024 4:54:25 PM MST David da Silva Polverari wrote:
> Hello,
> 
> In the midst of performing QA work on unworkable [1], I found the buf.c
> file with the following copyright notice on its header:
> 
> -- >8 --
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
> 
> 1. Redistributions of source code must retain the above copyright
>notice, this list of conditions and the following disclaimer.
> 2. The name of the author may not be used to endorse or promote products
>derived from this software without specific prior written permission.
> -- >8 --
> 
> This is not the BSD 2-clause variant, as it includes the non-endorsement
> clause from the 3-clause one, and excludes the actual second clause.
> Does anyone know if that is actually a BSD variant, and if so, what its
> name is? If it is not a BSD variant, how should it be dealt with/named?
> 
> [1] https://tracker.debian.org/pkg/unworkable
> 
> Regards,
> 
> David


-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Another 2-clause BSD or a mistake?

[David da Silva Polverari]

Hello,

In the midst of performing QA work on unworkable [1], I found the buf.c
file with the following copyright notice on its header:

-- >8 --
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.
2. The name of the author may not be used to endorse or promote products
   derived from this software without specific prior written permission.
-- >8 --

This is not the BSD 2-clause variant, as it includes the non-endorsement
clause from the 3-clause one, and excludes the actual second clause.
Does anyone know if that is actually a BSD variant, and if so, what its
name is? If it is not a BSD variant, how should it be dealt with/named?

[1] https://tracker.debian.org/pkg/unworkable

Regards,

David

Re: TrueType/OpenType and anti-circumvention laws

[Florian Weimer]

* Walter Landry:

> Paul Wise  writes:
>> On Fri, 2024-02-02 at 20:16 -0500, P. J. McDermott wrote:
>>> Ping?  Any thoughts on whether a font DRM modification tool would be
>>> legal to distribute and use in Debian given that the DRM is a simple bit
>>> field rather than an "effective" TPM such as scrambling or encryption?
>>
>> Probably best to consult a lawyer there, but ISTR even trivial things
>> are supposed to count under the DMCA.
>
> This feels similar to pdf viewers that do not honor DRM bits like 'do
> not print', which Debian distributes.  Here is an old email exchange.
>
>   https://lists.debian.org/debian-legal/2005/03/msg00308.html
>
> and a bug ticket that implemented DRM stripping.
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298584

There's also SCMS, which is technically similar (just two bits).
Reputable vendors sell devices which manipulate these bits.  For
example, the Behringer Ultramatch Pro SRC2496 manual says, “Allows
direct manipulation of emphasis and copy-protection bits” (although
they also say that, “We want to point out that the copyright of third
parties must not be infringed—despite the possibility of removing the
copy protect bit with the help of the ULTRAMATCH PRO! This device was
not developed to produce unauthorized copies”).

This is more similar to the ttfpatch case because it allows other
devices to operate in a way contrary to their design.

Discover innovative educational tools.

[Edric Croke]

Hi,

We support curriculum creators, scientific equipment providers, and textbook 
publishers in delivering innovative and effective educational tools.

With over 92 years of experience in creating educational products for students 
and teachers, our presence in international markets allows us to share our 
expertise from the perspective of various needs and challenges.

Our solutions enrich the teaching process of STEM subjects, increase student 
engagement, and improve learning outcomes.

We offer a wide range of products, starting from laboratory equipment (biology, 
chemistry, physics) for all educational levels, to biological specimens (live 
and preserved organisms), anatomical models, laboratory chemicals, scientific 
equipment, and ready-made sets for working with students in lessons.

Our curriculum programs tailored for elementary schools, middle schools, and 
higher education institutions provide support on multiple fronts, allowing for 
utilization in various educational environments, including remote learning.

Could I present how our products can contribute to the development of your 
company?


Best regards
Edric Croke

Re: Re: "freenginx" open source package and "nginx" from F5 open source, potential conflict?

[Thomas Ward]

Canonical has lawyers, but as this would not be a Canonical issue as they would 
sync from Debian, I raised the question here first.

It seems that overall consensus is I should let this sit and see what happens 
in the future with regards to whether F5 brings litigation or such against 
freenginx or such.

I'll keep watch on this and see what chaos is coming.

Thanks for the opinions, though.  I have my own lawyers I can ask but I don't 
want to keep making them do freebies for me with regards to consulting.



Thomas

Re: "freenginx" open source package and "nginx" from F5 open source, potential conflict?

[Michael Lustfield]

On Mon, 26 Feb 2024 14:59:48 -0600
Richard Laager  wrote:

> On 2024-02-26 11:49, Thomas Ward wrote:
> [...]
> 
> So, in effect, Maxim seems to have wanted F5 to either NOT publish a 
> security vulnerability for their commercial product, knowing their 
> customers/users had this code in production, or to issue a CVE for the 
> commercial product but not the underlying OSS project with the exact 
> same code. Neither of those makes any sense to me.
> 

I wanted to believe there was something deeper going on that would eventually
be exposed, but this really seems to be the root of it. One particular
developer was expecting that they'd get to say what is and is not a
vulnerability and they didn't like that reality was different.

In this particular case, the policy that was being followed was extremely clear
and there was very little room for interpretation.

> > So, before I follow through with Debian packaging (which would be 
> > synced to Ubuntu downstream), may I get the opinion of debian-legal on 
> > whether there’s any copyright or trademark violation concerns that 
> > exist before I pursue getting this into Debian?
> >  
> I'm not a lawyer, but it sure seems like an obvious trademark problem to 
> me. In my opinion, Maxim really should pick a brand new name if he's 
> serious about this as an ongoing project.

Everything I've seen so far screams copyright violation. The website even
started as a verbatim copy/paste of the original, with just the logo and name
changed in only a few places. Even now, it's basically just a copy/paste with a
reset feed ... heck, it still has "nginx news" up in the title on the front
page.

At this point, even if they were to find/replace, the proper copyright holder
will have a claim to be made against the squatting that took place.

From my perspective, it sure looks like they're trying to hostilely squat the
name for as long as they can while pushing out a replacement with a similar
name, currently offering nothing but the assurance of fewer CVEs.

This is one hot potato I would recommend staying far away from.
-- 
Michael Lustfield

Re: "freenginx" open source package and "nginx" from F5 open source, potential conflict?

[Richard Laager]

First off, I don't know anyone involved in this.

On 2024-02-26 11:49, Thomas Ward wrote:

Back on February 14^th , an email went to the standard NGINX mailing 
list that NGINX (F5) open source development changed a lot of policies 
and interfered with security policy use cases


I don't know what other factors lead to the fork, but as far as the 
security policy thing goes...


Note that, per Maxim's own statement, the security policy disagreement 
is that he did NOT want to issue CVEs because the code was marked 
"experimental": 
https://mailman.nginx.org/pipermail/nginx/2024-February/FRVX4M5JLFSFESRG7RLWWRBZ6D4AKKQU.html


MZMegaZone on Hacker News claims to be the person at F5 on the other 
side of that. Here's the top-level article:

https://news.ycombinator.com/item?id=39373327

These two sub-threads are most relevant:
https://news.ycombinator.com/item?id=39373834
https://news.ycombinator.com/item?id=39373966

As MZMegaZone said, "Honestly, anyone could have gone to a CNA and 
demanded a CVE and he would not have been able to stop it. That's how it 
works." As I replied there, "I recently did exactly that when a vendor 
refused to obtain a CVE themselves."


MZMegaZone also said, "Also, something that keeps getting lost here, the 
CVE is NOT just against NGINX OSS, but also NGINX+, the commercial 
product. And the packaging, release, and messaging on that is a bit 
different. That had to be part of the decision process too. Since it is 
the same code the CVE applies to both." And in another comment, "We know 
a number of customers/users have the code in production, experimental or 
not. And that was part of decision process. The security advisories we 
published do state the feature is experimental."


So, in effect, Maxim seems to have wanted F5 to either NOT publish a 
security vulnerability for their commercial product, knowing their 
customers/users had this code in production, or to issue a CVE for the 
commercial product but not the underlying OSS project with the exact 
same code. Neither of those makes any sense to me.



So, before I follow through with Debian packaging (which would be 
synced to Ubuntu downstream), may I get the opinion of debian-legal on 
whether there’s any copyright or trademark violation concerns that 
exist before I pursue getting this into Debian?


I'm not a lawyer, but it sure seems like an obvious trademark problem to 
me. In my opinion, Maxim really should pick a brand new name if he's 
serious about this as an ongoing project.


Does Canonical have lawyers you could ask?

--
Richard



OpenPGP_signature.asc
Description: OpenPGP digital signature

"freenginx" open source package and "nginx" from F5 open source, potential conflict?

[Thomas Ward]

Good day, debian-legal!

Back on February 14th, an email went to the standard NGINX mailing list that 
NGINX (F5) open source development changed a lot of policies and interfered 
with security policy use cases enough to irritate one of the main community 
developers of NGINX.  At that time, a fork was created of the NGINX project 
called "freenginx".  The list announcement of this can be seen at [1].

I was approached separately by Maxim as a known package maintainer for NGINX to 
see if I can help get freenginx into Debian and Ubuntu.  However, as a person 
in business myself as a consultant, and someone who had to ask Canonical to get 
involved on an unrelated trademark violation issue, I'm concerned that there 
may be a trademark violation problem at play.

While theoretically there wouldn't be one and we can simply add Provides: nginx 
to both freenginx and nginx packaging and conflicts/breaks on freenginx vs. 
standard nginx because the two won't behave right with each other, the concern 
I have is that we're introducing a trademark problem into the mix.

So, before I follow through with Debian packaging (which would be synced to 
Ubuntu downstream), may I get the opinion of debian-legal on whether there's 
any copyright or trademark violation concerns that exist before I pursue 
getting this into Debian?


Thomas Ward
Debian Maintainer for multiple packages
Ubuntu Core Developer

[1]: 
https://mailman.nginx.org/pipermail/nginx/2024-February/GPXQY27UA5SJJZ2Y6JWTRWJB2TKPTJR7.html

Meeting with the Development Team

[Ray Galt]

Hello,

I would like to reach out to the decision-maker in the IT environment within 
your company.

We are a well-established digital agency in the European market. Our solutions 
eliminate the need to build and maintain in-house IT and programming 
departments, hire interface designers, or employ user experience specialists.

We take responsibility for IT functions while simultaneously reducing the costs 
of maintenance. We provide support that ensures access to high-quality 
specialists and continuous maintenance of efficient hardware and software 
infrastructure.

Companies that thrive are those that leverage market opportunities faster than 
their competitors. Guided by this principle, we support gaining a competitive 
advantage by providing comprehensive IT support.

May I present what we can do for you?


Best regards
Ray Galt

Re: FreeSWITCH license analysis

[Richard Laager]

I dug into this a bit. We use FreeSWITCH at my day job, so I'm certainly 
interested in this sort of thing. I'm not a lawyer either, though.


In this particular case, I see @coppice-git's point that these are 
basically math data tables. Personally, I don't think it's a problem in 
this particular case.


That said, the _ideal_ situation would be for the copyright holder to 
explicitly clarify the situation. My recommendation would be:


Best: Change the make_*.c files to be LGPL.

Good: Change the make_*.c files to put some permissive license grant 
into the files. This is the gcc/autoconf/bison exception approach, 
more-or-less. @coppice-git offered this (possibly with some snark 
intended) in:

https://github.com/freeswitch/spandsp/issues/70#issuecomment-1944412131

Looking at the history of these files, as a practical matter, if 
@coppice-git consented, I'd probably call that good enough.


If I were you, I'd respond to that last comment with something like:

I see your point about these being data tables. However, Debian can be a 
stickler for copyright. If you were to make the tools put an LGPL header 
in the generated data files, that would eliminate any doubt, which would 
be helpful to me on the Debian side.


--
Richard



OpenPGP_signature.asc
Description: OpenPGP digital signature

FreeSWITCH license analysis

[Guillem Jover]

Hi!

At work we have been checking whether switching to FreeSWITCH would
be feasible, with an eye to eventually help package and/or maintain
it in Debian (as part of ). One of
the points was doing a license audit. For context, because FreeSWITCH
is licensed under the MPL-1.1 and that is incompatible with any GPL
version, this resulted in the following issue and PR upstream to
clean up stuff:

  
  

Which overall on the FreeSWITCH side do not seem like major issues (or
at least potential issues that can easily be solved by removing code or
disabling ancillary modules/dependencies). But as mentioned on that issue
above, while then checking its dependencies, I stumbled over src:spandsp,
where the library is LGPL licensed (so *not* MPL-1.1 incompatible) and
some of the tools or build machinery are GPL licensed, but found some
files that end up directly or indirectly being included in the library
were part of those GPL licensed ones. This resulted in:

  

Upstream mentioned that the C file that gets included directly was a
slip-up, and promptly corrected that in git. But there are still few
tools (GPL licensed) that are used as part of its build system that
generate code (data types and data tables) that ends up included in
the library.

At this point upstream is stating this is not a problem (as in those do
not "pollute" the library with GPL code). And I'm though wondering whether
that is indeed fine or I'm being overzealous/overcautious with this. So
I'd like your opinion whether these tools and their output are fine as is,
or there would ideally be some licensing change applied to those source
files.

Thanks,
Guillem

Re: XZ upstream thinks about switching from PD to 0BSD.

[Daniel Hakimi]

The BSD 0-clause license is effectively a public domain grant in
jurisdictions that acknowledge public domain grants, and an extremely
permissive license in jurisdictions that do not. This does not seem like an
issue. attribution is not required in either case.

On Tue, Feb 13, 2024, 15:49 Sebastian Andrzej Siewior <
sebast...@breakpoint.cc> wrote:

> Hi,
>
> the XZ upstream project thinks about changing the license from Public
> Domain to BSD Zero clause license:
> https://github.com/tukaani-project/xz/issues/79
>
> I *think* the PD "license" has no copyright and this isn't an issue for
> Debian.
> Could someone please comment on behalf of the Debian Project?
>
> Sebastian
>
>

XZ upstream thinks about switching from PD to 0BSD.

[Sebastian Andrzej Siewior]

Hi,

the XZ upstream project thinks about changing the license from Public
Domain to BSD Zero clause license:
https://github.com/tukaani-project/xz/issues/79

I *think* the PD "license" has no copyright and this isn't an issue for
Debian. 
Could someone please comment on behalf of the Debian Project?

Sebastian

Re: hard linking libboost copyright files

[Giovanni Mascellani]

Hi,

Il 04/02/24 06:38, Muhammad Yaaseen ha scritto:
we see that the copyright for libboost debian packages are 2MB each and 
are all the same. as per 
https://www.debian.org/doc/debian-policy/ch-docs.html section 12.5 
 
we are not allowed to create symbolic links. the doubt I have is whether 
I can hardlink these files and reduce the memory utilization.


As one of the Boost maintainers, I agree that's a problem. I wonder 
whether the best way forward would rather to aggregate the copyright 
data with more coarse granularity, so that the file is shorter. I am not 
really sure that we need such a detailed thing. I spent considerable 
time preparing that thing, but I am not sure that is the way forward.


At any rate, unfortunately I haven't had time to work on Debian packages 
for some time, so the situation is still unsolved.


Gio.

Re: TrueType/OpenType and anti-circumvention laws

[P. J. McDermott]

On 2024-02-05 at 10:34, Paul Wise wrote:
> On Mon, 2024-01-15 at 06:05 -0500, P. J. McDermott wrote:
> 
> > Paul Wise mentioned[8] on the fonts team list in 2021 a couple programs
> > ("embed"[9], a derivative "ttembed"[10], and "ttfpatch"[11]) that unset
> > the DRM/TPM bits, enabling full use of the fonts.  "embed" was written
> > by a font designer who noticed that his fonts had restrictive embedding
> > permissions and that a tool he used (which was intended for font users,
> > not designers) didn't allow lowering the restrictions.  
> 
> PS: for thread completeness, I note the embed author recieved DMCA
> legal threats, but did not remove the tool from their website:
> 
> http://carnage-melon.tom7.org/embed/dmca.html

Thanks, that's a very interesting read.

I'm surprised to see that Paul F. Stack alleged that embed violates
subsection 1201(a) (circumvention by descrambling, decrypting, etc.
of a TPM that "effectively controls access".  Tom Murphy 7 clearly
explains why that doesn't apply per the definitions in 1201(a)(3): a bit
field doesn't "[require] the application of information" etc. (e.g. a
descrambling or decryption key).  Instead, it actually requires other
programs (not embed) to proactively check and obey the bit field.  So
even if embed didn't exist, unauthorized exercise of a right (1201(b),
not unauthorized access to a work under 1201(a)) could be performed
simply because another program lacks the extra code to check the bit
field).

Only subsection 1201(b) (circumvention of not a TPM, but of "protection
afforded" by a TPM that "limits the exercise of a right") could apply
here.  However, 1201(b) doesn't prohibit the act of circumvention itself
like 1201(a)(1) does.  It only prohibits trafficking in technology etc.
that circumvents, like 1201(a)(2) does.

Stack seemed to pretend (or somehow believe) that 1201(a) applies,
specifically to rely on the prohibition of the act of circumvention (not
focusing on the trafficking in embed), in an attempt to scare Murphy
into believing he's vicariously liable for contributory infringement in
every (non-specified) act of circumvention by embed users (with a threat
that the statutory damages of each act add up).  It's not until his last
"memorandum" in which Stack ever mentioned 1201(b) at all, let alone
alleging any violation of it.  Further, Stack oddly quoted from 1201(b)
and at the end of that same paragraph made a remark about the DMCA not
affecting contributory infringement, as if to suggest (flat out wrongly)
that Murphy could be liable for acts of circumvention under 1201(b)
(which as I noted does not actually prohibit such circumvention).  Stack
was careful to not explicitly say that Murphy is liable for contributory
infringement by embed users under 1201(b) (there cannot possibly be any
such infringement by users in the first place) but apparently wanted
Murphy to believe that he could be liable.  That is either a bad faith
scare tactic or ignorance of the law (which is not good for a lawyer).
Either way, this seems like an unserious legal threat, which if brought
in court, any decent copyright defense attorney could probably have
dismissed, perhaps even summarily and/or with prejudice.

The DeCSS case cited by Stack could have been relevant here, except
that it alleged misappropriation of the CSS descrambling key as a trade
secret, and DVD CCA never alleged violation of the DMCA (1201(a), which
in that case would have been relevant).

Back to the matter at hand, subsection 1201(a) doesn't apply because no
information (e.g. a descrambling or decryption key) is needed to access
a font.  Subsection 1201(b) could apply, making distribution of a
program like embed or ttembed possibly illegal.  But 1201(b) (unlike
1201(a)) doesn't prohibit the use of such a program.  Does anyone know
whether other jurisdictions have laws stricter than the US DMCA, i.e.
laws that prohibit the use of programs like embed and ttembed (the
act of circumventing "protection afforded" by a TPM that "limits the
exercise of a right")?

Has there ever been a legal threat (let alone a court case) alleging
that a program like embed or ttembed violates subsection 1201(b) (or
an international equivalent thereof)?  Perhaps such a threat isn't
financially worthwhile, because statutory civil damages (1203(c)(3)) are
at most $2,500 per device/product/etc. (i.e. one program), and there can
be no contributory infringement that multiplies such damages for each
act of circumvention by users.  And actual damages (which can be sought
instead of, not in addition to, statutory damages) would be hard if not
impossible to prove.

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Re: TrueType/OpenType and anti-circumvention laws

[Paul Wise]

On Mon, 2024-01-15 at 06:05 -0500, P. J. McDermott wrote:

> Paul Wise mentioned[8] on the fonts team list in 2021 a couple programs
> ("embed"[9], a derivative "ttembed"[10], and "ttfpatch"[11]) that unset
> the DRM/TPM bits, enabling full use of the fonts.  "embed" was written
> by a font designer who noticed that his fonts had restrictive embedding
> permissions and that a tool he used (which was intended for font users,
> not designers) didn't allow lowering the restrictions.

PS: for thread completeness, I note the embed author recieved DMCA
legal threats, but did not remove the tool from their website:

http://carnage-melon.tom7.org/embed/dmca.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: hard linking libboost copyright files

[Walter Landry]

Andreas Metzler  writes:
> On 2024-02-04 Muhammad Yaaseen  wrote:
>> The question is once we install the libboost .deb packages into a
>> system, the copyright file for each libboost package is stored
>> separately in /usr/shared/doc/packages folder. I'm think of
>> hardlinking these copyright files so that we same some memory. Is this
>> legally allowed. 
> [...]
>
> The canonical solution would be to add libboost-commonx.xx containing
> what is currently found in /usr/share/doc/libboost-foox.xx and symlink
> the whole directory. You'll probably need to make libboost-commonx.xx
> arch all to be binNMU compatible.

Another solution would be to add the Boost license to
/usr/share/common-licenses.  Running

  ls /usr/share/doc/*/copyright | xargs -n 100 grep "Boost Software License" | 
wc -l

on my bookworm system finds it in 225 packages, of which 160 are not a
libboost* package.

Cheers,
Walter Landry

Re: hard linking libboost copyright files

[Andreas Metzler]

On 2024-02-04 Andreas Metzler  wrote:
[...]

> The canonical solution would be to add libboost-commonx.xx containing
> what is currently found in /usr/share/doc/libboost-foox.xx and symlink
> the whole directory. You'll probably need to make libboost-commonx.xx
> arch all to be binNMU compatible.
   ^^^

arch *any* obviously, not "all".

Re: hard linking libboost copyright files

[Andreas Metzler]

On 2024-02-04 Muhammad Yaaseen  wrote:
> The question is once we install the libboost .deb packages into a
> system, the copyright file for each libboost package is stored
> separately in /usr/shared/doc/packages folder. I'm think of
> hardlinking these copyright files so that we same some memory. Is this
> legally allowed. 
[...]

The canonical solution would be to add libboost-commonx.xx containing
what is currently found in /usr/share/doc/libboost-foox.xx and symlink
the whole directory. You'll probably need to make libboost-commonx.xx
arch all to be binNMU compatible.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

RE: hard linking libboost copyright files

[Muhammad Yaaseen]

Hi, 

The question is once we install the libboost .deb packages into a system, the 
copyright file for each libboost package is stored separately in 
/usr/shared/doc/packages folder. These copyright files are all the same. I'm 
think of hardlinking these copyright files so that we same some memory. Is this 
legally allowed. 

Regards
Yaaseen

-Original Message-
From: Steve Langasek  
Sent: Sunday, February 4, 2024 3:07 PM
To: Muhammad Yaaseen 
Cc: debian-legal@lists.debian.org
Subject: Re: hard linking libboost copyright files

On Sun, Feb 04, 2024 at 05:38:57AM +, Muhammad Yaaseen wrote:

> we see that the copyright for libboost debian packages are 2MB each 
> and are all the same.  as per 
> https://www.debian.org/doc/debian-policy/ch-docs.html section 
> 12.5 012.5> we are not allowed to create symbolic links.  the doubt I have 
> is whether I can hardlink these files and reduce the memory 
> utilization.

This isn't really a legal question; as a practical matter, it is not possible 
to ship cross-package hardlinks in .deb packages.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

Re: hard linking libboost copyright files

[Steve Langasek]

On Sun, Feb 04, 2024 at 10:50:43AM +, Muhammad Yaaseen wrote:

> The question is once we install the libboost .deb packages into a system,
> the copyright file for each libboost package is stored separately in
> /usr/shared/doc/packages folder.  I'm think of hardlinking these copyright
> files so that we same some memory.  Is this legally allowed.

Sorry, but this is also not a mailing list for providing legal advice to end
users.  If you are concerned about the legality of what you are doing
downstream of Debian, you should consult your own lawyer.

> -Original Message-
> From: Steve Langasek  
> Sent: Sunday, February 4, 2024 3:07 PM
> To: Muhammad Yaaseen 
> Cc: debian-legal@lists.debian.org
> Subject: Re: hard linking libboost copyright files
> 
> On Sun, Feb 04, 2024 at 05:38:57AM +, Muhammad Yaaseen wrote:
> 
> > we see that the copyright for libboost debian packages are 2MB each 
> > and are all the same.  as per 
> > https://www.debian.org/doc/debian-policy/ch-docs.html section 
> > 12.5 > 012.5> we are not allowed to create symbolic links.  the doubt I have 
> > is whether I can hardlink these files and reduce the memory 
> > utilization.
> 
> This isn't really a legal question; as a practical matter, it is not possible 
> to ship cross-package hardlinks in .deb packages.
> 
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
> 

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

RE: hard linking libboost copyright files

[Muhammad Yaaseen]

Hi Steve, 

The question is once we install the libboost .deb packages into a system, the 
copyright file for each libboost package is stored separately in 
/usr/shared/doc/packages folder. I'm think of hardlinking these copyright files 
so that we same some memory. Is this legally allowed. 

Regards
Yaaseen

-Original Message-
From: Steve Langasek  
Sent: Sunday, February 4, 2024 3:07 PM
To: Muhammad Yaaseen 
Cc: debian-legal@lists.debian.org
Subject: Re: hard linking libboost copyright files

On Sun, Feb 04, 2024 at 05:38:57AM +, Muhammad Yaaseen wrote:

> we see that the copyright for libboost debian packages are 2MB each 
> and are all the same.  as per 
> https://www.debian.org/doc/debian-policy/ch-docs.html section 
> 12.5 012.5> we are not allowed to create symbolic links.  the doubt I have 
> is whether I can hardlink these files and reduce the memory 
> utilization.

This isn't really a legal question; as a practical matter, it is not possible 
to ship cross-package hardlinks in .deb packages.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

Re: hard linking libboost copyright files

[Steve Langasek]

On Sun, Feb 04, 2024 at 05:38:57AM +, Muhammad Yaaseen wrote:

> we see that the copyright for libboost debian packages are 2MB each and
> are all the same.  as per
> https://www.debian.org/doc/debian-policy/ch-docs.html section
> 12.5
> we are not allowed to create symbolic links.  the doubt I have is whether
> I can hardlink these files and reduce the memory utilization.

This isn't really a legal question; as a practical matter, it is not
possible to ship cross-package hardlinks in .deb packages.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

hard linking libboost copyright files

[Muhammad Yaaseen]

Hi,

we see that the copyright for libboost debian packages are 2MB each and are all 
the same. as per https://www.debian.org/doc/debian-policy/ch-docs.html section 
12.5 we 
are not allowed to create symbolic links. the doubt I have is whether I can 
hardlink these files and reduce the memory utilization.

Regards
Yaaseen

Re: TrueType/OpenType and anti-circumvention laws

[P. J. McDermott]

On 2024-02-02 at 22:18, Walter Landry wrote:
> This feels similar to pdf viewers that do not honor DRM bits like 'do
> not print', which Debian distributes.  Here is an old email exchange.
> 
>   https://lists.debian.org/debian-legal/2005/03/msg00308.html
> 
> and a bug ticket that implemented DRM stripping.
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298584
> 
> Running
> 
>   pdftohtml --help
> 
> on my bookworm system includes the option
> 
>   -nodrm: override document DRM settings

Great example, thanks.

PDF 1.5[1] (the earliest version with this DRM, unchanged through
ISO 32000-2:2020) Table 3.20 lists user access permission bits.
Poppler represents them as follows:

//
// Permission bits
// Note that the PDF spec uses 1 base (eg bit 3 is 1<<2)
//

#define permPrint (1 << 2) // bit 3
#define permChange (1 << 3) // bit 4
#define permCopy (1 << 4) // bit 5
#define permNotes (1 << 5) // bit 6
#define permFillForm (1 << 8) // bit 9
#define permAccessibility (1 << 9) // bit 10
#define permAssemble (1 << 10) // bit 11
#define permHighResPrint (1 << 11) // bit 12
#define defPermFlags 0xfffc

It checks the bit field:

bool XRef::okToCopy(bool ignoreOwnerPW) const
{
return (!ignoreOwnerPW && ownerPasswordOk) || (permFlags & permCopy);
}

And pdftohtml (in Poppler) checks and optionally ignores it:

// check for copy permission
if (!doc->okToCopy()) {
if (!noDrm) {
error(errNotAllowed, -1, "Copying of text from this document is not 
allowed.");
goto error;
}
fprintf(stderr, "Document has copy-protection bit set.\n");
}

It's indeed very similar, except that pdftohtml doesn't change the
permission bit in the document like these font tools do.  But this
is maybe a distinction without a difference, as I note in the last
paragraph below.

[1]: 
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.5_v6.pdf

On 2024-02-03 at 13:42, Paul Wise wrote:
> On Fri, 2024-02-02 at 20:16 -0500, P. J. McDermott wrote:
> 
> > [Resending to the list, as it apparently didn't go through earlier.]  
> 
> It did go through.

Oops, you're right.  Sorry for the noise.

> > Ping?  Any thoughts on whether a font DRM modification tool would be
> > legal to distribute and use in Debian given that the DRM is a simple bit
> > field rather than an "effective" TPM such as scrambling or encryption?  
> 
> Probably best to consult a lawyer there, but ISTR even trivial things
> are supposed to count under the DMCA.

I guess there's another issue here.  17 USC subsection 1201(a) (which I
quoted previously) covers "circumventing a technological measure that
effectively controls access to a work".  Subsection 1201(b) covers
"circumventing protection afforded by a technological measure that
effectively protects a right of a copyright owner".

FontForge circumvents such "protection afforded" by a TPM under
subsection 1201(b); should it be removed from Debian?  Maybe it's OK
because it's not "primarily designed or produced" for that purpose?

As I said, I think tools like embed/ttembed and ttfpatch are fine under
subsection 1201(a) since they don't circumvent (e.g. by descrambling or
decryption) a TPM that "effectively controls access", but maybe 1201(b)
presents an issue with "circumventing protection afforded by" a TPM that
"effectively protects a right".

To "circumvent protection afforded by a technological measure" is
defined as "avoiding, bypassing, removing, deactivating, or otherwise
impairing" it.  These font tools I guess remove or deactivate a TPM,
and pdftohtml I guess avoids or bypasses a TPM.  What makes pdftohtml
acceptable in Debian?  Is it only the "primarily designed or produced"
language, and if so, how far does that extend (does it cover an intent
that a tool be used by font designers or others licensed to fix fonts)?

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Re: TrueType/OpenType and anti-circumvention laws

[Walter Landry]

Paul Wise  writes:
> On Fri, 2024-02-02 at 20:16 -0500, P. J. McDermott wrote:
>> Ping?  Any thoughts on whether a font DRM modification tool would be
>> legal to distribute and use in Debian given that the DRM is a simple bit
>> field rather than an "effective" TPM such as scrambling or encryption?
>
> Probably best to consult a lawyer there, but ISTR even trivial things
> are supposed to count under the DMCA.

This feels similar to pdf viewers that do not honor DRM bits like 'do
not print', which Debian distributes.  Here is an old email exchange.

  https://lists.debian.org/debian-legal/2005/03/msg00308.html

and a bug ticket that implemented DRM stripping.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298584

Running

  pdftohtml --help

on my bookworm system includes the option

  -nodrm: override document DRM settings

Cheers,
Walter Landry

Re: TrueType/OpenType and anti-circumvention laws

[Paul Wise]

On Fri, 2024-02-02 at 20:16 -0500, P. J. McDermott wrote:

> [Resending to the list, as it apparently didn't go through earlier.]

It did go through.

> Ping?  Any thoughts on whether a font DRM modification tool would be
> legal to distribute and use in Debian given that the DRM is a simple bit
> field rather than an "effective" TPM such as scrambling or encryption?

Probably best to consult a lawyer there, but ISTR even trivial things
are supposed to count under the DMCA.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: TrueType/OpenType and anti-circumvention laws

[P. J. McDermott]

[Resending to the list, as it apparently didn't go through earlier.]

Ping?  Any thoughts on whether a font DRM modification tool would be
legal to distribute and use in Debian given that the DRM is a simple bit
field rather than an "effective" TPM such as scrambling or encryption?

FontForge of course can also do this, though it's not "primarily
designed or produced" to do so.  So this seems to me like a reasonable
use case that can be done with software already in Debian.

On 2024-01-15 at 06:05, P. J. McDermott wrote:
> [I'm Cc:'ing Felix Lechner in case he is interested in this thread.
> Please Cc: Felix (unless he says otherwise) and me in replies; I've set
> Reply-To: to automate this.]
> 
> Hi,
> 
> I stumbled upon lintian's truetype-font-prohibits-installable-embedding
> and opentype-font-prohibits-installable-embedding warning tags[1][2]
> (from checks suggested[3][4] by Paul Wise and written[5] by Felix
> Lechner) via an affected package.  I've learned how to fix it, and I'm
> also drafting a message to the fonts team about why and how to fix it
> more broadly there and elsewhere in Debian.  But first I have some legal
> questions about the solution.
> 
> The issue, put simply, is fonts with DRM/TPM bit fields set to prohibit
> activities otherwise allowed by their licenses (licenses which in some
> cases actually prohibit "impos[ing]" or "apply[ing]" effective TPMs):
> specifically[6][7], embedding the fonts in documents, editing documents
> in which the fonts are embedded, and extracting embedded fonts from
> documents and installing them for further use.  Often this is a mistake
> by the font designers, because their tools (for example versions of
> FontForge older than 2014) restrict fonts by default.
> 
> Paul Wise mentioned[8] on the fonts team list in 2021 a couple programs
> ("embed"[9], a derivative "ttembed"[10], and "ttfpatch"[11]) that unset
> the DRM/TPM bits, enabling full use of the fonts.  "embed" was written
> by a font designer who noticed that his fonts had restrictive embedding
> permissions and that a tool he used (which was intended for font users,
> not designers) didn't allow lowering the restrictions.  "ttfpatch"
> was similarly written for font designers, to either prohibit or allow
> embedding and other uses, but I don't think the author is himself a
> designer.
> 
> Although these tools were written (in one case by a font designer) for
> use by font designers, they can also be (ab)used by others to unset
> DRM/TPM bits without permission.
> 
> US law[12] (17 USC section 1201(a)(2)(A)) prohibits software that "is
> *primarily designed or produced* for the purpose of circumventing"
> effective TPMs (emphasis mine), and the primary purpose of these tools,
> as I said, is for font designers to work around deficiencies in their
> editing tools.  But the primary purpose is also to unset DRM bits.
> 
> 17 USC section 1201(a)(3) defines circumvention as "to descramble a
> scrambled work, to decrypt an encrypted work, or otherwise to avoid,
> bypass, remove, deactivate, or impair a technological measure ...".
> And a TPM is defined as effective if it "requires the application of
> information, or a process or a treatment, with the authority of the
> copyright owner, to gain access to the work".  Unlike DVD CSS for
> example, there are no descrambling keys required (only a bit field that
> non-compliant PDF viewers/editors or font libraries might not even
> check).  So I'm not sure if, under US law at least, anti-circumvention
> law even applies to fonts.
> 
> Is anyone here familiar with how other jurisdictions (e.g. under
> Directive 2001/29/EC) define "circumvention", "technological measures",
> "effective", and "copy control mechanism", and whether simple bit fields
> count?  Is there any relevant case law?
> 
> I therefore wonder: should these tools be treated like regular
> development tools (e.g. fontforge or dh_fixperms) or more like
> circumvention tools (e.g. libdvdcss)?  Specifically:
> 
>   * Would it be legal or appropriate to package such a tool in Debian,
> because it would help font designers and Debian package maintainers
> find and fix free fonts with DRM, including possibly during package
> builds (like dh_fixperms for font DRM)?
> 
>   * Similarly, would it be legal or appropriate for packages containing
> restricted fonts to include and build from source (but not install
> and distribute binaries of) such a tool to fix permissions during
> the build?
> 
>   * Should Debian maintainers even be fixing the fonts themselves at all
> (obviously, in general, fixes should be sent upstream when possible)
> given that doing so could circumvent DRM/TPMs?  Should we not go
> near this issue and just tell upstream font designers to fix their
> own fonts, instead of us submitting fixed fonts upstream?  What if
> fonts are no longer actively developed and upstream is unresponsive?
> 
> Or are the licenses sufficient 

Re: TrueType/OpenType and anti-circumvention laws

[P. J. McDermott]

Ping?  Any thoughts on whether a font DRM modification tool would be
legal to distribute and use in Debian given that the DRM is a simple bit
field rather than an "effective" TPM such as scrambling or encryption?

FontForge of course can also do this, though it's not "primarily
designed or produced" to do so.  So this seems to me like a reasonable
use case that can be done with software already in Debian.

On 2024-01-15 at 06:05, P. J. McDermott wrote:
> [I'm Cc:'ing Felix Lechner in case he is interested in this thread.
> Please Cc: Felix (unless he says otherwise) and me in replies; I've set
> Reply-To: to automate this.]
> 
> Hi,
> 
> I stumbled upon lintian's truetype-font-prohibits-installable-embedding
> and opentype-font-prohibits-installable-embedding warning tags[1][2]
> (from checks suggested[3][4] by Paul Wise and written[5] by Felix
> Lechner) via an affected package.  I've learned how to fix it, and I'm
> also drafting a message to the fonts team about why and how to fix it
> more broadly there and elsewhere in Debian.  But first I have some legal
> questions about the solution.
> 
> The issue, put simply, is fonts with DRM/TPM bit fields set to prohibit
> activities otherwise allowed by their licenses (licenses which in some
> cases actually prohibit "impos[ing]" or "apply[ing]" effective TPMs):
> specifically[6][7], embedding the fonts in documents, editing documents
> in which the fonts are embedded, and extracting embedded fonts from
> documents and installing them for further use.  Often this is a mistake
> by the font designers, because their tools (for example versions of
> FontForge older than 2014) restrict fonts by default.
> 
> Paul Wise mentioned[8] on the fonts team list in 2021 a couple programs
> ("embed"[9], a derivative "ttembed"[10], and "ttfpatch"[11]) that unset
> the DRM/TPM bits, enabling full use of the fonts.  "embed" was written
> by a font designer who noticed that his fonts had restrictive embedding
> permissions and that a tool he used (which was intended for font users,
> not designers) didn't allow lowering the restrictions.  "ttfpatch"
> was similarly written for font designers, to either prohibit or allow
> embedding and other uses, but I don't think the author is himself a
> designer.
> 
> Although these tools were written (in one case by a font designer) for
> use by font designers, they can also be (ab)used by others to unset
> DRM/TPM bits without permission.
> 
> US law[12] (17 USC section 1201(a)(2)(A)) prohibits software that "is
> *primarily designed or produced* for the purpose of circumventing"
> effective TPMs (emphasis mine), and the primary purpose of these tools,
> as I said, is for font designers to work around deficiencies in their
> editing tools.  But the primary purpose is also to unset DRM bits.
> 
> 17 USC section 1201(a)(3) defines circumvention as "to descramble a
> scrambled work, to decrypt an encrypted work, or otherwise to avoid,
> bypass, remove, deactivate, or impair a technological measure ...".
> And a TPM is defined as effective if it "requires the application of
> information, or a process or a treatment, with the authority of the
> copyright owner, to gain access to the work".  Unlike DVD CSS for
> example, there are no descrambling keys required (only a bit field that
> non-compliant PDF viewers/editors or font libraries might not even
> check).  So I'm not sure if, under US law at least, anti-circumvention
> law even applies to fonts.
> 
> Is anyone here familiar with how other jurisdictions (e.g. under
> Directive 2001/29/EC) define "circumvention", "technological measures",
> "effective", and "copy control mechanism", and whether simple bit fields
> count?  Is there any relevant case law?
> 
> I therefore wonder: should these tools be treated like regular
> development tools (e.g. fontforge or dh_fixperms) or more like
> circumvention tools (e.g. libdvdcss)?  Specifically:
> 
>   * Would it be legal or appropriate to package such a tool in Debian,
> because it would help font designers and Debian package maintainers
> find and fix free fonts with DRM, including possibly during package
> builds (like dh_fixperms for font DRM)?
> 
>   * Similarly, would it be legal or appropriate for packages containing
> restricted fonts to include and build from source (but not install
> and distribute binaries of) such a tool to fix permissions during
> the build?
> 
>   * Should Debian maintainers even be fixing the fonts themselves at all
> (obviously, in general, fixes should be sent upstream when possible)
> given that doing so could circumvent DRM/TPMs?  Should we not go
> near this issue and just tell upstream font designers to fix their
> own fonts, instead of us submitting fixed fonts upstream?  What if
> fonts are no longer actively developed and upstream is unresponsive?
> 
> Or are the licenses sufficient permission for us to fix the fonts?
> 17 USC section 1201(a)(3)(A) for 

d/copyright for source having MPL-2.0 + "adaptation from ..."

[Fab Stz]

Hello,

We got a rejection from FTP masters asking to mention SUN Microsystems in 
addition to MPL-2.0.

My question would be, how would you transcribe this into d/copyright given 
that the source file upstream is not precise.

Upstream is here (with its issue for that matter referecing the affected 
source file).
https://github.com/pdeljanov/Symphonia
https://github.com/pdeljanov/Symphonia/issues/255

I found [1] which could match but since it's not in upstream's repo I don't 
really know what is the best.

Some of the options are:

A: Add SUN Microsystems to the copyright holders for * + Add a license named 
SUN-G711 with a single line content: "Adapted from work by SUN Microsystems 
under unrestricted use license."

B: Create a specific section for that file and add SUN Microsystems to the 
copyright holders + Add a license named SUN-G711 with a single line content: 
"Adapted from work by SUN Microsystems under unrestricted use license."

C: Like A but with full text license as found in [1]

D: Like B but with full text license  as found in [1]

[1] https://scancode-licensedb.aboutcode.org/sun-source.html

Which would be best?

Please keep me in copy of the reply.

Regards
Fab

Ihre Eintragung in unseren Newsletter

[operations]

Hallo EASYxMONEYxHERE http://betterchange.ru?ywhw EASYxMONEYxHERE 
http://betterchange.ru?ywhw,

Sie haben sich für unseren Newsletter eingetragen. 
Um zukünftig aktuelle Informationen zu erhalten, 
bestätigen Sie bitte diesen Link:
https://www.eurocommand.com/de/newsletter/eintragen-bestaetigen.php?receiversid=719b3c44fcd5a310e9522d8f835fb81e=debian-legal@lists.debian.org=748612d0b2971094a4a5f75f17ee22b9

Viele Grüße

Ihr Eurocommand-Team

TrueType/OpenType and anti-circumvention laws

[P. J. McDermott]

[I'm Cc:'ing Felix Lechner in case he is interested in this thread.
Please Cc: Felix (unless he says otherwise) and me in replies; I've set
Reply-To: to automate this.]

Hi,

I stumbled upon lintian's truetype-font-prohibits-installable-embedding
and opentype-font-prohibits-installable-embedding warning tags[1][2]
(from checks suggested[3][4] by Paul Wise and written[5] by Felix
Lechner) via an affected package.  I've learned how to fix it, and I'm
also drafting a message to the fonts team about why and how to fix it
more broadly there and elsewhere in Debian.  But first I have some legal
questions about the solution.

The issue, put simply, is fonts with DRM/TPM bit fields set to prohibit
activities otherwise allowed by their licenses (licenses which in some
cases actually prohibit "impos[ing]" or "apply[ing]" effective TPMs):
specifically[6][7], embedding the fonts in documents, editing documents
in which the fonts are embedded, and extracting embedded fonts from
documents and installing them for further use.  Often this is a mistake
by the font designers, because their tools (for example versions of
FontForge older than 2014) restrict fonts by default.

Paul Wise mentioned[8] on the fonts team list in 2021 a couple programs
("embed"[9], a derivative "ttembed"[10], and "ttfpatch"[11]) that unset
the DRM/TPM bits, enabling full use of the fonts.  "embed" was written
by a font designer who noticed that his fonts had restrictive embedding
permissions and that a tool he used (which was intended for font users,
not designers) didn't allow lowering the restrictions.  "ttfpatch"
was similarly written for font designers, to either prohibit or allow
embedding and other uses, but I don't think the author is himself a
designer.

Although these tools were written (in one case by a font designer) for
use by font designers, they can also be (ab)used by others to unset
DRM/TPM bits without permission.

US law[12] (17 USC section 1201(a)(2)(A)) prohibits software that "is
*primarily designed or produced* for the purpose of circumventing"
effective TPMs (emphasis mine), and the primary purpose of these tools,
as I said, is for font designers to work around deficiencies in their
editing tools.  But the primary purpose is also to unset DRM bits.

17 USC section 1201(a)(3) defines circumvention as "to descramble a
scrambled work, to decrypt an encrypted work, or otherwise to avoid,
bypass, remove, deactivate, or impair a technological measure ...".
And a TPM is defined as effective if it "requires the application of
information, or a process or a treatment, with the authority of the
copyright owner, to gain access to the work".  Unlike DVD CSS for
example, there are no descrambling keys required (only a bit field that
non-compliant PDF viewers/editors or font libraries might not even
check).  So I'm not sure if, under US law at least, anti-circumvention
law even applies to fonts.

Is anyone here familiar with how other jurisdictions (e.g. under
Directive 2001/29/EC) define "circumvention", "technological measures",
"effective", and "copy control mechanism", and whether simple bit fields
count?  Is there any relevant case law?

I therefore wonder: should these tools be treated like regular
development tools (e.g. fontforge or dh_fixperms) or more like
circumvention tools (e.g. libdvdcss)?  Specifically:

  * Would it be legal or appropriate to package such a tool in Debian,
because it would help font designers and Debian package maintainers
find and fix free fonts with DRM, including possibly during package
builds (like dh_fixperms for font DRM)?

  * Similarly, would it be legal or appropriate for packages containing
restricted fonts to include and build from source (but not install
and distribute binaries of) such a tool to fix permissions during
the build?

  * Should Debian maintainers even be fixing the fonts themselves at all
(obviously, in general, fixes should be sent upstream when possible)
given that doing so could circumvent DRM/TPMs?  Should we not go
near this issue and just tell upstream font designers to fix their
own fonts, instead of us submitting fixed fonts upstream?  What if
fonts are no longer actively developed and upstream is unresponsive?

Or are the licenses sufficient permission for us to fix the fonts?
17 USC section 1201(a)(3)(A) for example defines to "circumvent a
technological measure" as "to avoid, bypass, remove, deactivate,
or impair a technological measure, *without the authority of the
copyright owner*" (emphasis mine).  Are licenses like Apache-2.0,
CC-BY(-SA)-3.0, Expat, GPL-2.0, and OFL-1.1 considered to imply such
authority, or does a license have to more explicitly waive any legal
power to forbid circumvention of TPMs like CC-BY(-SA)-4.0 (section
2(a)(4)) and GPL-3.0 (section 3) do?  Of course, what matters most
is font copyright holders' (potentially various and contradictory)
interpretations of