I'm guessing that the previous headers were generated using the license-maven-plugin
We should go with a very plain and simple header as described here: http://www.apache.org/legal/src-headers.html I answered your questions in-line: On Tue, Nov 17, 2015 at 5:49 PM Lotts, David <[email protected]> wrote: > About half of our source code has Apache license with a Copyright > statement, see below. > Questions about the license headers: > > 1. Should we preserve the existing line "* Copyright (C) 2014 - 2015 Rya " > ? It is one of the three options for the Apache Tools. > no. > 2. Should it have " Apache " as in "Copyright ... Apache Rya" or some > other organization? > no. > 3. Is the placement above/below the package statement, and file comments > significant? Or just anywhere near the top? > first lines in the file > 4. Does anyone recognize the tool that uses the #%L and the %% ? > probably the previous plug-in > 5. It seems to add the package name, which seems unnecessary. > yeah, the package name shouldn't be there. > 6. Apache Rat looks great, but the Maven plugin only reports on the whole > project, not new or edited files, and does not insert the license. Can > anyone confirm or deny? So it would just be a tool to run as part of the > release process. > maybe we could use both plug-ins... but ultimately I think everything needs to pass using apache-rat > ==== > In Rya, this occurs in most files after the package statement: > /* > * #%L > * mvm.rya.rya.prospector > * %% > * Copyright (C) 2014 - 2015 Rya > * %% > * Licensed under the Apache License, Version 2.0 (the "License"); > * you may not use this file except in compliance with the License. > * You may obtain a copy of the License at > * > * http://www.apache.org/licenses/LICENSE-2.0 > * > * Unless required by applicable law or agreed to in writing, software > * distributed under the License is distributed on an "AS IS" BASIS, > * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > * See the License for the specific language governing permissions and > * limitations under the License. > * #L% > */ > > In the Accumulo project java files, I see almost the same text in each > Accumulo .java file, ABOVE the package statement. It's the same except it > is missing these 5 lines. > * #%L > * mvm.rya.rya.prospector > * %% > * Copyright (C) 2014 - 2015 Rya > * %% > > david lotts. > > -----Original Message----- > From: Josh Elser [mailto:[email protected]] > Sent: Tuesday, November 17, 2015 1:30 AM > To: [email protected] > Subject: Re: incubator report for November - please comment > > Josh Elser wrote: > > Puja Valiyil wrote: > >> All, > >> We (David Lotts and I) were going to start working on updating the > >> license headers this week. Do we just run the perl scripts referenced > >> here: > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_le > >> gal_src-2Dheaders.html&d=BQICaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrY > >> IdfxIq10&r=ruy1rriFBFoeOJvvQWwN1h8AcdSNT3EVLrdVl7pr-iA&m=ursN85XZ2iI- > >> sVyWHNBLpaCvY6dqnDXp4jhYUMYWgv0&s=gF4jawXf3ru7dWGnut0HT0jzcjBkZcVy-I5 > >> FH2U0_eM&e= Is there anything else we should do? I think that Adina > >> already vetted the dependencies. I'd like to get us on the path to > >> cutting our first apache release -- we've been waiting to check some > >> things in until the apache repo is in a good place, and I'd like to > >> just put some of these things to bed. > > > > However you want to skin that cat. Any text manipulation tool (even > > IDEs) has the ability to add the proper header. Getting the LICENSE > > and NOTICE files correct will be more work. If you include any > > convenience artifacts (binary -- e.g. jars) in the release outside of > > the source-release, these are also subject to scrutiny. > > > > Vetting dependencies gets tricky -- this will take some time to get > > correct and will always requires the project's attention. The bar as > > an incubating project is lower than that of a top-level project (TLP) > > in that incubator releases typically need not be 100% correct, but the > > intent is that, as a project, you make forward progress here and > > understand how to apply the ASL and follow ASF policy by the time you > > graduation. > > > > I've tried to condense the information on what I know here[1], and I > > know NiFi also has a great resource [2]. Hopefully these are easier > > applied and concentrated than the foundation-level docs. > > > > > >> Also, is there documentation about what paperwork needs to be filled > >> out to commit changes to Rya? > > > > This is a very important thing to understand here (I apologize for the > > incoming strong wording). > > > > The Apache Software Foundation does _not_ deal in terms of companies. > > Individuals contribute to the ASF. The only reason that companies are > > at all in the picture is because, sometimes, individuals do not always > > own the code that they write. All committers must have a document > > filed that states they donate the copyright on the work they make to > > the ASF by way of the ICLA (as all the committers have already done -- > > hopefully those of you with agreements on copyright with your > > companies have filed the necessary CCLAs). Committers whose companies > > own the code they wish to add to Rya must also have their company file > > a CCLA. The ICLA and CCLA serve the same purpose (copyright assignment > > to the ASF); the only difference is that one is for individuals the > other for companies. > > > >> There are some other companies we work with that would like to start > >> committing their changes directly. > > > > This sounds like you're not familiar with the model of roles at the > > ASF [3]. Please start there. > > > > The initial set of committers (and mentors) are the only ones with > > write access to the codebase. Everyone else is a contributor who sends > > you patches/pull-requests which a committer must vet and commit on > > their behalf. At this stage in Rya's lifetime, you want to grow the > > project by attracting contributors, making sure they understand how > > Rya "does business", and then, after some time, adding them as > > committers to do the same (and repeat). The PMC role gets important > > later, but we can cross that bridge later, IMO. > > Forgot to add the actual foundation docs for CLAs > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_licenses_-23clas&d=BQICaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=ruy1rriFBFoeOJvvQWwN1h8AcdSNT3EVLrdVl7pr-iA&m=ursN85XZ2iI-sVyWHNBLpaCvY6dqnDXp4jhYUMYWgv0&s=N8cf0Hnp3Lywam3Js2obr1gYovXMxsPM4qjNu2fRLM4&e= > . It's rather straightforward. > > > > > [1] > > https://urldefense.proofpoint.com/v2/url?u=http-3A__accumulo.apache.or > > g_verifying-5Freleases.html-23apache-2Dsoftware-2Dlicense-2Dapplicatio > > n&d=BQICaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYIdfxIq10&r=ruy1rriFBFo > > eOJvvQWwN1h8AcdSNT3EVLrdVl7pr-iA&m=ursN85XZ2iI-sVyWHNBLpaCvY6dqnDXp4jh > > YUMYWgv0&s=bH9J_HImN-DJPVI5PEyzVNojHQPNcKrgLw_fBhaUc3c&e= > > > > [2] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__nifi.apache.org_l > > icensing-2Dguide.html&d=BQICaQ&c=Nwf-pp4xtYRe0sCRVM8_LWH54joYF7EKmrYId > > fxIq10&r=ruy1rriFBFoeOJvvQWwN1h8AcdSNT3EVLrdVl7pr-iA&m=ursN85XZ2iI-sVy > > WHNBLpaCvY6dqnDXp4jhYUMYWgv0&s=JkpHV2MuFbknogSmTueOl0W-d8jjFWAxJloZuEZ > > SEhw&e= [3] > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_fou > > ndation_how-2Dit-2Dworks.html-23roles&d=BQICaQ&c=Nwf-pp4xtYRe0sCRVM8_L > > WH54joYF7EKmrYIdfxIq10&r=ruy1rriFBFoeOJvvQWwN1h8AcdSNT3EVLrdVl7pr-iA&m > > =ursN85XZ2iI-sVyWHNBLpaCvY6dqnDXp4jhYUMYWgv0&s=M47Lapn_5bLroA6V2HEU0d2 > > jlGu9eDLkRQEOEXB8Uls&e= >
