Add SPDX identifier

[afs]

Should Jena include the SPDX-License-Identifier tag?

If done in the header for Java files, it would look like:

/*
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you 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.
 *
 *   SPDX-License-Identifier: Apache-2.0
 */

[neumarcx]

Yes, it would be a good idea to include SPDX-License-Identifier tag.

[afs]

@Claudenw - what's your impression of the current best practice across ASF?

A quick search of ASF didn't find many places where it has been adopted wholesale - not surprising - the header already has a URI for the license text in it.

Scanning tools, RAT, github et al., have to-date been working with matching "known text" and that is unlikely to go away.

[arne-bdt]

I don't understand why millions of file headers (including other projects and other licenses) need to be changed when other tools work fine with the current license texts.

Why are the SPDX project and tools placing such a heavy burden on existing projects when they could technically adapt to what already exists?

[afs]

Existing tools are fragile.

• reformated license text
• some licenses have text that changes (e.g. BSD, MIT include the copyright holder name)
• use of modified licenses which take the text of an OSS license and add or change clauses, often making it not OSS
• imprecise : GPL-2.0 != GPL-3.0 (in fact, they conflict!); "GPL 2 or later".

For modified licenses, humans scan the first part and think it an XYZ license when in fact it isn't.

The AL2 header is already great - it has a URI in it!

[afs]

I'm getting closer to changing the license headers. For the actual change, but after that, the com.mycila:license-maven-plugin can be used to check (probably not automatically as its handling of sub-modules seems to require absolute file names).

I haven't manged to get the plugin to make the change. It does not put in a blank line after the license, before package ....

#3589 went though the code base and made all the license headers the same bytes exactly.

The next choice is the exact bytes of the new header.

There are two choices - differing only on the length of lines.

Both styles are in use in Apache projects.
Jena currently has hybrid (see issue description) - short-line first paragraph and long-line second paragraph.

https://www.apache.org/legal/src-headers.html is the Foundation policy text.
Using https is acceptable.

Realistically, only java files will be changed for Jena 6.0.0, maybe POMs. POMs should be simple ; scripts probably do have some variations.

Longer line form:
74 wide columns
16 lines

/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements. See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You 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
 *
 *   https://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.
 * 
 *   SPDX-License-Identifier: Apache-2.0
 */

Alternative: formatted for shorter lines and 2 lines longer.
63 wide columns
18 lines

/*
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you 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
 *
 *   https://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.
 *
 *   SPDX-License-Identifier: Apache-2.0
 */

For reference, the exclusions for java are:

org/apache/jena/sparql/lang/sparql_10	SPARQL 1.0 Parser - generated
org/apache/jena/sparql/lang/sparql_11	SPARQL 1.1 Parser - generated
**/org/apache/jena/ext	Source code from other projects, e.g Xerces (all AL2)
**/javacc	All active javacc code now goes into a javacc directory
org/apache/jena/riot/thrift/wire	Thrift generated
org/apache/jena/web/HttpSC.java	Code from Eclipse Jetty
org/apache/jena/fuseki/servlets/CrossOriginFilter.java	Code from Eclipse Jetty

[rvesse]

I'm getting closer to changing the license headers. For the actual change, but after that, the com.mycila:license-maven-plugin can be used to check (probably not automatically as its handling of sub-modules seems to require absolute file names).

Typically the way I've "hacked" around this in the past is to define the path to the expected license text using a Maven property in the plugin configuration e.g.

<header>${license.header.path}/header.txt</header>

And then in each sub-module you redefine the property appropriately for that module e.g. for the root pom.xml

<license.header.path>${project.basedir}</license.header.path>

For sub-modules use .parent to refer to parent module e.g.

<license.header.path>${project.parent.basedir}</license.header.path>

Multiple levels of .parent can be used for more deeply nested sub-modules e.g.

<license.header.path>${project.parent.parent.basedir}</license.header.path>

Then the only gotcha becomes ensuring that you remembered to set the property correctly in every child module which is a one-time thing unless you start reorganising how modules are structured in your repository