Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vcKMF-004lrU-3B for pgsql-advocacy@arkaria.postgresql.org; Sun, 04 Jan 2026 09:25:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vcKME-00EyAB-2t for pgsql-advocacy@arkaria.postgresql.org; Sun, 04 Jan 2026 09:25:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vcKME-00Ey9k-1x for pgsql-advocacy@lists.postgresql.org; Sun, 04 Jan 2026 09:25:07 +0000 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vcKMD-004ORm-05 for pgsql-advocacy@lists.postgresql.org; Sun, 04 Jan 2026 09:25:07 +0000 Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-64d2c50f0d6so16703248a12.3 for ; Sun, 04 Jan 2026 01:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767518704; x=1768123504; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NpRVYwxlvlJG4gFJrYOchb+1SxZNhqcffoCTL7xEgFQ=; b=k3F74hLPuLg7ZfXjTf2FMOXJhGerw/7AuKEXNgnZ0MK6q5/NVN0g1HASlePbmvyynI N+WnwtBQUHQOQxKGVdGAIPYr9+OSQ4Bksi4B8EIIpxcTtQSe5TR6th8W+37/8G7VBovL HzVEy2vi5fsjkCE98JWlg6fDbK48qmET3T4SWKPdD2NDmrwRd1CgL8mNWVXvfLA9mQod dnNbjnpDw0fewPurQoTFgCS9fswW+kSGjn3E/xhwoTLD8WZR9Z8bzkqJTDXEjB/m2JMX CTWYgsRtfB38dLkZTALShUVxmG0xc0GgQPu9RgxpB/QUuHV15u1elVrz3M5U+2Qz9pOF TBpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767518704; x=1768123504; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NpRVYwxlvlJG4gFJrYOchb+1SxZNhqcffoCTL7xEgFQ=; b=njOX52j8yeFqkJBGnZdIvMGJVFb8f/AFFwTgiDRYm2KoBFmCj2wVueWfezn4nTEAPg 8Is2NZ6BrCMWOxGggr+T2ulIWXyX+GsynVTnLRKIUqXIsDgZDtamW2Oi70+jsp2pW9OL gSrGO12eJnah82zh+fuJqQ5QQrrtlwCxjz7omwGVQ991q0fPeiO1pNygZHne1Uk2607C 88KynouwtCCb4WWXciuEI8Yds74kgTRrzLHIgrgiiLMMc4EUHhz7kQEySXZMPrFgmI/Y 6g/DpLpgEmTh/08JWaIfJtX76ZjQzra4JAnB2dRE302Iy5wBx9QNtxVW6ta9NCFH4awD vT4Q== X-Forwarded-Encrypted: i=1; AJvYcCW+PvVebrk3Mk8JkTayDdkGUK6eI9bCvc1XfDeXKzRS8kNIRGPAyTluIbjvzM6fEnMiGS8ZQbSO8vSaUmIKlg==@lists.postgresql.org X-Gm-Message-State: AOJu0Yyz+SvLkILwAofjZ0veGn6Fgf9KesqxgKo9jcXbXMTCkW+zsYoC iKqH/E+nIeJa/U2agW7iocnAEQDHilmtrr8H+/K1+TnNqdyDfMcv8HWFgaDWVovxSvpicPSX34D 7TrQP2yTGlNA3nrMq6iX0cuqlmp3WabE= X-Gm-Gg: AY/fxX5pGKvWG6lrDgf9XxhHiJuFs0TxyaHCuQSD2jTMS6N0f+8tqlHw1N9SIa0HIHx Ypx3dCWBNwAU04f8/2G7AkWuJX7dREviYmv1KuJLRgl0MyWpyHnYdHSqrGG5KDvTWZVTSDOJVY+ ahOuYedkq+YvyGikwJzG1B3mZgrUiWuqoMo+WsM2OTSbwzbkxzOLJTR7Rk3bECaJul//9OUirOl EICeGj+8zSaOW2IjSfNSK8aWAygXwPOpYiYSvV1a4L2d34trJ77TUWiFE4IQSCiqXI5kcIW X-Google-Smtp-Source: AGHT+IG/jOAw3RSgo1PTLJWVfAraOe4x3GhOYpczEfjP8YIVmbggAm+7ugTjJqBQDcfVv3PKm0fsJSEFkhrqCD+bU3c= X-Received: by 2002:a17:906:9fc7:b0:b83:a4a7:725e with SMTP id a640c23a62f3a-b83a4a77500mr1379452266b.24.1767518704046; Sun, 04 Jan 2026 01:25:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Valeria Kaplan Date: Sun, 4 Jan 2026 09:24:52 +0000 X-Gm-Features: AQt7F2ogsgPWJK6FxAQ12l0o4JVBPiAGH6xiA_wTcFPjKMUsqSaG3wyw-bfEh_Y Message-ID: Subject: Re: Non-Compete Challenges for Community Work To: Bruce Momjian Cc: Dave Page , Robert Haas , Umair Shahid , Greg Sabino Mullane , Cornelia Biacsics , pgsql-advocacy@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000007d14b706478c842e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007d14b706478c842e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 2, 2026 at 6:47=E2=80=AFPM Bruce Momjian wro= te: > On Wed, Dec 31, 2025 at 02:17:10PM -0500, Bruce Momjian wrote: > > I don't know if things are improving and we can ignore the issue, or if > > there is some action that can be taken. Ideas are: > > > > * New employees should read employment contracts and ideally have them > > reviewed by an employment lawyer. It might be difficult, but not > > being able to find a suitable job for a year is clearly worse. > > > > * Somehow incentivize companies to limit their non-compete restriction= s > > to be more limited, and hopefully not block community involvement. > > I think a question is whether it is wise for the community to be > influencing how companies specify compete restrictions in their > employment contracts. Even if the community were successful in making > changes that are positive for employees, is this an overreach for the > community? > An idea would be to allow companies to voluntarily submit their > non-compete clauses to the community for approval to be listed on some > community fair-employment page. Would any company do that? > I have a feeling companies won't do that unless there is a clear benefit to them... > > A more fruitful and less heavy-handed option might be to encourage > employees to read and actively evaluate their compete restrictions. > However, many of our contributors become involved with our community > only _after_ being employed, meaning the employment contract has already > been accepted by the employee. > We could perhaps consider having some PostgreSQL community guides about non-competes. Along the lines of: 1. Employees are generally advised to review their contracts for non-compete clauses. 2. Broad or generic non-compete clauses are not advisable, as they may hinder future work in the PostgreSQL field. 3. It=E2=80=99s worth clearly defining community work in the contract to av= oid restrictions on contributing to the PostgreSQL community after leaving the company. (I am aware that this might be tricky) and so on... Some of these are fairly obvious but it will make people a bit more aware of this potential issue. Of course, having this thread in the archives is helpful already. I don=E2=80=99t believe that starting to contribute after an employment con= tract has already been signed is something we can realistically prevent. However, we could add a note to our guides that if someone has already signed a contract and is considering community contributions, the non-compete clause in their contract should be reviewed to ensure their ability to contribute to the PostgreSQL community in the future, irrespective of their employment status. It would likely be worth consulting with community lawyers if we decide to put together guidelines like this. Valeria > -- > Bruce Momjian https://momjian.us > EDB https://enterprisedb.com > > Do not let urgent matters crowd out time for investment in the future. > > > --0000000000007d14b706478c842e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jan 2, 2026= at 6:47=E2=80=AFPM Bruce Momjian <b= ruce@momjian.us> wrote:
On Wed, Dec 31, 2025 at 02:17:10PM -0500, Bruce Momjian wrot= e:
> I don't know if things are improving and we can ignore the issue, = or if
> there is some action that can be taken.=C2=A0 Ideas are:
>
> *=C2=A0 New employees should read employment contracts and ideally hav= e them
>=C2=A0 =C2=A0 reviewed by an employment lawyer.=C2=A0 It might be diffi= cult, but not
>=C2=A0 =C2=A0 being able to find a suitable job for a year is clearly w= orse.
>
> *=C2=A0 Somehow incentivize companies to limit their non-compete restr= ictions
>=C2=A0 =C2=A0 to be more limited, and hopefully not block community inv= olvement.

