mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Roland Hieber <r.hieber@pengutronix.de>
Cc: barebox@lists.infradead.org, Michael Tretter <m.tretter@pengutronix.de>
Subject: Re: [PATCH v2 0/4] Xilinx Zynq Ultrascale+ MPSoC support
Date: Thu, 29 Nov 2018 11:37:56 +0100	[thread overview]
Message-ID: <20181129103756.lob2uu32t7oloxjx@pengutronix.de> (raw)
In-Reply-To: <20181129095038.t4s2gzvehvvfdd27@pengutronix.de>

On Thu, Nov 29, 2018 at 10:50:38AM +0100, Roland Hieber wrote:
> On Thu, Nov 29, 2018 at 09:14:01AM +0100, Sascha Hauer wrote:
> > On Wed, Nov 28, 2018 at 04:13:57PM +0300, Antony Pavlov wrote:
> > > At the moment barebox uses SPDX identifiers in very few files.
> > > 
> > > Can we adopt Linux kernel licensing rules for barebox?
> > > (https://github.com/torvalds/linux/blob/master/Documentation/process/license-rules.rst)
> > 
> > I really like the idea of using SPDX, but I never looked into what is
> > necessary to use it. Adopt this license-rules file, change the headers
> > in the files and be done with it?
> 
> "Necessary" depends. Having SPDX-License-Identifier tags in source files
> is usually enough for people who know what SPDX is, but for all the
> other people and to allow automated license compliance checks with
> tools, we also need the rest what the kernel documentation describes.
> I think forking that doc would be okay.
> 
> I stumbled into that problem already when I tried to package barebox for
> Debian [1], the problem here is that the files in the barebox source
> tree are historically grown and have different styles of headers and
> other quirks in the formatting, which make it rather impossible to
> throw it into tools to find out copyright holders. SPDX seems the way to
> go for machine-readable license annotations, and many projects already
> use it.

Well it's one thing to get the ball rolling and another to convert all
source files. Since we already started to import source files with SPDX
tags I think we should make this official, convert the files which can
be automatically converted and yes, the conversion of the remaining
files will probably take more time, but we do not need to do all at
once.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2018-11-29 10:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-28 11:20 Michael Tretter
2018-11-28 11:20 ` [PATCH v2 1/4] ARM: lib64: .gitignore barebox.lds Michael Tretter
2018-11-28 11:20 ` [PATCH v2 2/4] ARM: aarch64: compile with general-regs-only Michael Tretter
2018-11-28 11:20 ` [PATCH v2 3/4] ARM: aarch64: add ENTRY_PROC macro for arm64 Michael Tretter
2018-11-28 11:20 ` [PATCH v2 4/4] ARM: zynqmp: add support for Xilinx ZCU104 board Michael Tretter
2018-11-28 13:13 ` [PATCH v2 0/4] Xilinx Zynq Ultrascale+ MPSoC support Antony Pavlov
2018-11-29  8:14   ` Sascha Hauer
2018-11-29  9:50     ` Roland Hieber
2018-11-29 10:37       ` Sascha Hauer [this message]
2018-12-07 10:11 ` [PATCH v3 " Michael Tretter
2018-12-07 10:11   ` [PATCH v3 1/4] ARM: lib64: .gitignore barebox.lds Michael Tretter
2018-12-07 10:11   ` [PATCH v3 2/4] ARM: aarch64: compile with general-regs-only Michael Tretter
2018-12-07 10:11   ` [PATCH v3 3/4] ARM: aarch64: add ENTRY_PROC macro for arm64 Michael Tretter
2018-12-07 10:11   ` [PATCH v3 4/4] ARM: zynqmp: add support for Xilinx ZCU104 board Michael Tretter
2018-12-10  9:13   ` [PATCH v3 0/4] Xilinx Zynq Ultrascale+ MPSoC support Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181129103756.lob2uu32t7oloxjx@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=m.tretter@pengutronix.de \
    --cc=r.hieber@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox