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