I think a question is whether it is wise for the community to be
influencing how companies specify compete restrictions in their
employment contracts.=C2=A0 Even if the community were successful in making=
changes that are positive for employees, is this an overreach for the
community?

An idea would be to allow companies to voluntarily submit their
non-compete clauses to the community for approval to be listed on some
community fair-employment page.=C2=A0 Would any company do that?
I have a feeling companies won't do that unless there is a c= lear benefit to them...

A more fruitful and less heavy-handed option might be to encourage
employees to read and actively evaluate their compete restrictions.
However, many of our contributors become involved with our community
only _after_ being employed, meaning the employment contract has already been accepted by the employee.
=C2=A0
We cou= ld perhaps consider having some PostgreSQL community guides about non-compe= tes. Along the lines of:
1. Employees are generally advised to re= view their contracts for non-compete clauses.
2. Broad or generic non-c= ompete clauses are not advisable, as they may hinder future work in the Pos= tgreSQL field.
3. It=E2=80=99s worth clearly defining community work in= the contract to avoid restrictions on contributing to the PostgreSQL commu= nity after leaving the company. (I am aware that this might be tricky) and = so on...=C2=A0

Some of these are fairly=C2=A0obvio= us but it will make people a bit more aware of this potential issue. Of cou= rse, having this thread in the archives is helpful already.=C2=A0

I don=E2=80=99t believe that starting to contribute after a= n employment contract has already been signed is something we can realistic= ally prevent.

However, we could add a note to our = guides that if someone has already signed a contract and is considering com= munity contributions, the non-compete clause in their contract should be re= viewed to ensure their ability to contribute to the PostgreSQL community in= the future, irrespective of their employment status.

<= div>It would likely be worth consulting with community lawyers if we decide= to put together guidelines like this.

Valeria


--
=C2=A0 Bruce Momjian=C2=A0 <bruce@momjian.us>=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://momjian.us=
=C2=A0 EDB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https:= //enterprisedb.com

=C2=A0 Do not let urgent matters crowd out time for investment in the futur= e.


--0000000000007d14b706478c842e--