Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merging Lightbend copyright and ASF headers for existing source files #38

Closed
spangaer opened this issue Nov 9, 2022 · 31 comments
Closed
Labels
licensing licensing issue
Milestone

Comments

@spangaer
Copy link

spangaer commented Nov 9, 2022

Using this issue to gather some feedback before posting the proposal to the Apache legal JIRA

Current proposal (will be updated, based on feedback)

/*
 * Copyright (C) 2009-2022 Lightbend Inc. <https://www.lightbend.com>
 *
 * Updates since 2022-10-24 are 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.
 *
 * Lightbend and ASF license 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.
 */

Next to including the Lightbend notice, changes form the default header text are

Updates since 2022-10-24 are 

Lightbend and ASF license
@spangaer
Copy link
Author

spangaer commented Nov 9, 2022

In case anybody wonders, the date is the date that the incubation vote result was published.

@He-Pin
Copy link
Member

He-Pin commented Nov 9, 2022

/*
 * Copyright (C) 2014-2022 Lightbend Inc. <https://www.lightbend.com>
 * Copyright (C) 2022 The Apache Software Foundation. <https://www.apache.org/>
 * 
 * Licensed 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.
 */

@alexandru suggested this once.

@spangaer
Copy link
Author

spangaer commented Nov 9, 2022

Right, I recall that passing by at some point.
But here
https://www.apache.org/legal/src-headers.html#headers
it says, we should not include an Apache copyright notice.

Both that paragraph and the next one indicate that we can't remove the copyright notice without written permission.

I've added what changed specifically for clarity btw.

@pjfanning
Copy link
Contributor

this needs to go to legal team

I don't know why new threads keep being formed without any attempt to link the threads.

This is the existing discussion: https://lists.apache.org/thread/z0r4sr4kdvmh52mlhc5porot2sh1wtok

To summarise that thread:

  • we should aim not to remove the existing Lightbend copyrights
  • new files should have the standard Apache license header unmodified - example: https://github.com/apache/poi/blob/trunk/poi/src/main/java/org/apache/poi/POIDocument.java
  • if we modify an existing file with major changes then we need to have some new header setup that acknowledges the Lightbend and ASF contributions - the format should be discussed with legal
    • there is no plan to have any major changes to existing files - it will be months before we need to do this

@spangaer
Copy link
Author

spangaer commented Nov 9, 2022

@pjfanning
This issue takes all of that in to account. It just that the mailing list, with it automatic line breaking will make the above look like dung.

I'm trying to come up with what "bullit 3" should look like, but gathering some feedback within the project team before sending it to the legal JIRA. Seems like better to come with a proposal, then empty handed.

@pjfanning
Copy link
Contributor

pjfanning commented Nov 9, 2022

@pjfanning
Copy link
Contributor

pjfanning commented Nov 9, 2022

Proposal for the NOTICE file.

Apache Pekko
Copyright 2022 The Apache Software Foundation

