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.

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
> 

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

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

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.

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.

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

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

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

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<https://www.debian.org/doc/debian-policy/ch-docs.html%20section%2
> 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<https://www.debian.org/doc/debian-policy/ch-docs.html%20section%2
> > 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<https://www.debian.org/doc/debian-policy/ch-docs.html%20section%2
> 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

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 

Re: d/copyright entries for licenses and copyright data

[Ross Vandegrift]

Hi Paul,

On Mon, Jan 08, 2024 at 12:54:25PM +0800, Paul Wise wrote:
> On Fri, 2024-01-05 at 22:31 -0800, Ross Vandegrift wrote:
> 
> > Imagine I take some code from a freely licensed reference implementation and
> > customize it.  The result is a derived work.  But this embedding isn't
> > removable - the reference implementation shouldn't accept changes to 
> > integrate
> > it into a specific project.
> 
> The reference implementation should be flexible enough to work as a
> library imported/loaded/linked by any project that wants to use it.

Perhaps - but some people provide code without having any interest in the
implementation details that users might run into.  Still, that code might be
useful to use & distribute.

This is one of many ways Debian and upstream might have different or
conflicting goals.

> > It'd be reasonable to include the original license and copyright statements.
> 
> Right.
> 
> > If I do, Debian requires packagers to describe the license and copyright on
> > those embedded license/copyright files.  And I'm puzzled about how to do 
> > that
> > best.
> 
> Same as for any other file in the source package, list in the
> debian/copyright which files have which copyrights and licenses.

Heh, right - the problem is executing that. :)  Folks typically take care to
document the copyright on code, not so often licenses (the FSF licenses being
the exception, they are clear).

> > (I realize not much hangs on this - but cme/licensecheck raised the issue to
> > me.  I can ignore it, but also got curious and tried to figure out what to 
> > do.)
> 
> What issue did it print? Which package/code is this about BTW?

src:efl is a pastice of original work, dervied code, and vendored copies.  The
situation I asked about is somewhat simplified from real ones.  Here's two
harder cases than what the wiki considers:


- 
https://salsa.debian.org/pkg-e-team/efl/-/blob/debian/sid/src/static_libs/rg_etc/README

  This is a Zlib license statement for code derived from another project.  This
  copy has been rewritten from C++ -> C.  So the changes wouldn't be appropriate
  for the upstream project.

  What license and copyright holders can I write for this file?  The text is
  derived from the Zlib license, but I also don't know who wrote that.
 
- 
https://salsa.debian.org/pkg-e-team/efl/-/blob/debian/sid/src/static_libs/fnmatch/COPYRIGHT

  This is from an included copy of musl's fnmatch algorithm.  I think EFL
  includes this for portability, to ensure that the same fnmatch is used on
  Linux, BSD, and Windows.  Even if that's not needed in Debian, I don't think I
  can link to musl and glibc.


Interestingly, base-files (which contains /usr/share/common-licenses) doesn't
contain any copyright information for some of it's licenses.  It also doesn't
use dep5 copyright, and so probably not licensechcek/cme.  So no one is being
bugged to document who holds the copyright to the MPL-1.1.

Ross


[1] - src:efl has those too.  I'm recently trying to remove a libunbreak copy
  in the static_libs directory.


signature.asc
Description: PGP signature

Re: d/copyright entries for licenses and copyright data

[Paul Wise]

On Fri, 2024-01-05 at 22:31 -0800, Ross Vandegrift wrote:

> Imagine I take some code from a freely licensed reference implementation and
> customize it.  The result is a derived work.  But this embedding isn't
> removable - the reference implementation shouldn't accept changes to integrate
> it into a specific project.

The reference implementation should be flexible enough to work as a
library imported/loaded/linked by any project that wants to use it.
If it isn't then that is an issue that should be fixed upstream.
Once it is then the removal can happen and Debian can use depends.

> It'd be reasonable to include the original license and copyright statements.

Right.

> If I do, Debian requires packagers to describe the license and copyright on
> those embedded license/copyright files.  And I'm puzzled about how to do that
> best.

Same as for any other file in the source package, list in the
debian/copyright which files have which copyrights and licenses.

> Maybe the answer is to repack it away?  But that seems weird.  It's freely
> redistributable, and that'd be *obscuring* license/copyright details.  We
> usually like that. :)

Repacking it away sounds like removing it from the source package,
which would mean it could no longer be used, or never was used, in
both cases there isn't any point having it in the upstream VCS then.

