Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] License years 

The recommendation from Eclipse handbook [1] is
“ The {date} is either a year or a range of years with the first and last years of the range separated by a comma (e.g. “2004” or “2004, 2017”). The first year is when the contents of the file were first created and the last year is when the contents were last modified.”
So if you modify an existing file change the last year to 2019, If it is a new file just have 2019 on the file. Provided that you are not slow with your inbox and have not discovered time travel, in that case use the year that you are currently in :) 

[1] https://www.eclipse.org/projects/handbook/#ip-copyright-headers

—
Gorkem

On 11 Jan 2019, at 12:39, Nick Boldt wrote:
My rule of thumb is that generally you're supposed to update copyrights to 
the current year when you:

a) change a file (eg., .java)
b) change the version of the plugin / feature

So if one files moves up to 2019, its plugin should also have a newer
copyright date, as should its containing feature(s).
This applies to Eclipse IDE plugins probably, I do not think we have plugin.xmls on Che.
But if you have plugin or feature metadata that show copyright = 2018 while 
individual files in the plugin have been updated to 2019, that's fine.
On a related note, IANAL, TINLA. If you want to talk to an actual lawyer, 
hit up Jeff Kaufman or Richard Fontana.



@Nick I presume this is advice for Red Hatters only :)



Nick
On Fri, Jan 11, 2019 at 3:54 AM Sergii Kabashniuk <skabashn@xxxxxxxxxx> 
wrote:


I don't have such information.
On Fri, Jan 11, 2019 at 10:51 AM Oleksandr Garagatyi <ogaragat@xxxxxxxxxx> 
wrote:
Do you happen to know whether we are obliged by the Eclipse Foundation to 
use 2019 in new files/changes or old ones?
On Fri, Jan 11, 2019 at 10:32 AM Sergii Kabashniuk <skabashn@xxxxxxxxxx> 
wrote:


Hi
Small update on this topic.
We faced some untrivial behavior of our CI when it checks PRs.
The use-case becomes more complex as we expect and it's no longer looks 
like a quick fix with an easy win. That's is why we stopped any
investigation in this area. In case if someone wants to lead this
task let me or Mykhailo Kuznietsov know. Mykhailo will share all the 
information we have at this moment.

On Thu, Dec 27, 2018 at 10:51 PM Lukas Krejci <lkrejci@xxxxxxxxxx>
wrote:


I have used this in other projects and can recommend it.
It is on the same level of "PITA" as checkstyle or sortpom (meaning you 
have to remember to comply to them or remember to run their
"formatters"
for the sources to remain compliant).
We already apply sortpom, checkstyle et al., so +1 for another tool 
that
would keep the sources up-to-date.

Lukas

On 26. 12. 18 16:31, Sergii Kabashniuk wrote:

Hello

The issue:
It is quite common that legal departments require updating of

copyright

years in header sections whenever the given source file changes.
Initially, when we introduced license plugin functionality in Che, 
there
was no automation to detect years when source files were changed. But 
now

there is a
license-maven-plugin-git aims at making it easier not only to enforce 
this

requirement but also to fix found inconsistencies.

My question: what do you think should we introduce this plugin or

should we

manually
update years each year?

Links


https://github.com/mycila/license-maven-plugin/tree/master/license-maven-plugin-git

https://github.com/eclipse/che-dev/pull/16
https://github.com/eclipse/che-parent/pull/97/files
https://github.com/eclipse/che-dev/pull/16



_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or

unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/che-dev


_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev




--

Sergii Kabashniuk

Principal Software Engineer, DevTools

Red Hat Ukraine

skabashniuk@xxxxxxxxxx
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev




--

OLEKSANDR GARAGATYI

SENIOR SOFTWARE ENGINEER

Red Hat

<https://www.redhat.com/>
<https://red.ht/sig>
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev




--

Sergii Kabashniuk

Principal Software Engineer, DevTools

Red Hat Ukraine

skabashniuk@xxxxxxxxxx
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev




--

Nick Boldt

Principal Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt / http://nick.divbyzero.com
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews>      Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.facebook.com/RedHatInc>


“The Only Thing That Is Constant Is Change” - Heraclitus




_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/che-dev

Back to the top