Re: Licenses: being finicky

[Peter Hutterer]

On Fri, Feb 16, 2024 at 12:42:29PM +0100, tlaro...@kergis.com wrote:
> On Fri, Feb 16, 2024 at 08:22:59PM +1000, Peter Hutterer wrote:
> > On Wed, Feb 14, 2024 at 09:37:43PM +0100, tlaro...@kergis.com wrote:
> > > Some meson.build, for example, have a SPDX-License-Identifier: tag,
> > > where "MIT" is mentionned, applying (I think) to the file itself, and
> > > the project has an entry with a pair (license: 'MIT') applying to the
> > > data by itself.
> > > 
> > > But, for example, xcbproto has a license with a (classical, for me)
> > > fourth clause forbiding use of the names of the authors without
> > > permission to advertise etc.
> > > 
> > > Acoording to:
> > > 
> > > https://spdx.org/licenses/
> > > 
> > > this is identified as "X11", the "MIT" being the same without this
> > > fourth paragraph. (I suspect this distinction is rather new.)
> > > 
> > > When creating meson files for building, is there some rule regarding
> > > this? 
> > > 
> > > I think that the correct way is to state 'X11' or 'MIT' or
> > > whatever matches COPYING or COPYRIGHTS or whatever file explains the
> > > license status and to conform, simply because this exists and is
> > > standardized, to the SPDX list of identifiers.
> > > 
> > > What do other think about this?
> > 
> > we've recently done this work for Fedora so you can probably get the
> > various licenses from there. Fun fact, some projects have *a lot* of
> > SPDX identifers (i think the record is 15).
> > 
> > In the end whether the license entry in meson.build matters is very
> > questionable and only the actual code files and maybe COPYING matters
> > (but do ask your preferred lawyer for confirmation).
> 
> Since a packaging system using meson could advertise the license
> from what is set in the project in meson.build, 

Maybe in a perfect world but this is not a reliable indicator so I doubt
any packaging system that cares about licenses uses that, or can use it
for the forseeable future.  Meson doesn't do any verification of those
tags so aside from being easier to extract it's really no different to
relying on COPYING or LICENSE (the latter of which at least github
encourages you to add).

> I think that it should be set
> right there and perhaps conforming to the SPDX identifiers (the SPDX
> identifiers in the meson.build meson_options.txt are less crucial, one
> could infer that if someone---me for example---is contributing, he's
> willing to contribute under X11 license and that this is what applies
> if lacking a more defined license identifier).

ftr, I don't disagree, we should advertise the right license whereever
possible but, example of the xserver: 
  Adobe-Display-PostScript AND BSD-3-Clause AND DEC-3-Clause AND
  HPND AND HPND-sell-MIT-disclaimer-xserver AND HPND-sell-variant AND
  ICU AND ISC AND MIT AND MIT-open-group AND NTP AND SGI-B-2.0 AND
  SMLNJ AND X11 AND X11-distribute-modifications-variant

I'm sure that would scare a few people away ;)

Sure, you could reduce it to just whatever the top-level spdx license is
(MIT) but then you're just back at where you started.

A better option for this would be the relatively new `license_files`
kwarg in meson's project() which we can just point at COPYING. But
having to version-check meson just to add this seem a bit over the top.

TLDR: our COPYING files are (thanks to Alan) quite good so relying on
those is probably the least friction approach.

Changing 'mit' to 'x11' in projects where it's really just the once
license would be quite uncontroversial though.
 
Cheers,
  Peter

> > 
> > Licenses are also compatible or direct derivatives of each other so X11
> > and MIT are compatible and unless you're into lawyerese it doesn't
> > matter which one is listed in meson.build.
> > 
> > > Note: I'm not planing to review "correct" attribution between X11 and
> > > MIT in all the Xorg projects---I'm sufficiently late on my schedule
> > > with what I have to do without starting to rover around. Furthermore,
> > > X11 has been historically identified as 'MIT'...
> > 
> > The main question: what are you're trying to achieve here? The
> > vast majority of our projects are old and new projects tend to
> > (or should) copy/paste from SDPX anyway.
> 
> I'm just _adding_ (not removing autoconf/automake stuff) meson build
> files to Xorg projects I'm reviewing (because I need to track bugs with
> X11/Mesa and kernel DRMKMS on NetBSD), so I want to have everything as
> correct as possible.
> 
> > 
> > PS: If I were you I'd be *really* careful trying to update old
> > repositories. We've made people maintainers for less! ;)
> 
> I will be careful ;)
> -- 
> Thierry Laronde 
>  http://www.kergis.com/
> http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

