On 26.11.24 17:44, Anthony PERARD wrote:
On Fri, Nov 22, 2024 at 04:12:25PM +0100, Jürgen Groß wrote:On 22.11.24 14:55, Anthony PERARD wrote:On Wed, Oct 23, 2024 at 03:10:03PM +0200, Juergen Gross wrote:diff --git a/tools/include/xenmanage.h b/tools/include/xenmanage.h new file mode 100644 index 0000000000..2e6c3dedaa --- /dev/null +++ b/tools/include/xenmanage.h @@ -0,0 +1,98 @@ +/* + * Copyright (c) 2024 SUSE Software Solutions Germany GmbH + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; + * version 2.1 of the License. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; If not, see <http://www.gnu.org/licenses/>.Shall we use SPDX tags instead of this boilerplate?My thinking was to avoid that for "official" header files, as those might be copied verbatim to other projects, which might not use SPDX. So having the license text verbatim avoids any problems in this regard.Well, this header in particular would be fairly useless, I believe, if it was copied into an other project, it described a library so need to be distributed along side the library. Second, this isn't the text of the license but something describing which license is used and where to find the text for it. An SPDX tag does nearly the same thing, but can actually be parse by a computer. Official headers that would be useful to be copied into other project already expose the SPDX tags, many/all the headers in xen/include/public, as well as headers created by `mkheader.py` in this directory (tools/include). I've taken a look into my directory "/usr/include", and they are plenty of headers having the SPDX tag. So overall, I think we are fine to use SPDX tags here as well. ;-)
Okay, I'll switch to SPDX. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
