Version, Timestamp and Copyright

[kunakida]

Rather than being hard coded into source, these resources should be stamped into the MANIFEST.MF file during the build process and accessed at run-time from via the java.util.jar.Manifest class.

[jpaulm]

Sorry, was out all day! This sounds good - however, I was told code modules should also have copyright info as comments. Is this still true?

Also, I like the Artistic license - it seemed the best fit with FBP. Do you feel one of the other ones would work better?

Regards,

Paul

[kunakida]

Hi Paul,

The problem with copyright in the code is that every time it has to be updated for date, all the source files need to also be updated.

This isn't generally a good thing for source files in source versioning systems.

So the idea is to put some sort of static message at the top of each source file,but it should contain a reference to the full copyright notice, usually a separate file contained in the distribution itself.

That should be good enough for other developers, but for programmatic uses, the version and copyright info is usually put into the jar file's manifest (a type of resource file), which is available to the program logic via the Manifest class. The program can then display it where needed, such as UI displays and generated reports (for them that want it) as well as CLI (command line) help.

it is the equivalent of the VERSIONINFO resource Microsoft uses in its dlls and exes.

It should also be useful for maven-type artifact repositories.

The main idea is that the copyright notice and the manifest are not in source control, but are added by the build process automatically.

You cal look here for more info https://en.wikipedia.org/wiki/JAR_(file_format) and here http://docs.oracle.com/javase/tutorial/deployment/jar/manifestindex.html and here http://docs.oracle.com/javase/tutorial/deployment/jar/packageman.html

You could possibly have some other sort of resource file in the jar (like a .properties file), but the manifest is the customary location to put vendor information that everyone is used to.

Oasis (I think) also used to have some sort of plugin component architecture that relied on xml-based manifests for jar files. It was a big deal back in the day, but I don't know where they have gotten to nowadays.

Regards, --Bert

[kunakida]

The licence is a separate issue.

The artistic licence is generally used for icon libraries.

The licence you choose is up to you, but the Apache license and the LGPL are more widely known by businesses (with Apache being considered friendlier)

More recently the Creative Commons licenses are an option e.g. https://creativecommons.org/licenses/by/2.0/

But really it is up to you to figure out what you want to protect.

It is also possible to allow the user a choice of licences. Some libraries are LGPL and Apache dual-licensed to allow for compatibility with both systems.

Regards, --Bert

[jpaulm]

Makes sense! The copyright dates in the source are a bit of a pain! There is a version number in build.gradle, which controls the version number in the jar file name... I also have a version no. and timestamp member in the source code... There is also a version number in the jar manifest - which I see is out of date! Bit of overkill, probably!

Feel free to do some pruning!

Regards,

Paul

On Wed, Jun 8, 2016 at 10:15 PM, kunakida [email protected] wrote:

Hi Paul,

The problem with copyright in the code is that every time it has to be updated for date, all the source files need to also be updated.

This isn't generally a good thing for source files in source versioning systems.

So the idea is to put some sort of static message at the top of each source file,but it should contain a reference to the full copyright notice, usually a separate file contained in the distribution itself.

That should be good enough for other developers, but for programmatic uses, the version and copyright info is usually put into the jar file's manifest (a type of resource file), which is available to the program logic via the Manifest class. The program can then display it where needed, such as UI displays and generated reports (for them that want it) as well as CLI (command line) help.

it is the equivalent of the VERSIONINFO resource Microsoft uses in its dlls and exes.

It should also be useful for maven-type artifact repositories.

The main idea is that the copyright notice and the manifest are not in source control, but are added by the build process automatically.

You cal look here for more info https://en.wikipedia.org/wiki/JAR_(file_format) and here http://docs.oracle.com/javase/tutorial/deployment/jar/manifestindex.html and here http://docs.oracle.com/javase/tutorial/deployment/jar/packageman.html

You could possibly have some other sort of resource file in the jar (like a .properties file), but the manifest is the customary location to put vendor information that everyone is used to.

Oasis (I think) also used to have some sort of plugin component architecture that relied on xml-based manifests for jar files. It was a big deal back in the day, but I don't know where they have gotten to nowadays.

Regards, --Bert

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jpaulm/javafbp/issues/9#issuecomment-224784042, or mute the thread https://github.com/notifications/unsubscribe/AATGJzHN8Npq04gMuQJohIYtoV20RlOtks5qJ3c5gaJpZM4Iv7s6 .

[jpaulm]

I still like the Artistic License 2.0, used for Perl, because it allows for people to sell products which contain JavaFBP. Some licenses force products built on JavaFBP, say, to be open source as well. See http://www.perlfoundation.org/artistic_license_2_0 - hopefully I read it right!

[jpaulm]

Hi Bert,

Following up on this discussion...

If I understand what you are saying, the copyright, version number and date should be in a resource file. I see that build.gradle has some information about what gradle build should put into the jar manifest file, but I haven't been able to figure out how to add more info to it. Alternatively, I could just add this info as a special resource file, and apparently it will get added to the jar file by gradle build. If we go with LGPL, I assume we only have to include the URL for this...?

https://www.gnu.org/licenses/lgpl-3.0-standalone.html

Right? https://www.gnu.org/licenses/lgpl-3.0-standalone.html

If I then take the existing headers out of the source code, I assume I would replace them all with references to the (new) resource file...?

I also have a class called VersionAndTimestamp, which I use to build the About popup - I believe this could be switched to reference the resource file...

If I'm right, eventually the only two places we will have to have version numbers are in build.gradle and the version/timestamp/copyright resource. Does this make sense?

Regards,

Paul M.

On Wed, Jun 8, 2016 at 10:15 PM, kunakida [email protected] wrote:

Hi Paul,

The problem with copyright in the code is that every time it has to be updated for date, all the source files need to also be updated.

This isn't generally a good thing for source files in source versioning systems.

So the idea is to put some sort of static message at the top of each source file,but it should contain a reference to the full copyright notice, usually a separate file contained in the distribution itself.

That should be good enough for other developers, but for programmatic uses, the version and copyright info is usually put into the jar file's manifest (a type of resource file), which is available to the program logic via the Manifest class. The program can then display it where needed, such as UI displays and generated reports (for them that want it) as well as CLI (command line) help.

it is the equivalent of the VERSIONINFO resource Microsoft uses in its dlls and exes.

It should also be useful for maven-type artifact repositories.

The main idea is that the copyright notice and the manifest are not in source control, but are added by the build process automatically.

You cal look here for more info https://en.wikipedia.org/wiki/JAR_(file_format) and here http://docs.oracle.com/javase/tutorial/deployment/jar/manifestindex.html and here http://docs.oracle.com/javase/tutorial/deployment/jar/packageman.html

You could possibly have some other sort of resource file in the jar (like a .properties file), but the manifest is the customary location to put vendor information that everyone is used to.

Oasis (I think) also used to have some sort of plugin component architecture that relied on xml-based manifests for jar files. It was a big deal back in the day, but I don't know where they have gotten to nowadays.

Regards, --Bert