This product includes software developed at
The Apache Software Foundation (https://www.apache.org/).

This product contains significant parts that were originally based on software from Lightbend (Akka <https://akka.io/>).
Copyright (C) 2009-2022 Lightbend Inc. <https://www.lightbend.com>

Apache Pekko is a descendant of Akka 2.6.x, the last version that was distributed under the
Apache License, Version 2.0 License.

`pekko-protobuf` includes protobuf v2.5.0 code developed by Google Inc.

We may need to further extend this NOTICE with details of other non-Lightbend software that is used by Akka/Pekko .

This NOTICE is based on some existing files in other ASF projects - specifically, https://github.com/apache/poi/blob/trunk/legal/NOTICE

@spangaer
Copy link
Author

spangaer commented Nov 9, 2022

All legal will need are these 2 links.

[1] https://github.com/mdedetrich/akka-apache/blob/6680c47dcc2305906a44d7794081682211d7ee0b/akka-actor/src/main/scala/akka/actor/AbstractActor.scala [2] https://github.com/apache/poi/blob/trunk/poi/src/main/java/org/apache/poi/POIDocument.java

I can raise the legal issue, if that's ok.

I was going to adapt the proposal to the /*==*/, notation, but I see it's not a universal thing
https://github.com/apache/kafka/blob/trunk/server-common/src/main/java/org/apache/kafka/server/util/ToolsUtils.java

Other than that, I I don't think they need any examples for point 2, given that there's just the official docs, which I was referring
https://www.apache.org/legal/src-headers.html#headers

Finally, just trying to help get some paperwork out of the way 🤷

@spangaer
Copy link
Author

spangaer commented Nov 9, 2022

I think this part should be shortened

Until 7 September 2022, the Akka code base was licensed using the Apache License, Version 2.0. Akka changed to
the Business Source License (BSL) v1.1 <https://www.lightbend.com/akka/license> from that date.

A number of Akka contributors have come together and forked the code base as Apache Pekko, using the
final Apache Licensed commit as their starting point.
Apache Pekko is a descendant of Akka 2.6.x, the last version that was distributed under the
Apache License, Version 2.0 License.

I'd avoid that 7 sept or BSL refs.
Clearly Akka 2.6.x is actually Akka <module> <module version>.

@spangaer
Copy link
Author

spangaer commented Nov 9, 2022

On the NOTICE
I would have expected the --------------- separator, but as it turns out I didn't see it appear elsewhere, so without seems to be common (just making note in case anybody else makes that consideration).

On the header
Reason to write up a proposal to post in the legal JIRA is following statements:

3. Do not add the standard Apache License header to the top of third-party source files.
5. The project's PMC should deal with major modifications/additions to third-party source files on a case-by-case basis.

https://www.apache.org/legal/src-headers.html#3party

If you fear that coming with a proposal in hand won't be appreciated it can go without.

@Claudenw
Copy link
Contributor

Claudenw commented Nov 9, 2022

IMHO

The entire code base is a 3rd party work as defined in https://www.apache.org/legal/src-headers.html#headers

  • As such we will make no changes to the copyright or licence notices in any source file until MUCH later
  • We will create a NOTICE file that will list both Lightbend and Apache as copyright holders.

We will only change this for source code that has significant changes from the original. We will cross that bridge when we come to it.

In addition we should take up Justin McLean's offer as he has in-depth experience in this area.

@spangaer
Copy link
Author

spangaer commented Nov 9, 2022

Well, I tend to disagree on that for 2 reasons:

  1. The format and rename, while not very original, are already significant changes.
  2. Postponing it until a file changes, is not a very Poka Yoke process. If you can just do a find and replace now for all existing notice headers. That means that you only have to document "leave what is in place if it exists" or "use the standard official" header for new files. (this discussion to be precise Updated references from akka to pekko #28 #36 (comment))

I sure had no intention to dismiss the offer of @justinmclean and sure hope he iterates through this. Yet, correct me if I'm wrong, but the new header better get a formal stamp from legal, right?

@Claudenw
Copy link
Contributor

Claudenw commented Nov 9, 2022

The format and rename does not change the operation of the code, and therefor is not a change in the intellectual property.

Unless you can argue that the code is not 3rd party then we are not allowed to change the copyright notice as per the link above.

@spangaer
Copy link
Author

spangaer commented Nov 9, 2022

Well, if you look carefully line 1 of the header statement is the original notice is unmodified, so the proposal does not conflict with your statements.

If anything, it adds a clarification of the current state and covers future work, but it does not modify the copyright as it existed up to the point of fork.

@alexandru
Copy link

alexandru commented Nov 9, 2022

Renaming the akka package to pekko will create a derived work that justifies adding the Apache copyright notice.

The question is, is such a header change legal? I think it is, as we won't be removing Lightbend's copyright notice, rather we are adding to it.

Surely this is legal:

/*
 * Copyright (C) 2014-2022 Lightbend Inc. <https://www.lightbend.com>
/*

/*
 * Copyright (C) 2022 The Apache Software Foundation. <https://www.apache.org/>
 */

package pekko

And, so is this:

/*
 * Copyright (C) 2014-2022 Lightbend Inc. <https://www.lightbend.com>
 * Copyright (C) 2022 The Apache Software Foundation. <https://www.apache.org/>
 */

package pekko

And so is this:

/*
 * Copyright (C) 2014-2022 Lightbend Inc. <https://www.lightbend.com>
 * Copyright (C) 2022 The Apache Software Foundation. <https://www.apache.org/>
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * ...
 */

package pekko

Lightbend's copyright stays in place, where it was, nobody's touching it. And the change is very helpful, as it informs of the project's history, and this project will indeed have multiple copyright owners.

Plus, at some point we will add new files. What will happen to those? Will they have a different header? I don't think they should have a different header, because even new files can be considered derived works of Lightbend's work. But then this header would be incorrect for new files, right?

/*
 * Copyright (C) 2014-2022 Lightbend Inc. <https://www.lightbend.com>
/*

And if we go with it for all files, what will we do when the year 2023 comes?

Sure, legal needs to weigh in, however managing headers becomes impractical if we don't have the same header everywhere, and it would be best to use sbt-header.

@alexandru
Copy link

@Claudenw

The format and rename does not change the operation of the code, and therefor is not a change in the intellectual property.

IANAL, but I disagree. Both formatting and naming things is creative work. Whether it's not significant enough to be meaningfully protected by copyright, that's another discussion.

IMO, it's not practical to micromanage headers, file by file, or to declare Copyright 2014-2022 Lightbend from now on, on everything. If we want to avoid some discussions, for sure we can delay it, but not because it's illegal.

Again, IANAL, and someone from legal should definitely weigh in on any header changes, to the dot.

@spangaer
Copy link
Author

spangaer commented Nov 9, 2022

I don't think they should have a different header, because even new files can be considered derived works of Lightbend's work.

It probably is a derivative work, but unless it's mostly copy-paste of existing files, the new work (thus file) has it's own copyright so certainly should not contain a notice attributing it to Lightbend, hence should hold the official Apache header. So sadly one header fits all won't fly I fear.

I don't think there's any dispute we can't remove the existing Lightbend notices (can be asked to legal).

Other than that. Whether the rename consist of novel work is a completely symbolic discussion. If we're serious about this fork we'll need it sooner or later.

As with the rename, let's agree on a header, get it reviewed and stamped. Then get it in.

Postponing it only makes it harder, not simpler.

So TBH I really have a hard time understanding the too soon side here.

Does anyone object getting the ball rolling on legal JIRA?

I have no problem with chasing this, though it could be Monday before it gets to JIRA.

@pjfanning
Copy link
Contributor

I've created https://issues.apache.org/jira/browse/LEGAL-626

@justinmclean
Copy link
Member

Sorry I missing this conversation as it was not happening on the dev list.

As I mentioned in the legal JIRA reformatting code would not can't as major changes and the 3rd party headers need to stay as they are unless you have permission from Akka to change them.

There is no need to mention protobuf v2.5.0 in you NOTICE file. License information should go in your LICENSE file.

Please do not use "Copyright 2022 and onwards", as copyright has an expiry date.

On the subject of ASF copyright notices in headers, please do not state "Copyright (C) XXXX The Apache Software Foundation.". The standard header states "Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements". Only 3rd party ASF headers include a copyright line with the year.

Also ask yourself, who actually owns the copyright of a contribution? And does the ASF ask for IP transfer?

@gmethvin
Copy link
Member

gmethvin commented Nov 9, 2022

Also ask yourself, who actually owns the copyright of a contribution? And does the ASF ask for IP transfer?

That's an interesting point, because Lightbend doesn't actually own all the copyrights of contributions, right? The Lightbend CLA doesn't transfer the IP, it just licenses your contributions to Lightbend. So is the existing Lightbend header incorrect?

@spangaer
Copy link
Author

spangaer commented Nov 9, 2022

Sorry I missing this conversation as it was not happening on the dev list.

That one's on me, but for the practical reasons mentioned above.

The Lightbend CLA doesn't transfer the IP, it just licenses your contributions to Lightbend. So is the existing Lightbend header incorrect?

Well, the sublicense encompasses a right to copy. So I'm quite sure they do no wrong to slab their copy'right' on there. Without that they wouldn't be able to go proprietary either.

@gmethvin
Copy link
Member

gmethvin commented Nov 9, 2022

My question was in the context of that the standard ASF header says Licensed to the Apache Software Foundation (ASF) versus Copyright ... The Apache Software Foundation. I was just curious if from a legal standpoint it is technically incorrect to include a regular copyright header when you only hold a license to use someone else's copyrighted work.

IANAL, but the right to copy is only one aspect of what copyright means. If you hold the copyright, you have the right to, for example, contribute that work to another OSS project. If Lightbend holds the copyright you can't do that. But I'm not exactly sure how that applies to copyright notices.

@Claudenw
Copy link
Contributor

Claudenw commented Nov 10, 2022

Copyright is an attribution of creation. When you create something the copyright comes into being. For example as of now I hold the copyright on this message. (This is why publishing letters written by someone else is legally tricky). I can assign the copyright to someone else if I wish.

License is what I say you can do with material I have the copyright on. And now we get into what others can do with my copyrighted material. Under the Apache v2 license grant a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. Thus once I put code I authored (copyright) out under the Apache v2 license others can do anything they like with it. Even though I have given anyone the right to do anything with it, it is still my code (copyright).

The Apache Foundation does not require the transfer of the copyright, it requires that you provide your code to Apache under the Apache v2 license so that Apache may do with it as it pleases.

@spangaer
Copy link
Author

Starting to feel like this issue is or has become one of those gorilla dances 🤷

I sure had hoped the outcome on the header subject would be more actionable.

@justinmclean
Copy link
Member

How is what I suggested above not actionable? i.e The 3rd party headers need to stay as they are unless you have permission from Akka to change them.

@spangaer
Copy link
Author

@Claudenw
Copy link
Contributor

I think we all agree this is 3rd-party code. As such the following rules are in play:

TREATMENT OF THIRD-PARTY WORKS

  • The term "third-party work" refers to a work not submitted directly to the ASF by the copyright owner or owner's agent. This includes parts of a work submitted directly to the ASF for which the submitter is not the copyright owner or owner's agent.
  • Do not modify or remove any copyright notices or licenses within third-party works.
  • Make sure that every third-party work includes its associated license, even if that requires adding a copy of the license from the third-party download site into the distribution.
  • Do not add the standard Apache License header to the top of third-party source files.
  • 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.
  • The project's PMC should deal with major modifications/additions to third-party source files on a case-by-case basis.

Is is official Apache policy and thus has been reviewed by legal.

So the upshot is:

DO NOT remove or modify any existing copyright notices.
DO NOT add Apache license information to the existing files.

Change of package name is a minor modification.
The PMC will determine when the modification has become "Major" and will act at that time.

Modifications contrary to these restrictions will lead to the PMC not approving the pull request or not approving the release.

@hen
Copy link
Member

hen commented Nov 18, 2022

@He-Pin
Copy link
Member

He-Pin commented Nov 18, 2022

So should I just added befer the current lightbend copyright?

/*
 * Pekko is a fork of Akka 2.6.20. Any modifications are:
 *
 * 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. 
 *
 * See source control history for modification details.
 */
/*
 * Akka 2.6.20 is provided under the Apache-2.0 license.
 */

as @hen pointed out, I think even it's combersom but very clear.

@hen
Copy link
Member

hen commented Nov 19, 2022

Let's get the JIRA legal issue resolved first. I want to see what other thoughts there are from the licensing committee folk.

@mdedetrich
Copy link
Contributor

Closing this as solved in #50

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
licensing licensing issue
Projects
None yet
Development

No branches or pull requests

9 participants