Hi Willem, Thanks for your valuable feedback!
Best, Dianjin Wang On Thu, Dec 26, 2024 at 3:42 PM Willem Jiang <willem.ji...@gmail.com> wrote: > Please check out my comments in the below email. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Dec 25, 2024 at 5:07 PM Dianjin Wang <wangdian...@gmail.com> > wrote: > > > > Hi all, > > > > As source code cleanup work is in progress, I would like to start a > discussion thread on the License headers strategy. > > > > Our project includes codes from Greenplum and PostgreSQL, so we need to > handle the license headers carefully. I believe we all hope to align with > the ASF policies while maintaining traditional code conventions for better > engineering practices. > > > > /* > > Here are some related tasks for reference. Feedback is welcome via > GitHub: > > * For NOTICE and LICENSE files, see PR #812[1] (not ready for review). > > * For renaming the old brand in files to align the Apache brand, see PR > #731[2] (ready for review). > > * For GitHub workflows regarding brand name checks, see PR #787[3] > (ready for review). > > > > We must complete the cleanup work before creating any releases as > requested by ASF( > https://incubator.apache.org/guides/transitioning_asf.html). > > */ > > > > For this discussion, I referred to the `ASF Source header policy`[4] > page and practices from other ASF projects like HAWQ[5] & Pekko[6]. Hope we > can work together to achieve consensus on the following proposal points > before taking action. Welcome to have your suggestions and feedback, > especially from our mentors and members familiar with ASF rules. > > > > ## Proposed Cases > > > > I divided the scenarios into four cases: > > > > - Case 1: Completely original, new files created by the Cloudberry > community. > > - Case 2: Modifications/additions to the 3rd-party source files with > existing copyright headers. > > - Case 3: Modifications/additions to the 3rd-party source files without > copyright headers. > > - Case 4: No modifications/additions to the 3rd-party (PG/GP) source > files. > > > > I will share my thoughts on each case below. > > > > ## Case 1: New, Original Files > > > > For completely original, new files (created either before or after the > donation to ASF), we can use the standard Apache License header. > > > > Standard version (use Clang as an example): > > ``` > > > /*------------------------------------------------------------------------- > > * > > * example.c (option) > > * use for one example of how to add a licenser header (option) > > * > > * Licensed to the Apache Software Foundation (ASF) under one > > * or more contributor license agreements. See the NOTICE file > > * distributed with this work for additional information > > * regarding copyright ownership. The ASF licenses this file > > * to you under the Apache License, Version 2.0 (the > > * "License"); you may not use this file except in compliance > > * with the License. You may obtain a copy of the License at > > * > > * http://www.apache.org/licenses/LICENSE-2.0 > > * > > * Unless required by applicable law or agreed to in writing, > > * software distributed under the License is distributed on an > > * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY > > * KIND, either express or implied. See the License for the > > * specific language governing permissions and limitations > > * under the License. > > * > > * IDENTIFICATION (option) > > * src/timezone/zic.c (option) > > * > > > *------------------------------------------------------------------------- > > */ > > ``` > > > > As we adopt the PostgreSQL coding conventions and align the style, add > the `file name`, `description`, `IDENTIFICATION` and `file path` fields as > the options. They're not required, but should be encouraged. > > The new fileds may affect the auto License identification process. > You may think about put these options fields below the License header. > Ok, will provide another new standard version for this later. > > > > > ## Case 2 Modifications/Additions to Files with Existing Copyright > Headers > > > > When we have modifications/additions to the existing 3rd-party (PG/GP) > source files with copyright headers, we're asked to `Do Not` listed in the > following. Instead, we can use a short Apache License version. > > > > /* Reference: ASF Rules [7] > > 1. Do not modify or remove any copyright notices or licenses within > third-party works. > > 2. Do not add the standard Apache License header to the top of > third-party source files. > > 3. Minor modifications/additions to third-party source files should > typically be licensed under the same terms as the rest of the third-party > source for convenience. > > 4. The project's PMC should deal with major modifications/additions to > third-party source files on a case-by-case basis. > > */ > > > > Short version 1 (use Clang as an example): > > ``` > > > /*------------------------------------------------------------------------- > > * Licensed to the Apache Software Foundation (ASF) under one or more > > * license agreements; and to You under the Apache License, version 2.0: > > * > > * https://www.apache.org/licenses/LICENSE-2.0 > > * > > * This file is part of the Apache Cloudberry project. > > * > ------------------------------------------------------------------------- > > */ > > ``` > > > > When we want to add the license header in bulk to mounts of 3rd-party > files, we can directly insert the short version to the file header, this > way is accepted but not gorgeous. Here is one example of how to insert the > short header version into the existing files with the legacy copyright info: > > > > ``` > > I don't think we have the right change the License of the original > source code and relicense the source code in Apache License. > We just need to keep the original License header and make sure these > licenses are compatiable with Apache License. > You may find more information here > > https://www.apache.org/legal/resolved.html#handling-public-domain-licensed-works So we can remove Case #2. For Case #3, I believe all the files without copyright license headers are under the PostgreSQL license or the AL 2; from my understanding, there is also no need to take care of them anymore. Per this suggestion, we need only one case to handle: that's Case #1, which will be much simpler for the team.