xserver: Tidy up MAINTAINERS file

[Enrico Weigelt, metux IT consult]

Hello folks,

I've just submitted a MR for tidying up the MAINTAINERS file and bring
the xserver related part into the Xserver tree.

Background:

The Xserver tree has several different maintainers for various pieces of
the tree.

Historically these have been recorded in an entirely different tree
(xorg-docs repo), which rips apart the information base and makes it
pretty uncomfortable to find the maintainers (or other contacts) for
some particular area of the Xserver. And it gets even more complex when
the roles differing between branches (eg. stable 21.* line vs mainline
vs. 3rdparty branches)

Optimally this should be possible to do automatically by something like
the Linux kernel's get_maintainer.pl script, which also can be called by
other tooling. (since the existing MAINTAINERS file in xorg-docs already
has the Linux kernel's format, it's get_maintainer.pl script can be used
here).

In general it's good if code bases are self-documenting, w/o having to
consult additional sources.

This queue introduces MAINTAINERS file for the Xserver itself (once it's
landed, the one in xorg-docs should be changed to just pointing here) as
well as the Linux kernel's get_maintainer.pl script.

It's done in several stages:

copy over MAINTAINERS from xorg-docs (original commit ID recorded in
commit message)
drop all entries for things outside the Xserver tree
add some yet missing entries (Jeremy and myself) as well as some missing
lines
copy over get_maintainer.pl from Linux tree (also recording original
commit ID)
tweak it to work with the Xserver tree (source tree detection)
Once this this has landed mainline, I'll post a MR on xorg-devel for
replacing the Xserver entries there by a link to this new MAINTAINERS file.

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1301


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: Stepping in as Xnest maintainer

[Enrico Weigelt, metux IT consult]

On 15.02.24 20:42, Thomas Adam wrote:

Hi,

Whilst I'm sure this is a nice thing to do -- is there any reason why
you're wanting to invest your time in maintaining Xnest, when Xephyr
seems to have a lot of additional features already?


Believe it or not, I've lots of funny setups running with it (and needs
it's multi-screen ability).

And I'm planning to add some new features, e.g. multiple upstream
displays (similar to dmx) ... and I don't feel that kdrive is the right
place to do it (probably could make it much more complex again).


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: Licenses: being finicky

[tlaronde]

On Fri, Feb 16, 2024 at 08:22:59PM +1000, Peter Hutterer wrote:
> On Wed, Feb 14, 2024 at 09:37:43PM +0100, tlaro...@kergis.com wrote:
> > Some meson.build, for example, have a SPDX-License-Identifier: tag,
> > where "MIT" is mentionned, applying (I think) to the file itself, and
> > the project has an entry with a pair (license: 'MIT') applying to the
> > data by itself.
> > 
> > But, for example, xcbproto has a license with a (classical, for me)
> > fourth clause forbiding use of the names of the authors without
> > permission to advertise etc.
> > 
> > Acoording to:
> > 
> > https://spdx.org/licenses/
> > 
> > this is identified as "X11", the "MIT" being the same without this
> > fourth paragraph. (I suspect this distinction is rather new.)
> > 
> > When creating meson files for building, is there some rule regarding
> > this? 
> > 
> > I think that the correct way is to state 'X11' or 'MIT' or
> > whatever matches COPYING or COPYRIGHTS or whatever file explains the
> > license status and to conform, simply because this exists and is
> > standardized, to the SPDX list of identifiers.
> > 
> > What do other think about this?
> 
> we've recently done this work for Fedora so you can probably get the
> various licenses from there. Fun fact, some projects have *a lot* of
> SPDX identifers (i think the record is 15).
> 
> In the end whether the license entry in meson.build matters is very
> questionable and only the actual code files and maybe COPYING matters
> (but do ask your preferred lawyer for confirmation).

Since a packaging system using meson could advertise the license
from what is set in the project in meson.build, I think that it should be set
right there and perhaps conforming to the SPDX identifiers (the SPDX
identifiers in the meson.build meson_options.txt are less crucial, one
could infer that if someone---me for example---is contributing, he's
willing to contribute under X11 license and that this is what applies
if lacking a more defined license identifier).

> 
> Licenses are also compatible or direct derivatives of each other so X11
> and MIT are compatible and unless you're into lawyerese it doesn't
> matter which one is listed in meson.build.
> 
> > Note: I'm not planing to review "correct" attribution between X11 and
> > MIT in all the Xorg projects---I'm sufficiently late on my schedule
> > with what I have to do without starting to rover around. Furthermore,
> > X11 has been historically identified as 'MIT'...
> 
> The main question: what are you're trying to achieve here? The
> vast majority of our projects are old and new projects tend to
> (or should) copy/paste from SDPX anyway.

