Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] Happy New Copyright Year!

If the year says 2000 or 1999, then the project is either "very mature" or "dead", regardless if it is one or two numbers ;-)

As for what Alasdair pointed out, if everyone involved (and in most cases even their lawyers) agrees, it is best to change and adjust only the meta-information of e.g. the POM along the years and only files that really changed, then it sounds fine, too. 
Files that need to be created from scratch would not even end up in the "javax.*" namespace of existing specs like Servlet, JSP, JSF, etc. but a new one like "jakarta.*" For those, if nobody feels offended or has problems, maybe a neutral phrase could even be found. Again, it's up to all involved parties especially those who can and must afford legal advise to figure that out. 

For existing code their headers must not be touched in most cases. If a file like javax.servlet.Servlet ever really ended up in a new package like jakarta.servlet, then of course the year needs updating, e.g. 2019, but everything else should remain like it was before that.

HTH,

Werner 




On Mon, Jan 14, 2019 at 5:08 PM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:

I completely do not understand what you like to tell me. A project is not dead just because it has only a single copyright year instad of the dual-year variant.

-Markus

 

From: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Werner Keil
Sent: Montag, 14. Januar 2019 13:43
To: Jakara EE community discussions
Subject: Re: [jakarta.ee-community] Happy New Copyright Year!

 

The only project that needs no years changes is a dead or archived one;-)

 

Especially those who also contribute to Apache projects are perfectly fine with Apache Foundation taking all copyright credits away from them in all individual file headers and elsewhere (except maybe the list of authors or a POM) so it seems like a waste of time and effort that is better spent differently to argue about a detail of phrasing in such headers.

 

All it can do is to further delay Jakarta EE than it already is. 

 

Werner 

 

Am Mo., 14. Jan. 2019, 12:11 hat Markus KARG <markus@xxxxxxxxxxxxxxx> geschrieben:

Because we don't want to update the year at all, and we want to find a solution which is fair to everybody, not just to the original author.

-Markus

 

From: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Werner Keil
Sent: Montag, 14. Januar 2019 10:31
To: Jakara EE community discussions
Subject: Re: [jakarta.ee-community] Happy New Copyright Year!

 

If this is mainly about updating the year, then why don't all projects use a proper Maven plugin that e.g. JSRs I help as Spec Lead or Maintenance Lead uses for quite a while? ;-)

 

AFAIR we also applied it in JSR375 where Oracle needed some help even before Java EE8, so it might act as an example in EE4J/Jakarta EE.

 

Each company has slightly different phrases. Oracle's headers always say "Oracle and / or its associates". Red hat has a "individuals by the @author tag" phrase.

 

A lot like Microprofile Spring adds many "external ingredients" by Netflix, Apache, Dropwizard und whatever else is "hip" or trendy right now. That not only technically makes it harder to keep track of what's included and who do contributed it when and under which circumstances. Mike mentioned (Not always in this list but others like Working Groups) this practice may put both Eclipse Foundation and its users in a bad situation, thus MicroProfile also should respect more formal practices and governance instead of Jakarta EE repeating those mishaps and practices.

 

Regards,

Werner

 

 

Am Mo., 14. Jan. 2019, 07:02 hat Greg Wilkins <gregw@xxxxxxxxxxx> geschrieben:

 

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. 

Mike Milinkovich

(m) +1.613.220.3223


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 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 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

Back to the top