| 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 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 Most Eclipse projects have a copyright header like " Copyright (c) 2009, 2018 Oracle and/or its affiliates. All rights reserved. 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. 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 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. 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
|
