Some files are missing a license header

[pgiffuni]

At least these files have been introduced without a license header (haven't looked exhaustively): src/main/java/bsh/BshArray.java src/main/java/bsh/GeneratedClass.java src/main/java/bsh/Operators.java

I would assume they are meant to carry an Apache License 2 as the rest, but since they were never donated to the Apache Software Foundation they should carry the standard header referred to by the ASF :

Copyright [yyyy] [name of copyright owner]

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.

We should probably scan the code regularly for licensing with something like Apache RAT.

[nickl-]

Tx for checking, I have a mental note to check these files, you are going to catch me a lot with these. It's very much the last thing I think about and by the the buffer is full again. We can add something automated as part of the code style task. I've got the build failing restrictions down to the minimum basically white space as those buggers can really mess with collaboration.

I prefer the shortened version, could we not update everything with this version there seems to be a lot of unnecessary jargon attached. Surely the marketing value for the publication exposure is next to nothing now... I can't imagine that holds any legalise retentions. I can't help but wonder if all this namesake bling in not contributing to the hesitation of a community to get involved. Has everyone pushed to the shadows lurking unsure if they can make it their own. Can you imagine where linux would be if Linus autographed every page. I'm not arguing with the copyright but this is more than that.

[pgiffuni]

Hi; It's understandable .. I mean you are really doing a LOT. It is fine to take things easy and take breaks from stuff like this. I opened the issue just to keep the issue registered somewhere.

This said, license issues are better solved ASAP: it may happen that if you wait for too long you forget where the file came from or you lose contact with the author.

As a sidenote: I wasn't expecting so many "FindBugs" reports. Take those easy as well; don't expect to fix everything in one commit and try to keep a record of the Coverity ID's in the commit log (That's regular practice in another project I am involved with).

[nickl-]

Yes need to find some sleep again. You are welcome to do the admin I certainly don't want it back =) It is really awesome to have someone else pulling at the strings. Thanx! Don't let me stand in your way..

[nickl-]

I wasn't expecting so many "FindBugs" reports. Take those easy as well; don't expect to fix everything in one commit and try to keep a record of the Coverity ID's in the commit log (That's regular practice in another project I am involved with).

You love them coverity don't you =) I don't like that they are not open source and making it free to us is not an act of altruism, they are using us as guinea pigs to test the platform. I'll take the assist in making the code base more reliable but have no warm and fuzzies for it.

Only 95 new defects... I still expected way worse, considering 70% of the unit tests were failing when I started, which only covered 45% of the code base. Most of the defects are reported on the utils as well, the servlet and applets which I've given very little attention so far.

Are you referring to the CIDs of each defect or... hmmm I guess it is the CID cause the defect type doesn't seem to have a code readily available. Mind finding out for me what the work flow is for capturing these while fixing. Why I ask is because these generally fall under specific categories with many of them being fixable in batch with a search replace. Besides you can only know or sure that you squashed them if you analyse again which is after the commit.

I can see the benefit for using this as a deliverable or proof of work but we're not getting paid here. Can't see much bragging rights for having it, if I was that way inclined, rather the contrary they shouldn't have been there in the first place if you were such a rock star. These are all purely maintenance fixes, what I mean is that we do not need to track any of this for a change log or to write documentation. So what exactly do you want with the CIDs in the commits? I think batch fixing them with a "fixes as per coverity" commit message is sufficient unless I am missing something. @pgiffuni Please advise...

[nickl-]

RE: License on new files

@pgiffuni is this in order or what should I put as [name of copyright owner]?

/** Copyright 2018 beanshell.org
 * 
 * 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. */

[pgiffuni]

About the license: beanshell.org is not (legal or natural) person so it cannot be the copyright owner: it should be the person that wrote the code (and that is licensing the code to us). I am not sure it's mandatory though.

[nickl-]

bought by you know whom announced Jun 4, 2018 Fuck!

Nope my ignorance was blissful. There goes the neighbourhood.

GitHub was open source first, corporate 2nd... I don't have an issue with that. Like RedHat, Atlassian... which is completely closed source but 100% free, besides they are web apps for the most part so have some liberties they can take for security sake. Coverity is free like in the nanny lets you have one beer while she watches and tells your parents afterwards.

You know who... well yes they're sneaky at best.

[nickl-]

We (FreeBSD) normally document the CID for reference. Something like this

We have rather strict commit guidelines and all project members have access to coverity so it makes sense to keep such records. In beanshell's case it doesn't matter too much.

Tx for finding the example, I'm still not sure about the workflow... maybe I just need to check the filters or somethting. I'm currently using the coverity_scan branch as a delete, recreate push --force routine. Which is much quicker than trying to merge or rebase and getting out of sync. I also edit commits a lot to add stuff I missed or fix something in the message which doesn't make merging much fun if they get out of sync. Anyway I go through the list of defects and when I analyse again there are always some I missed or it wasn't accepted but the ones that were hit are gone.

If I can think up an easy workflow of fix and capture IDs I'll do it but it seems like a huge effort. Oh yes it also doesn't help that I work on like 10 things in parallel =)