Comments (31)
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 🤷
from pekko.
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>
.
from pekko.
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.
from pekko.
I've created https://issues.apache.org/jira/browse/LEGAL-626
from pekko.
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.
from pekko.
In case anybody wonders, the date is the date that the incubation vote result was published.
from pekko.
/*
* 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.
from pekko.
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.
from pekko.
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
from pekko.
@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.
from pekko.
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.
from pekko.
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
from pekko.
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.
from pekko.
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.
from pekko.
Well, I tend to disagree on that for 2 reasons:
- The format and rename, while not very original, are already significant changes.
- 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 #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?
from pekko.
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.
from pekko.
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.
from pekko.
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.
from pekko.
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.
from pekko.
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?
from pekko.
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?
from pekko.
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.
from pekko.
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.
from pekko.
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.
from pekko.
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.
from pekko.
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.
from pekko.
from pekko.
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.
from pekko.
Noting that I've proposed a simpler approach here of a new forked-file source header: https://issues.apache.org/jira/browse/LEGAL-626?focusedCommentId=17635668&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17635668
from pekko.
Let's get the JIRA legal issue resolved first. I want to see what other thoughts there are from the licensing committee folk.
from pekko.
Closing this as solved in #50
from pekko.
Related Issues (20)
- Move link validator to nightly/weekly job
- handle the case where `DeviceTerminated.groupId` may not match the `DeviceGroup.groupId` HOT 2
- review test dependency overrides associated with docker-java
- java.lang.UnsupportedOperationException pekko migration HOT 5
- EventSourcedBehavior/Durable State exposed to stack overflow when lots of read-only commands are in the stash HOT 6
- Reproducible Scala 3 artifacts HOT 1
- With entity passivation enabled the shard region will cause a lot of unhandled ShardsUpdated during shutdown
- Feature request: Add BoundedSourceQueue#isComplete method
- double "a" appearing in tutorial HOT 2
- Add FutureTimeoutSupport#timeout support HOT 4
- Add UntypedAbstractActorWithTimers
- Add Flow#onBackpressureDrop() operator HOT 2
- Support just warning instead of error when `pekko.scheduler.tick-duration` < 10ms on Windows?
- Bug - Assertion failure caused by exception during pre-start HOT 3
- stream-testkit: issue with scala 2.12 usage of expectNextWithTimeoutPF HOT 9
- long running tests should be run in a nightly build HOT 2
- Deprecate `org.apache.pekko.dispatch.Futures` HOT 3
- Attribute overriding in `SourceQueueWithComplete`
- jdk9 tests do not run HOT 1
- Feature: backoff for Pattern#retry
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pekko.