I'm just _adding_ (not removing autoconf/automake stuff) meson build
files to Xorg projects I'm reviewing (because I need to track bugs with
X11/Mesa and kernel DRMKMS on NetBSD), so I want to have everything as
correct as possible.

> 
> PS: If I were you I'd be *really* careful trying to update old
> repositories. We've made people maintainers for less! ;)

I will be careful ;)
-- 
Thierry Laronde 
 http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

2024 X.Org Board of Directors Elections Nomination period is NOW

[Christopher Michael]

We are seeking nominations for candidates for election to the X.Org 
Foundation Board of Directors. All X.Org Foundation members are eligible 
for election to the board.


Nominations for the 2024 election are now open and will remain open 
until 23:59 UTC on 26 February 2024.


The Board consists of directors elected from the membership. Each year, 
an election is held to bring the total number of directors to eight. The 
four members receiving the highest vote totals will serve as directors 
for two year terms.


The directors who received two year terms starting in 2023 were 
Arkadiusz Hiler, Christopher Michael, Lyude Paul, and Daniel Vetter. 
They will continue to serve until their term ends in 2024. Current 
directors whose term expires in 2024 are Emma Anholt, Mark Filion, 
Ricardo Garcia, and Alyssa Rosenzweig.



A director is expected to participate in the fortnightly IRC meeting to 
discuss current business and to attend the annual meeting of the X.Org 
Foundation, which will be held at a location determined in advance by 
the Board of Directors.


A member may nominate themselves or any other member they feel is 
qualified. Nominations should be sent to the Election Committee at 
electi...@x.org.


Nominees shall be required to be current members of the X.Org 
Foundation, and submit a personal statement of up to 200 words that will 
be provided to prospective voters. The collected statements, along with 
the statement of contribution to the X.Org Foundation in the member's 
account page on http://members.x.org, will be made available to all 
voters to help them make their voting decisions.


Nominations, membership applications or renewals and completed personal 
statements must be received no later than 23:59 UTC on 26 February 2024.


The slate of candidates will be published 04 March 2024 and candidate 
Q&A will begin then. The deadline for Xorg membership applications and 
renewals is 07 March 2024.



Cheers,

Christopher Michael, on behalf of the X.Org BoD

Re: Licenses: being finicky

[Peter Hutterer]

On Wed, Feb 14, 2024 at 09:37:43PM +0100, tlaro...@kergis.com wrote:
> Some meson.build, for example, have a SPDX-License-Identifier: tag,
> where "MIT" is mentionned, applying (I think) to the file itself, and
> the project has an entry with a pair (license: 'MIT') applying to the
> data by itself.
> 
> But, for example, xcbproto has a license with a (classical, for me)
> fourth clause forbiding use of the names of the authors without
> permission to advertise etc.
> 
> Acoording to:
> 
> https://spdx.org/licenses/
> 
> this is identified as "X11", the "MIT" being the same without this
> fourth paragraph. (I suspect this distinction is rather new.)
> 
> When creating meson files for building, is there some rule regarding
> this? 
> 
> I think that the correct way is to state 'X11' or 'MIT' or
> whatever matches COPYING or COPYRIGHTS or whatever file explains the
> license status and to conform, simply because this exists and is
> standardized, to the SPDX list of identifiers.
> 
> What do other think about this?

we've recently done this work for Fedora so you can probably get the
various licenses from there. Fun fact, some projects have *a lot* of
SPDX identifers (i think the record is 15).

In the end whether the license entry in meson.build matters is very
questionable and only the actual code files and maybe COPYING matters
(but do ask your preferred lawyer for confirmation).

Licenses are also compatible or direct derivatives of each other so X11
and MIT are compatible and unless you're into lawyerese it doesn't
matter which one is listed in meson.build.

> Note: I'm not planing to review "correct" attribution between X11 and
> MIT in all the Xorg projects---I'm sufficiently late on my schedule
> with what I have to do without starting to rover around. Furthermore,
> X11 has been historically identified as 'MIT'...

The main question: what are you're trying to achieve here? The
vast majority of our projects are old and new projects tend to
(or should) copy/paste from SDPX anyway.

Cheers,
  Peter

PS: If I were you I'd be *really* careful trying to update old
repositories. We've made people maintainers for less! ;)