| Re: [jakarta.ee-community] Happy New Copyright Year! |
_______________________________________________Wayne,
thank for this.
I would like to kindly ask you to either remove the speculations about IP ownership in the listed situations OR clearly mark them as examples based on US / canadian law. The reason is that in other countries these are in part of entirely wrong. For example in Germany, Eclipse Foundation projects defintively ARE legal entities (GbR, non-registered, non-commercial, possibly non-profit), and German law says that the IP always belongs to the AUTHR and is absolutely unsaleable, but the employment contract can grant an exclusive exploitation right to the employer (but just that); in particular the law guarantees that the AUTHOR'S name (not the employer's) MUST be told so even the "and others" form might not be sufficient. Hence, your assumptions are a violation of German law. So please mark them as "examples basing on US / canadian law" or remove them.
Thanks
-Markus
From: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: Dienstag, 15. Januar 2019 05:47
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] Happy New Copyright Year!
The Eclipse Project Handbook provides guidance regarding the format of copyright headers.
The short version is that we expect to see the year that the content was initially created. Project teams can optionally decide to include a "most recently changed" year as well. Further, if the copyright statement lists one or more company names, it is expected that "and others" will be added when other copyright holders make contributions to the content.
HTH,
Wayne
On Mon, Jan 14, 2019 at 8:35 PM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
If an API project was last release in 2017, then a new release is done in 2019 which modifies 15 of it's 40 source files, then is it really the case that copyright expires earlier for the 25 files? If so, why is the granularity of copyright scope set at file rather than line, class, method, directory, package etc? How much of a file needs to change to "refresh" it's copyright? Probably just changing the date in the header is not sufficient? Does Mickey Mouse's nose come out of copyright earlier than his ears because it changed less recently?
These are difficult legal questions which I doubt will be resolved by us, nor by a date in a file header!
But whatever the decision is, we need to decide a policy that is clearly stated so all projects can follow it. I'd prefer no dates in the header (just because it's simpler), but can live with any of the options so long as we all do the same thing.
cheers
On Tue, 15 Jan 2019 at 00:24, Alasdair Nottingham <alasdair.nottingham@xxxxxxxxx> wrote:
I always understood that updating a copyright year without a significant change to the file was a big no no since it could be interpreted as an attempt to extend copyright beyond the age allowed for by law. Whatever ends up being decided I don’t think that should be an option.
Alasdair Nottingham
On Jan 14, 2019, at 1:01 AM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
Isn't then main issue here the year in the copyright, with the question being should we: a) remove the years; b) update them on mass; c) update them on a file by file basis.
Whatever the answer is, it needs to be clearly stated as a policy, as currently I think it is very piecemeal. The jetty project is an eclipse project and we update on mass - which is a PITA for outstanding branches. It would be great to get rid of the need to update the header at all.
Can somebody ask the lawyers if having 2012-2019 in a header is meaningful at all when we have a configuration control system that can trace the history and date of every line of code?
regards
On Sun, 13 Jan 2019 at 23:35, Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote:
Werner,
yes, Thorntail lists the main contributing company, but it also mentions that there are other contributors (see here):
Copyright 2015-2017 Red Hat, Inc, and individual contributors.
Currently most EE4J copyright headers give the impression that the copyright belongs 100% to Oracle. That is currently correct (in most cases), but will change as soon as more people start contributing. Therefore, I think it is reasonable to discuss how a copyright header could look like in the future. Or we say that we don't care at all if the copyright headers are different between files within the same project. That would also be fine. In JAX-RS are already have different headers (see here and here).
By the way, Spring Boot for example doesn't list the main contributing company at all (see here):
Copyright 2012-2017 the original author or authors.
Best regards
Christian
Am So., 13. Jan. 2019 um 12:42 Uhr schrieb Werner Keil <werner.keil@xxxxxxxxx>:
Nobody does that, not even Red Hat
Thorntail is relatively new, but the original or main contributing company has just the same kind of header https://github.com/thorntail/thorntail/blob/master/core/container/src/main/java/org/wildfly/swarm/DebugUtils.java
you also find in almost every other project including CDI or Bean Validation.
Werner
Am So., 13. Jan. 2019, 10:23 hat Markus KARG <markus@xxxxxxxxxxxxxxx> geschrieben:
Nobody asked for giving up ownership. The proposal was just to change the single copyright line, as due to the various contributions the files become as shared good of all contributors. There also might be completely new files in the future in projects previously donated by Oracle. It would be rather confusing to have totally different copyright lines within one single project. For example, one file with Oracle's copyright, one with IBM's, one with "Eclipse Contributors" and one with a list of names. So my proposal would be to ask the Oracle lawyers what the price would be to replace the original copyright line by a generic "Eclipse Contributors" line. Given the fact that the EF strives for lots of more contributions from outside Oracle, and given the possibility that some day those might outweigh the contributions of Oracle, this would be just logical.
-Markus
From: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Bill Shannon
Sent: Samstag, 12. Januar 2019 22:33
To: Jakarta EE community discussions; Mike Milinkovich
Subject: Re: [jakarta.ee-community] Happy New Copyright Year!
Oracle is definitely not giving up ownership of the contributed code. Others may update the code and own their updates, but that doesn't remove Oracle's ownership of the code Oracle contributed, and thus we definitely don't want you to modify the copyright statement to remove Oracle.
It's best if these discussions of the law are done with lawyers. We're following the advice of Oracle's lawyers.Mike Milinkovich wrote on 1/12/19 9:13 AM:
Markus,
My understanding is that Oracle would prefer that their current copyright notices remain in their current form. I wouldn’t make any assumptions.
On Jan 12, 2019, at 11:50 AM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:Note that this is just a best practice, but not an enforced rule. The EF handbook explicitly allows that the committers agree upon modification of the owner line. And hence Oracle said, they would migrate their projects to the EF, I assume they are willing to accept a change like this one…
Copyright (c) {date} Contributors to the Eclipse Foundation
…without a main owner, and without a second date.
-Markus
From: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Werner Keil
Sent: Samstag, 12. Januar 2019 15:44
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] Happy New Copyright Year!
Most Eclipse projects have a copyright header like
" Copyright (c) 2009, 2018 Oracle and/or its affiliates. All rights reserved.
(from EclipseLink)
so with minor phrase changes all contributors do this for ages, it may say "IBM and others", "Red Hat and others", etc. but the main IP contributor is mentioned in the header, even if 100 people may have edited a particular file.
Werner
On Sat, Jan 12, 2019 at 3:32 PM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
Oracle owns the IP of their contributions, but not the files in their entirety. These are two different things. And I doubt that the pure copyright line itself can be counted as IP at all, as it is only an optional addition to the file, but not any kind of "proetected invention". So I wonder if Oracle really wants to forbid all other committers to modify the copyright line in the proposed way.
-Markus
From: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Werner Keil
Sent: Samstag, 12. Januar 2019 15:26
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] Happy New Copyright Year!
The code of course.
While Apache Foundation projects also generally own the copyright (at least according to file headers) the authors and contributors mentioned in the copyright and headers of all Jakarta EE projects own it, Eclipse Foundation does not own the IP, it only protects brand names like "Jakarta EE" or others.
On Sat, Jan 12, 2019 at 3:12 PM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
As Jakarta EE is an Eclipse Foundation project, what do you mean with "Oracle-owned"?
-Markus
-----Original Message-----
From: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Bill Shannon
Sent: Freitag, 11. Januar 2019 21:39
To: Jakarta EE community discussions; Matija Šuklje
Subject: Re: [jakarta.ee-community] Happy New Copyright Year!
Until you convince Oracle legal, the rules remain the same for Oracle-owned content.
Matija Šuklje wrote on 1/10/19 11:26 PM:
> On sreda, 02. januar 2019 23:38:58 CET Michael Müller wrote:
>> The European copyright gladly does not need to mention any year.
>> It's bound to the author, not to the time. So why do American's need
>> to mention the year?
>
> Since the Berne convention, copyright is indeed automatic and any work
> of authorship is automatically protected by it.
>
> The urge to absolutely have to write copyright statements stems from
> the inertia in the USA, as it only joined the Berne convention well
> after computer programs were a thing (i.e. in 1989), and so until then
> still required the copyright statement in order for a work to be
> protected; also some FOSS licenses require them to be kept in tact (if
> they existed, when you copied the code).
>
> Not every contribution is original or substantial enough to be
> copyrightable – even the popular 5 (or 10, or X) SLOC rule of thumb
> is, legally-speaking, very debatable.
>
> Especially in USA, copyright notices are formalised as – but even
> there the years of major changes are optional! – see:
>
> ```
> $copyright_sign_or_equivalent $year_of_creation
> [$year(s)_of_major_change] $copyright_holder ```
>
> That being said, I think the yearly bump of the year is a lot of work
> trying to tackle some very minuscule risk.
>
> Let us imagine the worst possible scenario: _1)_ Project never bumps
> the year in a copyright statement in a file and _2)_ 50+ years¹ after
> the initial release, someone would copy the code as if it were in
> public domain. Now, if we would have issue with that and go to court,
> and _3)_ the court would (very unlikely) only take the copyright
> headers of that file into account and therefore _4)_ rule that the
> code in that file has fallen under public domain and the FOSS license
> does not apply to it any more. The end result would simply be that (in
> one jurisdiction) that file would fall into public domain and be up
> for grabs by anyone for anything, no copyleft, 50+ years from the
> file’s creation (instead of e.g. 5, maybe 20 years later).
>
> Nothing prevents you from having a code base where all the old files
> carry the old year and the files that were created later carry a newer
> year.
>
> But, honestly, how likely is it that 50 years from now the same
> (unaltered) code would still be interesting to exploit?
>
> And even if you think FOSS code flowing into the public domain 50+
> years from its first publication is a risk you do not want to take,
> you still have 50 years to bump the year before it becomes an issue.
> For the super-risk-averse year-bumpers, scheduling a reminder every
> decade should be totally enough IMHO.
>
> Personally, I don’t think it’s worth the bother and should be
> abolished …
>
> cheers,
> Matija Šuklje
> —
> 1 “Life plus 50 years” is the minimum under the Berne convention
> (and TRIPS), but it still differs from jurisdiction to jurisdiction.
> For example in almost all of EU and in USA it is (life plus) 70 years,
> while in India it is (life plus) 60 years, and in China and Japan only
> (life plus) 50 years.
>
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________jakarta.ee-community mailing listjakarta.ee-community@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community