[FEATURE] Switch to SPDX license identifiers

[dbaluta]

What is your take on switching to SPDX identifiers [1]? The license text at the beginning of each file makes code harder to read.

[1] https://spdx.org/ids-how

[plbossart]

need to consult with Intel Legal, stay tuned.

[plbossart]

Answer: using the SPDX header instead of license text is actually Intel's recommended practice

If anyone has an objection it's time to voice it now, or we'll go ahead and do it for all Intel-contributed files. Note that the same idea of using C++ comments for .c files and C comments for .h files applies.

[dbaluta]

Great news. What about the files inherited from Cadence? I think we can keep them like that.

[jajanusz]

We can use SPDX, but this one is weird ->

Note that the same idea of using C++ comments for .c files and C comments for .h files applies.

I see they use it like that in kernel, but why? Cannot we just use one type of comments?

[plbossart]

On 5/22/19 5:45 AM, Janusz Jankowski wrote: We can use SPDX, but this one is weird -> Note that the same idea of using C++ comments for .c files and C comments for .h files applies. I see they use it like that in kernel, but why? Cannot we just use one type of comments?

My note was precisely to avoid this sort of debates and state a 'same as kernel' solution. There's been countless debates on this in kernel cycles. I believe it's because headers can be shared and used in other areas where C++ comments are not accepted. It's a convention, let's stick to it and avoid wasting cycles on cosmetic stuff. If there are multiple equivalent solutions, the majority wins.

[dbaluta]

The history goes like this:

When SPDX was discussed to be used inside the Linux kernel everybody agreed to use C++ style comments (//) for all the code.

Now the problem was that with old binutils ld failed to parse C++ style comments in .c files so they switched to C++ comments only to .c files :).

Nowadays, ld is fixed but due to historical reasons they kept the old convention.

So, they ended up with these rules:
https://elixir.bootlin.com/linux/v5.2-rc1/source/Documentation/process/license-rules.rst#L71

Now, I think it is a good idea for us to stick with them. Anyhow, in sound tree Mark prefers to use only C++ comments at the beginning of the .c file.

Like this:

 // SPDX-License-Identifier: GPL-2.0
 //
 // Audio driver for AK4458 DAC
 //
 // Copyright (C) 2016 Asahi Kasei Microdevices Corporation
 // Copyright 2018 NXP
 

and only C comments inside .h files. Like this:

/* SPDX-License-Identifier: GPL-2.0 */                                                                                                                                                                             
/*
 * Audio driver for AK4458
 *
 * Copyright (C) 2016 Asahi Kasei Microdevices Corporation
 * Copyright 2018 NXP
 */

Can we agree to use the same convention in SOF fw code?

[plbossart]

On 5/22/19 1:41 AM, Daniel Baluta wrote: Great news. What about the files inherited from Cadence? I think we can keep them like that.

Let's keep them as is. Finding out whom to speak with at Cadence on this is time I just don't have.

[lgirdwood]

ACK

[jajanusz]

@dbaluta Thanks for info.
@plbossart Agree with your points, just wanted to know if there is some reason I don't know about.

[jajanusz]

@lgirdwood @plbossart @dbaluta So I guess we agree for this change?
If so, I'd like to update files that we already have and require from authors of PRs that add new files to have SPDX identifiers in them.

[dbaluta]

@jajanusz you have the green light from me. Please mind the example I provided in a comment above on how to add comments for .c and .h files.

Please send the PR and we can discuss on that.

[plbossart]

On 5/24/19 6:47 AM, Janusz Jankowski wrote: @lgirdwood <https://github.com/lgirdwood> @plbossart <https://github.com/plbossart> @dbaluta <https://github.com/dbaluta> So I guess we agree for this change? If so, I'd like to update files that we already have and require from authors of PRs that add new files to have SPDX identifiers in them.

Agreed, thanks.