> The same issue arises for disabled conveience copies.  The wiki suggests
> Files-Excluded, but also alternatives that involve Debian redistributing the
> convenience copy (and so probably it's license/copyright files) in source
> packages.

Unless there are DFSG or size reasons to remove the unused copy,
generally Debian suggests either forwarding the removal upstream,
or keeping the unused copy, not repacking to remove the copy. Some
folks repack anyway to avoid the work needed documenting copyrights
and licenses, although there are tools to automate that process now.

https://wiki.debian.org/CopyrightReviewTools

> (I realize not much hangs on this - but cme/licensecheck raised the issue to
> me.  I can ignore it, but also got curious and tried to figure out what to 
> do.)

What issue did it print? Which package/code is this about BTW?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: d/copyright entries for licenses and copyright data

[Ross Vandegrift]

Hi Richard,

On Tue, Jan 02, 2024 at 10:31:23PM -0600, Richard Laager wrote:
> I document them the same, except that I also add use the DEP-5 "Comment"
> field to indicate that it came from "B".

That's a nice idea.  If I claim my software distribution is licensed under the
GPL, then it's natural to think I mean all of the software distribution.
Simple way to represent what project B probably intended.

(I realize there's also something fishy - that GPL isn't really under the GPL -
but IANAL and this is still better than I'd thought of before.)

Ross

Re: d/copyright entries for licenses and copyright data

[Ross Vandegrift]

Hi Paul,

On Sat, Jan 06, 2024 at 01:12:50PM +0800, Paul Wise wrote:
> On Mon, 2024-01-01 at 13:16 -0800, Ross Vandegrift wrote:
> 
> > Suppose project A includes code from project B.
> 
> The best option would be to talk to upstream about removing the copy,
> further advice about embedded copies is on the wiki:
> 
> https://wiki.debian.org/EmbeddedCopies

Definitely agreed in general.  I had a different kind of situation in mind.

Imagine I take some code from a freely licensed reference implementation and
customize it.  The result is a derived work.  But this embedding isn't
removable - the reference implementation shouldn't accept changes to integrate
it into a specific project.  It'd be reasonable to include the original license
and copyright statements.

If I do, Debian requires packagers to describe the license and copyright on
those embedded license/copyright files.  And I'm puzzled about how to do that
best.

Maybe the answer is to repack it away?  But that seems weird.  It's freely
redistributable, and that'd be *obscuring* license/copyright details.  We
usually like that. :)

The same issue arises for disabled conveience copies.  The wiki suggests
Files-Excluded, but also alternatives that involve Debian redistributing the
convenience copy (and so probably it's license/copyright files) in source
packages.


(I realize not much hangs on this - but cme/licensecheck raised the issue to
me.  I can ignore it, but also got curious and tried to figure out what to do.)

> > How should these files appear in d/copyright?
> > (Please CC me, I'm not subscribed.)
> 
> Richard Laager responded but forgot to CC you, I bounced the message:
> 
>I document them the same, except that I also add use the DEP-5 "Comment"
>field to indicate that it came from "B".

Thanks!

Ross


signature.asc
Description: PGP signature

Re: d/copyright entries for licenses and copyright data

[Paul Wise]

On Mon, 2024-01-01 at 13:16 -0800, Ross Vandegrift wrote:

> Suppose project A includes code from project B.

The best option would be to talk to upstream about removing the copy,
further advice about embedded copies is on the wiki:

https://wiki.debian.org/EmbeddedCopies

> How should these files appear in d/copyright?
> (Please CC me, I'm not subscribed.)

Richard Laager responded but forgot to CC you, I bounced the message:

   I document them the same, except that I also add use the DEP-5 "Comment"
   field to indicate that it came from "B".

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: d/copyright entries for licenses and copyright data

[Richard Laager]

I document them the same, except that I also add use the DEP-5 "Comment" 
field to indicate that it came from "B".


--
Richard



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1053672: Apple copyright notices in test .xlsx files

[Paul Wise]

On Sun, 2023-10-08 at 15:04 +0100, Rebecca N. Palmer wrote:

> Given this, why is that copyright notice there, and what does it imply 
> that we should do?  (E.g. does Apple Numbers automatically copy 
> Apple-owned items (e.g. fonts) into files it creates?  If so, is there a 
> way to remove these items to get a Free file?)

*.xlsx files are actually just *.zip files containing XML and other
files. The Apple copyright for both of the files you mention comes from
the Apple copyright listed for the ICC profile embedded in the EXIF
data in the JPEG file that was saved as a thumbnail of the spreadsheet.

I am not sure what that means for the license of the test cases in
openpyxl and but it would be easy to fix by either deleting the
thumbnail, or removing the ICC profile, but that would alter the test
cases, probably that wouldn't affect the tests passing/failing though.

$ unzip conditional-formatting.xlsx 
Archive:  conditional-formatting.xlsx
  inflating: [Content_Types].xml 
  inflating: _rels/.rels 
  inflating: xl/_rels/workbook.xml.rels  
  inflating: xl/workbook.xml 
 extracting: docProps/thumbnail.jpeg  
  inflating: xl/theme/theme1.xml 
  inflating: xl/styles.xml   
  inflating: xl/worksheets/sheet1.xml  
  inflating: docProps/core.xml   
  inflating: docProps/app.xml

$ grep -ri apple
grep: conditional-formatting.xlsx: binary file matches
grep: docProps/thumbnail.jpeg: binary file matches

$ exiftool docProps/thumbnail.jpeg | grep -i apple
Profile CMM Type: Apple Computer Inc.
Primary Platform: Apple Computer Inc.
Device Manufacturer : Apple Computer Inc.
Profile Creator : Apple Computer Inc.
Profile Copyright   : Copyright 2007 Apple Inc., all rights 
reserved.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: License violations for dependencies of Rust and Go programs?

[Florian Weimer]

* John Thorvald Wodder, II:

> It is my understanding that when an executable program that depends (directly
> or indirectly) on libraries licensed under (picking one license here) the MIT
> license is compiled into a binary that statically links these libraries, and
> this binary is then distributed to third parties, the binary must be
> accompanied by the license text & copyright notices for all of the program's
> direct & indirect MIT-licensed dependencies.

Based on my understanding of copyright law, this is correct.
Nevertheless, there seems to be an emerging consensus throughout the
industry that (for example) mentioning the “MIT” SPDX license
identifier is sufficient to meet the notification requirement inherent
to the MIT license.

> Unfortunately, I've come across some software in the official Debian
> repositories that do not seem to properly honor these requirements.

This conclusion is incorrect for Debian, I would say.  In Debian's
case, notification requirements are primarily met by shipping full
source code for the entire distribution.  I'm aware of heroic efforts
to maintain debian/copyright files, but as you point out, they are
incomplete when viewed in isolation because they only reflect a
source-only view.

Personally, I do not think this is an issue.  Debian does not need to
enable binary-only redistribution in cases where licenses may permit
it (Of course, there are plenty of cases where binary-only
distribution is not allowed by applicable licenses anyway.)  I don't
see how it furthers Debian's goals, and it only helps a tiny subset of
Debian users.

Re: License violations for dependencies of Rust and Go programs?

[Paul Wise]

On Wed, 2023-09-27 at 10:41 -0400, John Thorvald Wodder II wrote:

> So was this problem previously known but under-acknowledged, or was it simply
> not brought up before now?  I find it surprising that Debian would allow so
> many license violations to get this far.  Is fixing the tooling to handle this
> considered a priority?  If the author of an uncredited dependency were to
> complain, would Debian be more likely to focus on fixing the tooling posthaste
> or to just pull whatever packages use the dependency in question?

This is the first time this problem was brought up in Debian AFAICT.
Likely no-one thought about it because we are used to dynamic linking,
which doesn't have this problem. Several folks on different IRC
channels discussed the problem yesterday and it is possible the Rust
or Go teams might work on a debhelper addon to solve it. In theory it
could be possible to solve by copying the copyright files of static
libraries into the binary packages they are linked into, probably
using the Built-Using and Static-Build-Using fields. It will also
further bloat the binary packages of Rust/Go/etc based binaries.

We also noted that this is not just a Debian problem, but a problem
with every distro packaging statically linked stuff and with even the
upstream ecosystems, any project using static linking must deal with
this problem, so every single Rust/Go developer must deal with it.

These links point to some efforts to handle it in the Rust community:

https://github.com/rust-lang/cargo/issues/12053
https://lib.rs/crates/cargo-bundle-licenses
https://lib.rs/crates/cargo-about

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: License violations for dependencies of Rust and Go programs?

[Paul Wise]

On Wed, 2023-09-27 at 11:03 -0400, John Thorvald Wodder II wrote:

> On further inspection, it turns out that bat itself compiles the text
> of its NOTICE file into the binary, and the text is displayed when
> running `batcat --acknowledgements`, so bat's Apache 2.0 license is
> being followed.  If it's Debian policy to include the NOTICE file in
> the .deb anyway, let me know so I can file a more appropriate bug
> report.

Yes, I think we should include the NOTICE as a file too, so that users
who are looking at the Debian copyright file can find it easily.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: License violations for dependencies of Rust and Go programs?

[Mihai Moldovan]

* On 9/27/23 21:10, Sam Hartman wrote:
>> "Mihai" == Mihai Moldovan  writes:
> 
> Mihai> In this case, we're "just" talking about missing notices for
> Mihai> dependencies that are pulled in, which might not be nice, but
> Mihai> also, realistically, nobody would really care about or try to
> Mihai> enforce it (unless somebody has malicious intent, which
> Mihai> indeed did happen in the past).
> 
> I agree with your overall conclusion that in practice we are unlikely to
> have significant legal liability or cause significant damages here.
> 
> However, I disagree on one point.  You imply that you believe anyone
> complaining about a violation here would be malicious.

Let me apologize for this misunderstanding, this is not what I meant. What I
really wanted to convey was that malicious intent, aiming at causing disruption
or for personal gains, is a great concern for the Debian Project, while friendly
hints at violations are usually quickly dealt with to the satisfaction of both
sides via collective work.

Though very rare, and mostly related to patents and not licenses directly, there
have been instances of what I would call malicious intent strictly for personal
gain in the past, to which I was referring.



Mihai


OpenPGP_signature
Description: OpenPGP digital signature

Re: License violations for dependencies of Rust and Go programs?

[Sam Hartman]

> "Mihai" == Mihai Moldovan  writes:

Mihai> In this case, we're "just" talking about missing notices for
Mihai> dependencies that are pulled in, which might not be nice, but
Mihai> also, realistically, nobody would really care about or try to
Mihai> enforce it (unless somebody has malicious intent, which
Mihai> indeed did happen in the past).

I agree with your overall conclusion that in practice we are unlikely to
have significant legal liability or cause significant damages here.

However, I disagree on one point.  You imply that you believe anyone
complaining about a violation here would be malicious.

One of my former house mates was part of a BSD-licensed free software
project  related to a new technology.
That project cared a lot about having their code acknowledged in
supporting documentation, because they were trying to demonstrate wide
adoption of their technology.
It significantly impacted their ability to raise money  and impacted
their satisfaction with their work to be able to demonstrate all the
wide variety of products that incorporated their technology.

I don't think they sued (or would consider doing that) when not
credited, but it did do emotional and possibly economic harm to them
when dependencies did not credit them.

If someone like that came to Debian and asked us to do a better job of
crediting them, I would not consider that malicious at all.

Re: License violations for dependencies of Rust and Go programs?

[Mihai Moldovan]

* On 9/27/23 16:41, John Thorvald Wodder II wrote:
> On 2023 Sep 26, at 20:36, Paul Wise  wrote:
>> Your analysis is correct, some extra context for this problem:
>>
>> The problem you have identified applies to other statically linked
>> languages too, so I have updated the wiki page to link to it.
>>
>> https://wiki.debian.org/StaticLinking
> 
> So was this problem previously known but under-acknowledged, or was it simply
> not brought up before now?  I find it surprising that Debian would allow so
> many license violations to get this far.

The reason is likely a lot more mundane: it's terribly difficult to get license
information right (and to comply with licensing terms verbatim) in such cases.

When just linking in a shared fashion, the work is split up into small,
manageable packages, and every package that depends on another package needs not
care about the other dependencies (as long as one knows that they are 
compatible).

Static linking is a beast.

Rather, I'd wager that it's important for maintainers to provide the software in
question at all than to delve into such issues for extended periods of time.

The severity of the issue is also very debatable. If it were the case that
non-free parts are mixed with free parts and statically linked, or incompatible
licenses mixed through static linking, than that would be a much graver concern.

In this case, we're "just" talking about missing notices for dependencies that
are pulled in, which might not be nice, but also, realistically, nobody would
really care about or try to enforce it (unless somebody has malicious intent,
which indeed did happen in the past).


Richard Laager wrote a beautiful statement on this list a few months ago, albeit
regarding a different matter, which I want to quote:

> Furthermore, courts are not robots blindly executing code. Seriously, 
> can you imagine standing in court trying to argue to a judge that this 
> distinction matters and somehow causes you damage‽


This also extends to Sam Hartman:

> Sometimes the best approach to licensing is to take a defensible 
> position and not to try and find problems.



> Is fixing the tooling to handle this
> considered a priority?  If the author of an uncredited dependency were to
> complain, would Debian be more likely to focus on fixing the tooling posthaste
> or to just pull whatever packages use the dependency in question?

If someone were to complain and the complain were to be rightful, the easiest
way to handle the situation would be to remove the affected packages from the
archives. Fixing it properly would take more time.

Truth be told, in my opinion, this whole thing is a bit blown out of proportion.
The real-world implications are minimal, and while it does make sense to rectify
the blunders that probably exist, it feels more like a trade-off between a very
complicated situation that binds maintainer's time tightly (particularly because
no automated solution exists and manual intervention for packages with hundreds
of dependencies that are then statically linked is a time drain nightmare) for
minimal benefits of having it gotten it done absolutely waterproof.

Which is not to say that slips shouldn't be eventually fixed - it does make
sense to actually point them out and to start working on them.



Mihai


OpenPGP_signature
Description: OpenPGP digital signature

Re: License violations for dependencies of Rust and Go programs?

[John Thorvald Wodder II]

On 2023 Sep 26, at 22:09, Paul Wise  wrote:
> 
> On Tue, 2023-09-26 at 14:20 -0400, John Thorvald Wodder II wrote:
> 
>> - bat (In addition to the type of problem discussed above, the source code 
>> for
>>   bat has an Apache 2.0 `NOTICE` file, yet this is not included in the .deb
>>   package.)
> 
> Please file a severity serious bug report against bat about the NOTICE
> issue, I've mentioned it on the #debian-rust IRC channel though.
> 
> https://www.debian.org/Bugs/Reporting
> 
> I note that lintian detects the NOTICE issue, so I have requested that
> the ftp-master team turn on auto-rejections for the lintian tag.

On further inspection, it turns out that bat itself compiles the text of its 
NOTICE file into the binary, and the text is displayed when running `batcat 
--acknowledgements`, so bat's Apache 2.0 license is being followed.  If it's 
Debian policy to include the NOTICE file in the .deb anyway, let me know so I 
can file a more appropriate bug report.

-- John Wodder

Re: License violations for dependencies of Rust and Go programs?

[John Thorvald Wodder II]

On 2023 Sep 26, at 20:36, Paul Wise  wrote:
> Your analysis is correct, some extra context for this problem:
> 
> The problem you have identified applies to other statically linked
> languages too, so I have updated the wiki page to link to it.
> 
> https://wiki.debian.org/StaticLinking

So was this problem previously known but under-acknowledged, or was it simply
not brought up before now?  I find it surprising that Debian would allow so
many license violations to get this far.  Is fixing the tooling to handle this
considered a priority?  If the author of an uncredited dependency were to
complain, would Debian be more likely to focus on fixing the tooling posthaste
or to just pull whatever packages use the dependency in question?

-- John Wodder

Re: License violations for dependencies of Rust and Go programs?

[Paul Wise]

On Wed, 2023-09-27 at 05:24 +, Stephan Verbücheln wrote:

> Are the upstream developers not already legally required to include all
> this information into various places including their “Help-About” menu?

It is definitely not common practice to document the copyright/license
info of dependencies in about dialogs. Sometimes it happens in the
build documentation in the source package but not always and that
usually isn't distributed in the binary package.

In distributions like Debian, usually programs dynamically link their
dependencies so the copyright/license info of dependencies accompanies
the binaries of the dependencies instead of the programs. Then the
dependency information plus the individual package copyright info
ensures that the license information for all components is present.

It is only because of static linking that the issue you mention arises.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: License violations for dependencies of Rust and Go programs?

[Stephan Verbücheln]

On Wed, 2023-09-27 at 08:36 +0800, Paul Wise wrote:
> This more general problem is very hard to impossible to solve,
> since it would mean patching every single build toolchain and
> source package [...]

Are the upstream developers not already legally required to include all
this information into various places including their “Help-About” menu?

Regards
Stephan


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

Re: License violations for dependencies of Rust and Go programs?

[Paul Wise]

On Tue, 2023-09-26 at 14:20 -0400, John Thorvald Wodder II wrote:

> - bat (In addition to the type of problem discussed above, the source code for
>   bat has an Apache 2.0 `NOTICE` file, yet this is not included in the .deb
>   package.)

Please file a severity serious bug report against bat about the NOTICE
issue, I've mentioned it on the #debian-rust IRC channel though.

https://www.debian.org/Bugs/Reporting

I note that lintian detects the NOTICE issue, so I have requested that
the ftp-master team turn on auto-rejections for the lintian tag.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: License violations for dependencies of Rust and Go programs?

[Paul Wise]

On Tue, 2023-09-26 at 14:20 -0400, John Thorvald Wodder II wrote:

> I suspect that this problem applies to all programs written in Go or Rust that
> Debian distributes.  Is Debian handling dependency licenses for these packages
> incorrectly, or is there something I'm missing?

Your analysis is correct, some extra context for this problem:

The problem you have identified applies to other statically linked
languages too, so I have updated the wiki page to link to it.

https://wiki.debian.org/StaticLinking

The problem can be more generally stated as; Debian aggregates the
copyright and license of source files we distribute but does not trace
the path from source files to compiled files, and therefore does not
trace which source files each generated file was created from and as a
subset of that problem, does therefore not trace the flow of copyright
and license information and does not aggregate that information and
does not discover license incompatibilities in the generated files.

This more general problem is very hard to impossible to solve, since it
would mean patching every single build toolchain and source package to
provide traces of the path from source files to compiled files and then
processing those traces to generate copyright info for binary packages.

The specific problem with Rust/Go/etc static linking might be solvable
by a new debhelper command that would read the Built-Using and related
fields and then append each of them to the DEBIAN/copyright files.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Bug#903999: RFC about DFSG-freeness of PHP license [Re: Bug#903999: ITP: php-doc -- Documentation for PHP]

[Sergio Durigan Junior]

Hello,

Disclaimer: I am not a lawyer and this is not legal advice.

I talked extensively to Athos during DebConf and, after looking at the
multiple licenses and nuances involved in this problem I believe:

1) Athos followed precisely the instructions from ftp-masters
(https://ftp-master.debian.org/php-license.html).  He also followed the
good practices pointed by Lintian.

2) IMO, it is possible to argue that php-doc is actually part of PHP
itself, judging by the fact that the project is hosted under the PHP
umbrella on the Microsoft Github repository.  If that's the case, then I
agree with Athos that we should extend the Lintian warning.

3) Ultimately, it is the ftp-master's job to determine whether php-doc's
license is suitable for Debian or not.  I don't think it's
necessary/beneficial to extend this discussion here.

Having said that, I will review and sponsor the package for Athos.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Re: Bug#1029842: ITP: randombytes -- Library generating fresh randomness

[Simon Josefsson]

Sam Hartman  writes:

>> "Jan" == Jan Mojzis  writes:
>
> * Package name: randombytes
>   Version : 20230126
>   Upstream Author : Daniel J. Bernstein
> * URL : https://randombytes.cr.yp.to/
> * License : Public domain
>
> Public domain is problematic  as a license.
> At least under US copyright law, there are very few circumstances when
> something can actually be public domain.
> One example is software written by US government employees.
> But I don't think any of those circumstances apply to this library.
> So I'm not sure the license is okay.

We have plenty of code written under that same license from the same
group of authors, already in Debian.  Look in OpenSSH and OpenSSL for
example.  So I would disagree there is a license problem having this
package in Debian.

Jan, I'm happy to help review, sponsor and co-maintain randombytes if
you are interested.  I rely on it as a dependency in some projects I'm
working on.

/Simon


signature.asc
Description: PGP signature

Re: NetData violating DFSG, nonfree?

[Paul Wise]

On Thu, 2023-08-24 at 13:56 +, Marius Gripsgard wrote:

> Could someone review this? 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1045145

On the question of missing source code, looking at the Debian source
package, all the CSS and JavaScript (except that embedded in the HTML)
is minified and there is evidence that some of the minified JavaScript
is from dependencies, under various licenses, including GPLv3.

The same applies to the v1 web gui too.

In addition there is this ominous notice in the v2 README.md file:

   # Do not edit any files in this directory!
   
   If you spot any errors or bugs in these files please open a bug report
   at https://github.com/netdata/netdata/issues/new/choose.
   
   These files are maintained in a seprate private repository and copied
   here when they are updated there, so any changes made in this directory
   will eventually be overwritten.

Similarly the v1 README.md says this:

   # Do not edit any files in this directory!
   
   If you spot any errors or bugs in these files and wish to fix them,
   please submit your changes at
   https://github.com/netdata/dashboard instead.
   
   These files are copied from the most recent release of that repository,
   and any changes you make here will be
   overwritten the next time there’s a new release there.

I think that the netdata web guis should not be in Debian like this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: NetData violating DFSG, nonfree?

[Paul Wise]

On Fri, 2023-08-25 at 11:35 +0800, Paul Wise wrote:

> ## Acceptance
> By using the software, you agree to all of the terms and conditions
> below.

This is icky, not sure about DFSG compliance.

> ## Copyright License
> The licensor grants you a non-exclusive, royalty-free, worldwide, non-
> sublicensable, non-transferable license to use, copy, distribute, make
> available the software, in each case subject to the limitations,
> restrictions and conditions below.

Does not allow modifications, fails DFSG item 3.

> ## Limitations
> This license allows you to use the Software only to interface with the
> licensor's other software components, such as Netdata Agents and
> Netdata Cloud. Any use with replacements for these components is not
> permitted.

Discriminates against Netdata competitors, fails DFSG item 6.

> ## Restrictions
> The Software is provided in a binary form for use by end-users. You may
> not reverse engineer, decompile, disassemble, or modify the Software.
> The Software is licensed as a single product and its component parts
> may not be separated.

Not distributing source code, fails DFSG item 2.

The restrictions seem like they fail DFSG item 6.


-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: NetData violating DFSG, nonfree?

[Paul Wise]

On Thu, 2023-08-24 at 13:56 +, Marius Gripsgard wrote:

> Could someone review this? 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1045145

Here is a copy of the license for the list archives:

# Netdata Cloud UI License v1.0 (NCUL1)

## Acceptance
By using the software, you agree to all of the terms and conditions
below.

## Copyright License
The licensor grants you a non-exclusive, royalty-free, worldwide, non-
sublicensable, non-transferable license to use, copy, distribute, make
available the software, in each case subject to the limitations,
restrictions and conditions below.

## Limitations
This license allows you to use the Software only to interface with the
licensor's other software components, such as Netdata Agents and
Netdata Cloud. Any use with replacements for these components is not
permitted.

## Restrictions
The Software is provided in a binary form for use by end-users. You may
not reverse engineer, decompile, disassemble, or modify the Software.
The Software is licensed as a single product and its component parts
may not be separated.

## Patents
If you or your company make any written claim that the software
infringes or contributes to infringement of any patent, your license
for the software granted under these terms ends immediately. If your
company makes such a claim, your license ends immediately for work on
behalf of your company.

## Notices
You must ensure that anyone who gets a copy of the Software from you
also gets a copy of these terms.

## No Other Rights
These terms do not imply any licenses other than those expressly
granted in these terms.

## Termination
If you use the Software in violation of any of these terms, such use is
not licensed, and your licenses will automatically terminate. If the
licensor provides you with a notice of your violation, and you cease
all violations of this license no later than 30 days after you receive
that notice, your licenses will be reinstated retroactively. However,
if you violate these terms after such reinstatement, any additional
violation of these terms will cause your licenses to terminate
automatically and permanently.

## No Warranties and No Liability
The software comes "As Is", without any express or implied warranties
of any kind, including but not limited to any warranties of
merchantability, non-infringement, or fitness for a particular purpose.
The licensor will not be liable to you for any damages arising out of
these terms or the use or nature of the Software, under any kind of
legal claim.

## Open Source Components
The software includes certain third party open source components. Each
of these components is subject to its own license. The list of open-
source components used by Netdata Cloud UI is
[here](https://app.netdata.cloud/3D_PARTY_LICENSES.txt).

## Definitions
The "licensor" is Netdata Inc., the entity offering these terms, and
the "**software**" is the Netdata Cloud UI software the licensor makes
available under these terms, including any portion of it.

"**you**" refers to the individual or entity agreeing to these terms.

"**your company**" is any legal entity, sole proprietorship, or other
kind of organization that you work for, plus all organizations that
have control over, are under the control of, or are under common
control with that organization. "**Control**" means ownership of
substantially all the assets of an entity, or the power to direct its
management and policies by vote, contract, or otherwise. Control can be
direct or indirect.

"**your licenses**" are all the licenses granted to you for the
software under these terms.

"**use**" means anything you do with the software requiring one of your
licenses.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: NetData violating DFSG, nonfree?

[Sam Hartman]

> "Marius" == Marius Gripsgard  writes:

Marius> Hi, Could someone review this?
Marius> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1045145

I have read the bug, but not looked into the claims in the bug:

* The v2 dashboard is distributed under a new license
* That license only permits the software to be used to contact their
* service.

If these two claims are true, then that is a DFSG violation.
Similarly, distributing the minimified version of the v2 dashboard or
the v1 dashboard without full source is also definitely a DFSG
violation.


signature.asc
Description: PGP signature

Re: Re: Here

[manuel]

Manuel Reyes 5685

Re: BSD-3-Clause-Attribution GPL Compatibility

[Sam Hartman]

> "Richard" == Richard Laager  writes:


Richard> Furthermore, courts are not robots blindly executing
Richard> code. Seriously, can you imagine standing in court trying
Richard> to argue to a judge that this distinction matters and
Richard> somehow causes you damage‽

I agree with your analysis (in the entire message, not just the part I
quoted).

Re: SWIFTStandards IPR Policy

[Mathias Behrle]

* Walter Landry: " Re: SWIFTStandards IPR Policy" (Tue, 04 Jul 2023 09:39:49
  -0700):

Hi Walter,

thanks for your feedback.

> Mathias Behrle  writes:
> > 2. License
> > SWIFT hereby grants you a world-wide, royalty-free, non-exclusive license to
> > use or promote SWIFTStandards (i) for information transmission purposes in
> > or outside the context of SWIFT messaging services and/or (ii) to develop
> > software, products or services which support transmission of information in
> > accordance with SWIFTStandards.  
> 
> This feels funny.  It does not allow users to use SWIFTStandards to
> advocate against SWIFTStandards.  As written, you can not even use it to
> improve the standard.  Users also can not use it in unexpected ways,
> such as an art piece.
> 
> > 3. Limitations
> > You may not directly or indirectly sell SWIFTStandards. You may not modify
> > SWIFTStandards while maintaining “SWIFTStandards” as a reference for the
> > modified standard. This License Agreement does not grant you a license to
> > use any of SWIFT’s trademarks, except the trademark “SWIFTStandards” for
> > the use as defined in Section 2.  
> 
> I think this would preclude putting SWIFTStandards on a DVD and selling
> it.  It is not directly selling SWIFTStandards, but it is indirectly
> selling it.  
> 
> So I do not think it passes the DFSG.

I agree.

> It would be suitable for non-free.  IANADD.  IANAL.  YMMV.

I am even not sure if the package qualifies for non-free because the files
in question are currently distributed by Tryton upstream *without* resp.
under a *wrong* license.

The feedback on the issue is unfortunately poor
https://foss.heptapod.net/tryton/tryton/-/issues/12304#note_300126

I think I will move to a dfsg package excluding those files and disabling
the tests (which is obviously a pity).

Cheers,
Mathias


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Re: SWIFTStandards IPR Policy

[Walter Landry]

Mathias Behrle  writes:
> 2. License
> SWIFT hereby grants you a world-wide, royalty-free, non-exclusive license to
> use or promote SWIFTStandards (i) for information transmission purposes in or
> outside the context of SWIFT messaging services and/or (ii) to develop
> software, products or services which support transmission of information in
> accordance with SWIFTStandards.

This feels funny.  It does not allow users to use SWIFTStandards to
advocate against SWIFTStandards.  As written, you can not even use it to
improve the standard.  Users also can not use it in unexpected ways,
such as an art piece.

> 3. Limitations
> You may not directly or indirectly sell SWIFTStandards. You may not modify
> SWIFTStandards while maintaining “SWIFTStandards” as a reference for the
> modified standard. This License Agreement does not grant you a license to use
> any of SWIFT’s trademarks, except the trademark “SWIFTStandards” for the use 
> as
> defined in Section 2.

I think this would preclude putting SWIFTStandards on a DVD and selling
it.  It is not directly selling SWIFTStandards, but it is indirectly
selling it.  

So I do not think it passes the DFSG.  It would be suitable for
non-free.  IANADD.  IANAL.  YMMV.

Cheers,
Walter Landry

Re: mini-httpd NCSA license

[Richard Laager]

On 2023-07-02 16:43, Alexandru Mihail wrote:

mini-httpd contains early portions of code commited by Rob
McCool which seem to originate from NCSA httpd.


Just htpasswd.c (which is what I get when searching for Rob McCool), or 
something else?



How do we proceed to clarify this situation?


Figure out (from the history of the code, etc.) if that license applies.

Looking into this a bit, I found this repository (which I am _assuming_, 
but have not verified, is a faithful import of NCSA httpd):

https://github.com/TooDumbForAName/ncsa-httpd/

I definitely see some code from mini-httpd's htpasswd.c in 
cgi-src/util.c in the HEAD of that repository above.


Looking at git blame on that, it came from auth/htpasswd.c in httpd 1.1:
https://github.com/TooDumbForAName/ncsa-httpd/commit/9572b626b7f10ab57e4715b3f3ff41b3f0696684#diff-7c5a48b0225b3fd1048000f4dfe2c4d9f56faa29f74876ff724384244d6d099d

So that seems to be the original source of the code in question.

In that same version, the top-level README says:


This code is in the public domain. Specifically, we give to the public
domain all rights for future licensing of the source code, all resale
rights, and all publishing rights.

We ask, but do not require, that the following message be included in
all derived works:

Portions developed at the National Center for Supercomputing
Applications at the University of Illinois at Urbana-Champaign.

THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
PARTICULAR PURPOSE.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Re: Nethack General Public License

[MJ Ray]

Le 28 juin 2023 16:25:09 GMT+01:00, Joshua Allen  a écrit :
>Dear Debian Legal,
>
>I was going through the Nethack General Public License and even though it is a 
>free software license obviously not compatible with the GNU GPL, how do you 
>maintain it without calling it nethack though since the only official nethack 
>releases can be called nethack. If you were to append the same license on top 
>of the NGPL but remove references to nethack, it would still qualify because 
>the terms are the same im just changing the name of the program derivative.

I don't see the problem with maintaining it. You do not have to remove 
references to nethack. You only cannot call other things nethack inaccurately.

Hope that explains,
-- 
MJR

Re: advice on non-free NXP Software License Agreement

[Sam Hartman]

> "Johannes" == Johannes Schauer Marin Rodrigues  writes:
>> In such situations we have sometimes had success reaching out to
>> companies and negotiating something.

Johannes> Who is usually doing this reaching out? Individual DDs
Johannes> like myself or official representatives like the DPL?

I think for Nvidia it was individual DDs a long time ago.
Asking the DPL for help is certainly reasonable, and if you need legal
resources to review an agreement Debian can in theory help with that.
Although the turn around time for actual lawyer review has how shall we
say been variable for a variety of factors.

Johannes> The non-free binary blobs covered by this license apply to
Johannes> popular platforms like the IMX8MQ (which is used by the
Johannes> purism librem5 phone and the mnt reform laptop) as well as
Johannes> anything with a cadence edp chip like the LS2028A.

I'd reach out to DDs working for Purism and see if they have any advice
and how they approached this.
They may already have a contact.

Re: advice on non-free NXP Software License Agreement

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Sam Hartman (2023-06-22 16:46:51)
> > "Johannes" == Johannes Schauer Marin Rodrigues  
> > writes:
> 
> Johannes> Dear Debian legal, I seek advice on the NXP Software
> Johannes> License Agreement and whether binaries licensed under it
> Johannes> are redistributable in non-free(-firmware) or not. The
> Johannes> full text is at the end of this email. I think the
> Johannes> interesting parts are in 2.1, 2.2 and 2.3. If I'm reading
> Johannes> this correctly, then this means that Debian is not allowed
> Johannes> to distribute work under this license.
> 
> That's my reading as well.
> We might be able to distribute precompiled binaries under section 2.3,
> but not source, and I don't know what is involved in getting the
> permissions under 2.3 to apply.

thank you, Sam!

> In such situations we have sometimes had success reaching out to
> companies and negotiating something.

Who is usually doing this reaching out? Individual DDs like myself or official
representatives like the DPL?

The non-free binary blobs covered by this license apply to popular platforms
like the IMX8MQ (which is used by the purism librem5 phone and the mnt reform
laptop) as well as anything with a cadence edp chip like the LS2028A.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Expat license and "free for academic users"

[Andrius Merkys]

Hi all,

Thank you for your prompt responses.

On 2023-06-22 17:49, Sam Hartman wrote:

I mean under xpat, it's certainly free for academic users, and it's also
free for everyone else.

Unless that statement in the readme is in a section called license or
otherwise claims to be a license, I'd treat it as xpat and move on with
life.


The "free to academic users" comment is in "COPYRIGHT & CONTACT" section 
of a readme file.



Sometimes the best approach to licensing is to take a defensible
position and not to try and find problems.


Just to clarify: does this mean one should avoid ambiguous licenses?

Best wishes,
Andrius

Re: Expat license and "free for academic users"

[Sam Hartman]

> "Andrius" == Andrius Merkys  writes:

Andrius> Hello, [Please keep me in CC, I am not subscribed]

Andrius> I encountered a package EvoEF2 [1] which is licensed under
Andrius> Expat and has the following in its README.md:

Andrius> "EvoEF2 is free to academic users."

Andrius> To me such limitation seems to contradict the Expat
Andrius> license, but I wonder what is the legal opinion about such
Andrius> combination. I know that I can always ask the upstream for
Andrius> clarification which I did earlier when the restriction was:

I mean under xpat, it's certainly free for academic users, and it's also
free for everyone else.

Unless that statement in the readme is in a section called license or
otherwise claims to be a license, I'd treat it as xpat and move on with
life.
Sometimes the best approach to licensing is to take a defensible
position and not to try and find problems.

Re: advice on non-free NXP Software License Agreement

[Sam Hartman]

> "Johannes" == Johannes Schauer Marin Rodrigues  writes:

Johannes> Dear Debian legal, I seek advice on the NXP Software
Johannes> License Agreement and whether binaries licensed under it
Johannes> are redistributable in non-free(-firmware) or not. The
Johannes> full text is at the end of this email. I think the
Johannes> interesting parts are in 2.1, 2.2 and 2.3. If I'm reading
Johannes> this correctly, then this means that Debian is not allowed
Johannes> to distribute work under this license.

That's my reading as well.
We might be able to distribute precompiled binaries under section 2.3,
but not source, and I don't know what is involved in getting the
permissions under 2.3 to apply.

In such situations we have sometimes had success reaching out to
companies and negotiating something.

Re: Expat license and "free for academic users"

[Nicholas D Steeves]

Francesco Poli  writes:

> On Tue, 20 Jun 2023 10:14:41 +0300 Andrius Merkys wrote:
>> 
>> [Please keep me in CC, I am not subscribed]
>> 
>> I encountered a package EvoEF2 [1] which is licensed under Expat and has 
>> the following in its README.md:
>> 
>> "EvoEF2 is free to academic users."
>> 
>> To me such limitation seems to contradict the Expat license, but I 
>> wonder what is the legal opinion about such combination. I know that I 
>> can always ask the upstream for clarification which I did earlier when 
>> the restriction was:

1. EvoEF2 is licensed Expat
2. Expat makes EvoEF2 free for all users
3. "EvoEF2 is free to academic users."
4. I am a[n] [academic] user
5. EvoEF2 is free for me.

#3 is redundant because it is a subset of #2.

vs

1. EvoEF2 is licensed Expat
2. Expat makes EvoEF2 free for all users
3. "EvoEF2 is free to academic users."
4. I am a [commercial or nonacademic] user
5. EvoEF2 is free for me.

At #2, all users, includes nonacademic, commercial, etc.  #3 becomes an
editorial: a statement of the anticipated audience and nothing more.

> Well, take into account that I am not a lawyer.

I'm also not a lawyer and this is not legal advice.

> Anyway, to me, the sentence "EvoEF2 is free to academic users." looks
> a little misleading.

Agreed.

> One could nitpick that the sentence is not false: it's true that EvoEF2
> is free to academic users, since it's released under the Expat license,
> and therefore it's free to everyone, including academic users.
>
> However, the sentence may make the reader think that EvoEF2 is free
> _only_ to academic users, although it does not say so.

I agree that this is the important part!  It seems legally nonbinding to
me, and not nice to the reader.

Also, I think it would be a stretch to successfully argue that the
antecedent of a redundant statement in the README somehow acts as an
addendum to the LICENSE, such that the license is no longer Expat.
Maybe there are some parts of the world were this is how an addendum
works, but I think the additional statements usually need to be
explicitly defined as such. ie: "This is an addendum to the LICENSE...I
limit the LICENSE in the following way...".

> I would suggest to once again get in touch with upstream and persuade
> them to drop that sentence, or perhaps to replace it with something
> like "EvoEF2 is free to all users."

Agreed!  On the other hand, if the author intends to forbid commercial
use, then the license should say so.  While not great for the community,
that may also be what the author wishes for...

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Possible GPL violation

[Daniel Hakimi]

You are allowed to modify works licensed under the GPL. You are not allowed
to modify the GPL itself.

On Tue, Jun 20, 2023, 21:27 Joshua Allen  wrote:

> In the debian manual, it says
>
> "This manual is free software; you may redistribute it and/or modify it
> under
> the terms of the GNU General Public License. Please refer to the license in
> Appendix F, GNU General Public License."
>
> It then includes verbatim the license which says
>
> "Appendix F. GNU General Public License
>
> Version 2, June 1991
>
> Copyright (C) 1989, 1991 Free Software Foundation, Inc.
> 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
>
> Everyone is permitted to copy and distribute verbatim copies
> of this license document, but changing it is not allowed."
>
> Since the GPL cannot be changed or modified, henceforth there is a
> contradiction that goes against the GPL by including the very wording of
> the form license.
>
> Because of this, the debian should consider removing the form license.
> Or relicense the manual under the GFDL and putting Appendix F under an
> invariant section, which I doubt since Debian doesnt consider the GFDL
> with invariant clauses to be free documentation.
>
>

Re: Expat license and "free for academic users"

[Francesco Poli]

On Tue, 20 Jun 2023 10:14:41 +0300 Andrius Merkys wrote:

> Hello,

Hi!

> 
> [Please keep me in CC, I am not subscribed]

Done.

> 
> I encountered a package EvoEF2 [1] which is licensed under Expat and has 
> the following in its README.md:
> 
> "EvoEF2 is free to academic users."
> 
> To me such limitation seems to contradict the Expat license, but I 
> wonder what is the legal opinion about such combination. I know that I 
> can always ask the upstream for clarification which I did earlier when 
> the restriction was:
> 
> "... unauthorized copying of the source code files via any medium is 
> strictly prohibited."
> 
> However, I am interested in the legal meaning of the current situation.
> 
> [1] https://github.com/tommyhuangthu/EvoEF2
> [2] https://github.com/tommyhuangthu/EvoEF2/issues/1

Well, take into account that I am not a lawyer.

Anyway, to me, the sentence "EvoEF2 is free to academic users." looks
a little misleading.

One could nitpick that the sentence is not false: it's true that EvoEF2
is free to academic users, since it's released under the Expat license,
and therefore it's free to everyone, including academic users.

However, the sentence may make the reader think that EvoEF2 is free
_only_ to academic users, although it does not say so.

I would suggest to once again get in touch with upstream and persuade
them to drop that sentence, or perhaps to replace it with something
like "EvoEF2 is free to all users."

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


pgp4iS7ux53zG.pgp
Description: PGP signature

Re: Fonts that must be purchased - nonfree?

[Sebastian Crane]

Dear Bagas,

I thought Klim Type Foundry had really lost it until I realised that an error in
their website made my browser replace all their 'Helvetica-inspired' fonts with
Bitstream Vera Serif!

On Sun, Jun 11, 2023 at 08:37:06PM +0700, Bagas Sanjaya wrote:
> For the background: The foodb upstream uses non-free (commercial) Söhne font,
> for which the upstream has bought and acquired appropriate licenses for the
> package purpose, and I was about to package it for Debian including the
> font. He probably chooses Söhne because there is no suitable free fonts that
> provide the same or similar typographical features as Söhne do (and partly due
> to ChatGPT influence). Hence, I was asked if the font can be distributed in
> Debian, since I had not found similar thread in debian-legal list.

I've had a look at the Söhne specimens to see if I can find a free typeface with
similar features. Söhne is definitely unique; I think the closest I've found is
Nimbus Sans L Regular. It looks pretty similar to Söhne's lower weights,
including the distinctive right-facing terminal of the 'a'. However, it's not
such a good match at heavier weights, where I would say Söhne looks more
'friendly'.

Hope this helps!

Best wishes,

Sebastian

Re: Fonts that must be purchased - nonfree?

[Bagas Sanjaya]

On 6/11/23 21:13, Jonathan Carter wrote:
> On 2023/06/11 15:37, Bagas Sanjaya wrote:
>> If I prefer to have foodb Debian package keep using non-DFSG-free Söhne,
>> do you mean I have to host the font on my server (and with my license)?
> 
> I meant that you won't be able to include it in Debian at all using the 
> non-free font. If you want to include the non-free font, or download it at 
> runtime, then you can still host the package on your own infrastructure 
> outside of Debian, if the font license permits that kind of redistribution.
> 

OK, thanks!

-- 
An old man doll... just what I always wanted! - Clara

Re: Fonts that must be purchased - nonfree?

[Jonathan Carter]

On 2023/06/11 15:37, Bagas Sanjaya wrote:

If I prefer to have foodb Debian package keep using non-DFSG-free Söhne,
do you mean I have to host the font on my server (and with my license)?


I meant that you won't be able to include it in Debian at all using the 
non-free font. If you want to include the non-free font, or download it 
at runtime, then you can still host the package on your own 
infrastructure outside of Debian, if the font license permits that kind 
of redistribution.


-Jonathan

Re: Fonts that must be purchased - nonfree?

[Bagas Sanjaya]

Hi Jonathan,

Jonathan Carter said:

> 
> * The foodb upstream has already bought the font license (in case
>of Söhne, he bought desktop and web license). If I as Debian packager
>wants to also distribute Söhne for the sake of foodb (under license
>in the name of Debian), at least both licenses and OEM license must
>also be purchased, IMO. Is both all licenses acceptable?
> 
> 
> You haven't actually shared the license text in question, so very specific 
> answers isn't possible.
> 
> 

You haven't tried buying the font from the link at the start of this thread
(and I'm not, either, because I don't have required bucks).

> * With Debian distributing this commercial font, there is a "pirating"
>loophole that someone else can extract the font files and distributing
>them freely on various sites (including torrent and shady ones) with
>Debian licensee attached. What do you think?
> 
> 
> To be included in Debian, it has to conform with the Debian Free Software 
> Guidelines:
> 
> https://www.debian.org/social_contract#guidelines
> 
> Licensing conditions like you describe above would be against DFSG#8.
> 

OK, thanks for the explanation (albeit a rather confusing to me).

For the background: The foodb upstream uses non-free (commercial) Söhne font,
for which the upstream has bought and acquired appropriate licenses for
the package purpose, and I was about to package it for Debian including
the font. He probably chooses Söhne because there is no suitable free fonts
that provide the same or similar typographical features as Söhne do (and
partly due to ChatGPT influence). Hence, I was asked if the font can be
distributed in Debian, since I had not found similar thread in debian-legal
list.

> 
> * Supposed that the foodb upstream refuses to change the font choice
>(and insists on Söhne) due to his preference when I request the
>change after reading this fact. What can I do about it?
> 
> 
> ...
>  * Host it in an external archive outside of Debian.

If I prefer to have foodb Debian package keep using non-DFSG-free Söhne,
do you mean I have to host the font on my server (and with my license)?

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Re: Fonts that must be purchased - nonfree?

[Andrew M.A. Cater]

On Sun, Jun 11, 2023 at 05:22:17PM +0700, Bagas Sanjaya wrote:
> On 6/11/23 16:37, Andrew M.A. Cater wrote:
> > On Sun, Jun 11, 2023 at 01:19:48PM +0700, Bagas Sanjaya wrote:
> >> Hi,
> >>
> >> I was stumbled on Söhne font collection, primarily due to ChatGPT
> >> uses it for its web interface. I'd like to also use it for hypothetical
> >> web app (let's name it foodb) to be packaged in Debian (due to design
> >> constraints). However, in order to acquire the font, I have to buy it [1]
> >> (buy its license). Can the font be included in Debian package of foodb
> >> (or as separate package), or is it non-free?
> >>
> > 
> > This would be permanently non-free because it couldn't be distributed
> > without individuals purchasing the fonts. Please consider using free
> > fonts that already exist within Debian / could be freely packaged and
> > distributed.
> > 
> 
> Hi Andy, thanks for the answer.
> 
> Several questions remain:
> 
> * The foodb upstream has already bought the font license (in case
>   of Söhne, he bought desktop and web license). If I as Debian packager
>   wants to also distribute Söhne for the sake of foodb (under license
>   in the name of Debian), at least both licenses and OEM license must
>   also be purchased, IMO. Is both all licenses acceptable?

That's a licence personal to him: you can't rely on it. The best thing to
do is to patch foodb and substitute a free font.
> 
> * With Debian distributing this commercial font, there is a "pirating"
>   loophole that someone else can extract the font files and distributing
>   them freely on various sites (including torrent and shady ones) with
>   Debian licensee attached. What do you think?
> 
This is *precisely* why the Debian Free Software Guidelines exist
https://wiki.debian.org/DebianFreeSoftwareGuidelines

> * Supposed that the foodb upstream refuses to change the font choice
>   (and insists on Söhne) due to his preference when I request the
>   change after reading this fact. What can I do about it?
> 

He doesn't have to change his preferences: if his code is free and you 
are free to modify it for your preferences, *you* modify it.

> Thanks.
> 
> -- 
> An old man doll... just what I always wanted! - Clara
>

With every good wish, as ever,

Andy Cater 

Re: Fonts that must be purchased - nonfree?

[Jonathan Carter]

Hi Bagas

On 2023/06/11 12:22, Bagas Sanjaya wrote:

Several questions remain:

* The foodb upstream has already bought the font license (in case
   of Söhne, he bought desktop and web license). If I as Debian packager
   wants to also distribute Söhne for the sake of foodb (under license
   in the name of Debian), at least both licenses and OEM license must
   also be purchased, IMO. Is both all licenses acceptable?


You haven't actually shared the license text in question, so very 
specific answers isn't possible.



* With Debian distributing this commercial font, there is a "pirating"
   loophole that someone else can extract the font files and distributing
   them freely on various sites (including torrent and shady ones) with
   Debian licensee attached. What do you think?


To be included in Debian, it has to conform with the Debian Free 
Software Guidelines:

https://www.debian.org/social_contract#guidelines

Licensing conditions like you describe above would be against DFSG#8.


* Supposed that the foodb upstream refuses to change the font choice
   (and insists on Söhne) due to his preference when I request the
   change after reading this fact. What can I do about it?


Your top options are probably:

 * You can choose not to package it,
 * Supply a patch in the packaging that makes it
   use another font or
 * Host it in an external archive outside of Debian.

-Jonathan

Re: Fonts that must be purchased - nonfree?

[Bagas Sanjaya]

On 6/11/23 16:37, Andrew M.A. Cater wrote:
> On Sun, Jun 11, 2023 at 01:19:48PM +0700, Bagas Sanjaya wrote:
>> Hi,
>>
>> I was stumbled on Söhne font collection, primarily due to ChatGPT
>> uses it for its web interface. I'd like to also use it for hypothetical
>> web app (let's name it foodb) to be packaged in Debian (due to design
>> constraints). However, in order to acquire the font, I have to buy it [1]
>> (buy its license). Can the font be included in Debian package of foodb
>> (or as separate package), or is it non-free?
>>
> 
> This would be permanently non-free because it couldn't be distributed
> without individuals purchasing the fonts. Please consider using free
> fonts that already exist within Debian / could be freely packaged and
> distributed.
> 

Hi Andy, thanks for the answer.

Several questions remain:

* The foodb upstream has already bought the font license (in case
  of Söhne, he bought desktop and web license). If I as Debian packager
  wants to also distribute Söhne for the sake of foodb (under license
  in the name of Debian), at least both licenses and OEM license must
  also be purchased, IMO. Is both all licenses acceptable?

* With Debian distributing this commercial font, there is a "pirating"
  loophole that someone else can extract the font files and distributing
  them freely on various sites (including torrent and shady ones) with
  Debian licensee attached. What do you think?

* Supposed that the foodb upstream refuses to change the font choice
  (and insists on Söhne) due to his preference when I request the
  change after reading this fact. What can I do about it?

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Re: Fonts that must be purchased - nonfree?

[Andrew M.A. Cater]

On Sun, Jun 11, 2023 at 01:19:48PM +0700, Bagas Sanjaya wrote:
> Hi,
> 
> I was stumbled on Söhne font collection, primarily due to ChatGPT
> uses it for its web interface. I'd like to also use it for hypothetical
> web app (let's name it foodb) to be packaged in Debian (due to design
> constraints). However, in order to acquire the font, I have to buy it [1]
> (buy its license). Can the font be included in Debian package of foodb
> (or as separate package), or is it non-free?
> 

This would be permanently non-free because it couldn't be distributed
without individuals purchasing the fonts. Please consider using free
fonts that already exist within Debian / could be freely packaged and
distributed.

Andy Cater

> Thanks.
> 
> [1]: https://klim.co.nz/buy/soehne/
> 
> -- 
> An old man doll... just what I always wanted! - Clara
> 

Re: python-sepaxml questions

[Paul Wise]

On Thu, 2023-06-01 at 15:54 +0200, Matthias Geiger wrote:

> I was working on packaging sepaxml  [1] when I ran into an issue
> where I'd appreciate some legal guidance. The source contains .xsd
> SEPA files [2] distributed by the iso committee [3] under what I
> believe to be DFSG-compliant licensing [4].
> 
> Is this indeed adhering to the DFSG ?

I don't believe that this is DFSG compliant. None of the terms I found
seem to include the right to modifications. In addition the SWIFT IPR
policy document does not let you sell the SWIFT standard.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: python-sepaxml questions

[Paul Wise]

On Fri, 2023-06-02 at 10:42 +0800, Paul Wise wrote:

>    Although the material on this site is intended to be used and reproduced 
> freely
>    by all interested users under the ISO 20022 Intellectual Property Right 
> Policy,

Here is a copy of that policy:

https://www.iso20022.org/intellectual-property-rights

   Intellectual Property Rights Policy
   
   Organizations that contribute information to be incorporated into the ISO 
20022
   Financial Repository shall keep any Intellectual Property Rights (IPR) they
   have on this information. A contributing organization warrants that it has
   sufficient rights on the contributed information to have it published in the
   ISO 20022 Repository through the Registration Authority in accordance with 
the
   rules set in the ISO 20022 standard. To ascertain a widespread, public and
   uniform use of the Financial Repository information, the contributing
   organisation grants third parties a non-exclusive, royalty-free license to 
use
   the published information.
   
   Contributing organizations can communicate their IPR policies to the RA for
   publication on this website. Received IPR policies are available for download
   hereafter.
   
 • CBI
 • SWIFT
   
   Disclaimer:
   
   Although the Registration Authority has used all reasonable efforts to ensure
   accuracy of the contents of this website and the information published 
thereon,
   the Registration Authority assumes no liability whatsoever for any 
inadvertent
   errors or omissions that may appear thereon. 
   
   Moreover, the information is provided on an "as is" basis. The Registration
   Authority disclaims all warranties and conditions, either express or implied,
   including but not limited to implied warranties of merchantability, title,
   non-infringement and fitness for a particular purpose.
   
   The Registration Authority shall not be liable for any direct, indirect,
   special or consequential damages arising out of the use of the information
   published on this website, even if the Registration Authority has been 
advised
   of the possibility of such damages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: python-sepaxml questions

[Paul Wise]

On Thu, 2023-06-01 at 15:54 +0200, Matthias Geiger wrote:

> I was working on packaging sepaxml  [1] when I ran into an issue
> where I'd appreciate some legal guidance. The source contains .xsd
> SEPA files [2] distributed by the iso committee [3] under what I
> believe to be DFSG-compliant licensing [4].
...
> [4] https://www.iso20022.org/terms-use

Here is a copy of the license for posterity:

   Terms of use
   
   This is the official ISO 20022 Website under a grant of authority and 
agreement
   with the ISO Central Secretariat.
   
   Warning:
   
   Although the material on this site is intended to be used and reproduced 
freely
   by all interested users under the ISO 20022 Intellectual Property Right 
Policy,
   all visitors of the site are hereby notified that the material contained on 
the
   site changes, is maintained and kept up to date frequently and should be the
   sole source for such information.  Any replication of this site should make 
the
   statement that theirs is not the official site and that the sole source of
   up-to-date materials and information on ISO 20022 message standards and
   Repository is https://www.iso20022.org/.
   
   Disclaimer:
   
   Although the Registration Authority has used all reasonable efforts to ensure
   accuracy of the contents of this website and the information published 
thereon,
   the Registration Authority assumes no liability whatsoever for any 
inadvertent
   errors or omissions that may appear thereon.
   Moreover, the information is provided on an "as is" basis. The Registration
   Authority disclaims all warranties and conditions, either express or implied,
   including but not limited to implied warranties of merchantability, title,
   non-infringement and fitness for a particular purpose.
   Neither the Registration Authority, nor ISO nor any of its members shall be
   liable for any direct, indirect, special or consequential damages arising out
   of the use of the information published on this website, even if the
   Registration Authority, ISO or any of its members have been advised of the
   possibility of such damages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: About distribution of modified copy of Debian OS

[Borja Sanchez]

Thanks Daniel for the quick and helpfull response.

The business focus will be the course, and the image is only a way of
having all the students begin the lessons from the same starting point.

Thanks again for your help,
sincerelly,

Borja





On Fri, May 19, 2023, 19:07 Daniel Hakimi  wrote:

> As long as you comply with the GPL, this is perfectly acceptable. Note
> that this includes making source code available and allowing licensees to
> redistribute your OS freely, so charging for your version might not be the
> most effective way go make money—I could just throw up an iso torrent for
> free—but it could work.
>
> RedHat, for example, charges for RHEL (packaged with support). CentOS was
> a famous fork that originally only changed trademarkable features (names
> and logos) and charged one vent per copy. This didn't stop RedHat from
> becoming a profitable venture, of course.
>
> On Fri, May 19, 2023, 12:51 Borja Sanchez 
> wrote:
>
>> Dear Debian Project Team,
>>
>> My name is Borja Sanchez, writting from Spain. I am currently planning to
>> run a paid course where I will distribute a modified version of Debian,
>> rebranded and renamed. This software will be offered at no extra cost as
>> part of the course materials.
>>
>> In addition to this, I wish to inform you that I am also considering
>> charging a fee for this customized software in the future, separate from
>> the course fees.
>>
>> The custom OS version will be built from the latest Debian stable
>> version, by running a live-build process to build a ISO image with custom
>> packages, scripts, assests pre-installed.
>>
>> With these points in mind, I have two key questions:
>>
>> 1. I would like to confirm that these proposed actions comply with the
>> GPL's guidelines and Debian's policies.
>>
>>
>> 2. I am interested to know if there are any other considerations,
>> requirements, or permissions I should be aware of before proceeding with
>> this plan.
>>
>>
>> Your expert advice and guidance on this matter would be greatly
>> appreciated. I value your work and aim to respect the open-source
>> principles that Debian upholds.
>>
>> Thank you for your time. I look forward to your response.
>>
>> Best regards,
>> Borja Sanchez
>>
>>

Re: About distribution of modified copy of Debian OS

[Andrew M.A. Cater]

On Fri, May 19, 2023 at 06:33:35PM +0200, Borja Sanchez wrote:
> Dear Debian Project Team,
> 
> My name is Borja Sanchez, writting from Spain. I am currently planning to
> run a paid course where I will distribute a modified version of Debian,
> rebranded and renamed. This software will be offered at no extra cost as
> part of the course materials.
> 
> In addition to this, I wish to inform you that I am also considering
> charging a fee for this customized software in the future, separate from
> the course fees.
> 
> The custom OS version will be built from the latest Debian stable version,
> by running a live-build process to build a ISO image with custom packages,
> scripts, assests pre-installed.
> 
> With these points in mind, I have two key questions:
> 
> 1. I would like to confirm that these proposed actions comply with the
> GPL's guidelines and Debian's policies.
> 
> 
> 2. I am interested to know if there are any other considerations,
> requirements, or permissions I should be aware of before proceeding with
> this plan.
> 

As someone else has suggested, this is not going to make large amounts 
of money for the software. You will be responsible for all branding 
checking, security support and so on.

If you do this, *please* change the reportbug scripts, the popularity
contest script, set up your own bug tracking instance and generally
be prepared to handle all queries from your users because Debian will
not be able to help them since we won't know how your distribution differs.
You may find it easier to use unmodified Debian and just supply
a small amount of software hosted and supported by you in addition.
Depending on the nature of the course, this might even be simplest by
hosting your own website.

Also please check the Debian wiki for details of how to set up
derivatives.

With every good wish, as ever,

Andy Cater

> 
> Your expert advice and guidance on this matter would be greatly
> appreciated. I value your work and aim to respect the open-source
> principles that Debian upholds.
> 
> Thank you for your time. I look forward to your response.
> 
> Best regards,
> Borja Sanchez