Add license

[elamn1]

This software doesn't have a license, would you please add it?

[sbot50]

AFAIK no license means you can do anything with it, plus the license they would use probably would also state that you can do anything with it. So does it really matter that much?

[FintasticMan]

That's incorrect; no license means it's not defined what you can do with the software, so the owners of the code (who are not with PINE64) own the rights and can decide what's allowed to be done with it. It would be a good idea IMO to get some concrete statements from the owners of the code about licensing.

[SethFalco]

FintasticMan is correct, it's more formally described as "All Rights Reserved". Rights to IP are almost never granted, unless explicitly granted.

Here is a nice write-up by GitHub that explains why including a license is important:

If you find software that doesn’t have a license, that generally means you have no permission from the creators of the software to use, modify, or share the software.

— https://choosealicense.com/no-permission/

In other words, OpenPineBuds is not open-source, until they include the license. However, in theory, it can never really be fully open-source at all anymore, unless Pine64 contacts every contributor to retroactively get permission to license it or otherwise remove their contributions.

The longer maintainers take to add the license, the more complicated the matter becomes. This really should be prioritized, and all contributors asked to agree to whatever license is proposed.

[FintasticMan]

I agree that we should prioritise figuring out a way to license this code, the issue is that this repository is based on code that PINE64 was granted permission to use by some Chinese company. As far as I'm aware, the conditions of that agreement have not been made public. To add a license, we would need not only the approval of all the contributors as well as from that company.

[shymega]

Yes, this is an issue. We could use a CLA bot to get the contribution copyright signed over to Pine64. I don't know if that's a good idea.

The problem remains of tracking down all contributions and resolving SDK copyright from BES. I don't think they'll allow it [copyright] to be transferred to an open-source license.

They might do, but I doubt it, from my experience with Chinese ODM/OEMs.

I'll hand this over to @gamelaster and @Ralim for their input on this issue - I'm new to the project, but we've discussed things in depth recently.

[SethFalco]

I wasn't aware of the Chinese ODM/OEM thing, so I appreciate that you both raised it.

I do hope that one way or another, it'll be possible to get open-source firmware. Be it through this repository or something similar, where the offending code is superseded. 👍

However, at least some clarity on the license terms would help then. Especially as the README explicitly states that this is open-source when it's not, at least not by the OSI definition, which I think most people would imply. ^-^'

This is ofc a complicated matter, so I appreciate it'll take time to figure everything out. But if indeed there are licensing issues, it may be worth revising the README to either omit the term "open-source", or at least replace it with "source accessible".

[shymega]

We have discussed replacing Makefiles with CMake, and my long-term goal is to convert the firmware over to Rust - plus simplify the linker scripts. This may reduce the offending code.

I'll probably hold fire on future PRs until we've sorted the copyright issues. However, I'll make a PR to the README shortly, just to clarify.

I'll link to this issue in the PR when I commit.

[Ralim]

So we need to plan for this case:

resolving SDK copyright from BES. I don't think they'll allow it [copyright] to be transferred to an open-source license.

No matter what I've asked, its been silence from them on this; it appears they do not want any transfer of their existing code/binary blobs to a different licence. It seems they are ok with source-available of it (and given this SDK is all over csdn, its not really a secret).

At this point I would suggest we adopt a licence for our changes and new content at the minimum; and have a goal of eventually removing all of the existing dubious licensed code.

[OneDeuxTriSeiGo]

Since it looks like the project will have different files under different licenses, I'd recommend using something like the REUSE spec [1] and the Debian Copyright (DEP5) format [2] as they are machine readable and have tooling for automatic verification (reuse-tool) [3].

This would involve listing all the licenses in LICENSES/ with the names matching the SPDX identifiers (LICENSES/MIT.txt for FreeRTOS files and LICENSES/LicenseRef-BES.txt for the propriety BES license).

Additionally you'd create a file (.reuse/dep5) that contains all the DEP5 copyright data for any files that you can't include a header in for whatever reason.

The reuse tool can then verify that licenses are identified and properly marked for every file prior to PR merges.

And if you want to list all licensing in one place, you can generate a full DEP5 style license manifest (named either LICENSE, COPYING, or COPYRIGHT) using Debian's decopy tool [5] with the .reuse/dep5 file as a base.

1. https://reuse.software/
2. https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
3. https://github.com/fsfe/reuse-tool
4. https://github.com/fsfe/reuse-tool/blob/main/.reuse/dep5
5. https://salsa.debian.org/debian/decopy

[gamelaster]

@OneDeuxTriSeiGo we have some update about this. We found identical BES files with the ones in our SDK, with Apache license in AliOS repository (I am on phone right now, so I can't send link). Thus, we can relicense those files. For other files, we already asked Pine Store for help, so it should be resolved soon.

[shymega]

Since it looks like the project will have different files under different licenses, I'd recommend using something like the REUSE spec [1] and the Debian Copyright (DEP5) format [2] as they are machine readable and have tooling for automatic verification (reuse-tool) [3].

This would involve listing all the licenses in LICENSES/ with the names matching the SPDX identifiers (LICENSES/MIT.txt for FreeRTOS files and LICENSES/LicenseRef-BES.txt for the propriety BES license).

Additionally you'd create a file (.reuse/dep5) that contains all the DEP5 copyright data for any files that you can't include a header in for whatever reason.

The reuse tool can then verify that licenses are identified and properly marked for every file prior to PR merges.

And if you want to list all licensing in one place, you can generate a full DEP5 style license manifest (named either LICENSE, COPYING, or COPYRIGHT) using Debian's decopy tool [5] with the .reuse/dep5 file as a base.

1. https://reuse.software/
2. https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
3. https://github.com/fsfe/reuse-tool
4. https://github.com/fsfe/reuse-tool/blob/main/.reuse/dep5
5. https://salsa.debian.org/debian/decopy

You may not have seen what I said in the Discussions area, but that's precisely what I aim to do.

[OneDeuxTriSeiGo]

[...]

You may not have seen what I said in the Discussions area, but that's precisely what I aim to do.

Ah yep. I see that comment now. I'm open to help out where I can but it'll probably take me a little bit to get acquainted with everything (Just got my pinebuds in the mail a week ago and was looking through the repo when I came across this issue).

[gamelaster]

This is file which we have in our SDK and it's Apache 2
licensed. https://github.com/alibaba/AliOS-Things/blob/a99f20706f9c666903a12a205edce13263b1fadb/hardware/chip/haas1000/drivers/services/nv_section/aud_section/aud_section.h#L77

If anyone can check out how many files are same, it would be great. Thanks

[shymega]

@OneDeuxTriSeiGo It's gonna take a while to get going. I've branched the reuse branch from cmake, so that we can base the licensing from the new changes on cmake branch. However, I cannot figure out howto specify the non-free license in REUSE.

Any ideas?

[OneDeuxTriSeiGo]

@OneDeuxTriSeiGo It's gonna take a while to get going. I've branched the reuse branch from cmake, so that we can base the licensing from the new changes on cmake branch. However, I cannot figure out howto specify the non-free license in REUSE.

Any ideas?

Oh easy. Any non-standard licenses can be declared by including them in a file named LICENCES/LicenseRef-${name}.txt (where ${name} is the name/identifier for the licenses) along with the other standard licenses like LICENSES/Apache-2.0.txt, etc.

Then just tag the license ID ${name} in each file's header, in a corresponding ${filename}.LICENSE file, or in the dep5 for the project (.reuse/dep5).

[shymega]

Huh. That was easier than I expected. I guess we need @gamelaster to get the full license Pine64 got from BES, so we can copy it into the repository.

[OneDeuxTriSeiGo]

yep. luckily REUSE is pretty simple to deal with. Do we by chance know the licenses for the audio assets?

I ask as REUSE will want us to label all files in the repo with a license either via a .LICENSE file or via dep5.

[shymega]

I don't know myself. (cc: @gamelaster @Ralim)

I think I'd rather reduce the amount of .LICENSE files, for sure. Can we store that info in dep5?

For now, I'll need all the help I can get with this undertaking. CMake and REUSE.

[OneDeuxTriSeiGo]

I think I'd rather reduce the amount of .LICENSE files, for sure. Can we store that info in dep5?

Yeah. personally that's my preferred way of handling it when we can't include it in a header file. So for example we'd just list all the audio files (or just glob the folder) and tag it with whatever license those are under.

For now, I'll need all the help I can get with this undertaking. CMake and REUSE.

I think rather than basing the REUSE branch on top of CMake, it might be worthwhile to split the CMake branch into a "restructure repository" branch and the CMake branch on top of that. That way the REUSE work can all be done on top of that restructure branch and we won't need to deal with any potential divergence between the REUSE and CMake branch. also that might simplify reviewing both the CMake and REUSE branch since it won't have 2k+ files changed.

I can see if that can be done fairly easily and if it can I'll put those updated branches onto my fork and link back here. After that

I can start working on the REUSE branch so you can focus on the CMake stuff. I can also help with CMake if you need it.

Edit: I'll just leave the branch as is and wait to make it a non-draft PR until after cmake is done and I'll just rebase it onto main

[OneDeuxTriSeiGo]

Also just to confirm:

• Any file which can be proved to have an equivalent source licensed under Apache-2 will be relicensed as Apache-2
• Any file which cannot be proved to have an equivalent source licensed under Apache-2 will keep the BES license.

Do we just want to have all new contributions under the Apache 2 as well?

[OneDeuxTriSeiGo]

Also @shymega can we license the CMake stuff under whatever license we use for the main repo (assuming Apache-2 for now)?

[OneDeuxTriSeiGo]

Also worth noting that the RTOS (RTX) is partially licensed under its own license as well. IDK how far that goes but not all of the headers have licenses attached.

[Ralim]

I guess we need @gamelaster to get the full license Pine64 got from BES, so we can copy it into the repository.

(Sadly)
The way this licensing goes down, there isnt even a licence in writing. Its a spoken agreement that occurred between TL and bes. There is currently no licence in western terms. Its similar to the source code you can find on osdn that is provided as-is with no licence. We have the ok for this to be public for use with their parts; for pine products; and for us to evolve this and add features etc. But nothing really more concrete than that.

TL is going to try and get them agree to something more concrete but we have (A) no promise that will occur (B) they cannot re-licence the RTX stuff really, which is a main goal in moving off it once we have things sorted out.

Edit:

Meant to add that we should figure out what we can plan for if we don't ever get licencing information on the files we can't match up to having already been licenced. I'm not opposed to making a list of them and reimplementing or replacing them as a matter of urgency. For RTX we have the ability to replace it with freertos easier as that's part of their supported options. At least as a stop gap.
The blobs will be messy as always though. 😢

[OneDeuxTriSeiGo]

At this point I have a list of all the files that could be easily identified with a license and am going through all the remaining files one by one to figure out:

1. whether they have any indication of a license,
2. whether they exist in the other repo licensed under a different license (Apache 2.0)
3. who created or modified them/who we need to confirm with to update the license for that file.

I'll open a PR with a giant table containing all this in the comments so that we can get written OKs from everyone to re-license (or find a plan to use an alternative so we don't step on feet).

Some of the important details based on what I've come across so far:

1. It looks like parts of the GNU libc were just copied into utils/libc. These are GPL licensed and while technically there's a provision in the license for allowing these files to be used by software that isn't GPL as long as you compile with GCC, I don't know if how we are distributing them would cause any problems with that.
2. We distribute files in utils/crc16 which are quite clearly lifted from the linux source code. I think we might distribute some other files that came from the linux source but nothing that is still carrying a GPL header in it. I'll try to look into the other suspect files but worst case I'll just tag their origin as questionable and we can consider replacing them down the road.
3. We source a header from sony with no associated license. Since it's a header that describes the interface for the associated binary blob we can probably get away with it but I'd much rather get clarification of what license they acquired this under and if we could get it licensed under something explicit.
4. We distribute the FDK AAC codec which while under a free software license, it isn't a standard free software license and we will probably need to have someone qualified read through it once we get everything sorted to verify that we are complying with it and that it is compatible with all the other licenses.

[shymega]

Thank you for your work. I am a little worried about my CMake and Rust branches, and if my work will need adjusting for the upcoming PRs with REUSE support... any thoughts on reducing merge conflicts?

Cheers.

[OneDeuxTriSeiGo]

Thank you for your work. I am a little worried about my CMake and Rust branches, and if my work will need adjusting for the upcoming PRs with REUSE support... any thoughts on reducing merge conflicts?

I am basing my changes off of 5521f97 which is the first commit of your CMake branch since everything after that is just new CMake files and all you'd need to do is go back and put licenses/SPDX tags on those files. After my branch gets PRed, reviewed, and hopefully merged, your PR should just move up one commit with that base commit now being part of the shared history and your merge should otherwise go through as if it went through now.

I noticed however that your second commit moves a bunch of files in the ANC directory out of their include/src dirs into the same dir. Is there a reason for that given it's the only section you did that for? That would be the only possible conflict but even then it should be pretty easy to resolve.

[shymega]

Ah, okay.

Yes, the reason I did that was to simplify the hierarchy.

[OneDeuxTriSeiGo]

As for the rust rewrite, I'm not sure how much has been done on it so far but would it be worthwhile to break that out into its own repo instead? If you need to reference code from this repo, you could just fetch it in a build.rs script and base it off a pinned commit. That might honestly be easier than trying to balance 2 separate implementations in the same repo with shared components. Also it might get us some distance from the pretty hefty size of this repo thanks to the embedded binary blobs inside it currently.

That discussion is probably out of the scope of this issue so we could continue it in #pinebuds or in another issue.

[OneDeuxTriSeiGo]

Yes, the reason I did that was to simplify the hierarchy.

Ah. I'm not inherently opposed to the change but I think whatever we do we need to be consistent about it. Also any changes in the repo structure we make will make integrating new changes from other trees more difficult. With the move of the top level directory it isn't so bad because we can replicate that pretty easily but if deeply nested directories start getting moved around, that may make pulling in changes harder.

IDK if we intend on even doing that so that might not be a concern but I figured it was worth mentioning.

[shymega]

It was also due to the file (GLOB .. command in the CMakeLists.txt.

I might change it back - not sure yet. I wanted to make it simple, and didn't want too many file (GLOB .. commands, so I just moved the includes.

[OneDeuxTriSeiGo]

ah.

I'd personally recommend avoiding globs for marking sources as I've been bitten in the ass by them in the past (and on top of that CMake docs recommend avoiding them as well).

From [1]:

Note

We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate. The CONFIGURE_DEPENDS flag may not work reliably on all generators, or if a new generator is added in the future that cannot support it, projects using it will be stuck. Even if CONFIGURE_DEPENDS works reliably, there is still a cost to perform the check on every rebuild.

1. https://cmake.org/cmake/help/latest/command/file.html#filesystem

[shymega]

ah.

I'd personally recommend avoiding globs for marking sources as I've been bitten in the ass by them in the past (and on top of that CMake docs recommend avoiding them as well).

From [1]:

Note
We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate. The CONFIGURE_DEPENDS flag may not work reliably on all generators, or if a new generator is added in the future that cannot support it, projects using it will be stuck. Even if CONFIGURE_DEPENDS works reliably, there is still a cost to perform the check on every rebuild.

1. https://cmake.org/cmake/help/latest/command/file.html#filesystem

Yeah, I used globs based on another CMake project I help maintain. Seemed to have worked there.

What do you make of using a solution like this?

I'd prefer to use globs to recursively collect headers and sources - I don't want to add each one manually, there's loads.

[OneDeuxTriSeiGo]

What do you make of using a solution like this?

I'm not inherently against it. It's definitely better than plain globs. And if we were to do that, rather than try to do a switch, it'd be preferable to just set the minimum CMake version to 3.11.

I'd prefer to use globs to recursively collect headers and sources - I don't want to add each one manually, there's loads.

Given that there's a fairly small number per sub project (but a metric ton in total), If you don't mind them being there but don't want to deal with the monotony of adding them, I can go through and do the grunt work to replace globs with declarative header/source lists after I finish up the license stuff. I'm pretty sure there are actually scripts that exist which do this automatically once all the CMakeLists.txt files are set up but I'd have to go digging to see if I can find them (or slap one together myself).

[shymega]

Yeah, I suppose backwards compatibility is a factor.

If you do find the script, I can do that - can you ping me on Telegram when you find it?

Thanks.

[OneDeuxTriSeiGo]

Yeah, I suppose backwards compatibility is a factor.

If you do find the script, I can do that - can you ping me on Telegram when you find it?

Thanks.

Sure.

[shymega]

OK, so with regards to app_anc, I've edited (and rebased, so prepare for force pulls/push) the structure to retain what it originally had. I think we should keep a similar structure for all subdirectories - i.e.: inc and src.

We can then use target_include_directories.

I don't know if this will affect your branch.

I also added a linking directive to apps_anc. Other apps will need a similar adjustment.

[OneDeuxTriSeiGo]

OK, so with regards to app_anc, I've edited (and rebased, so prepare for force pulls/push) the structure to retain what it originally had. I think we should keep a similar structure for all subdirectories - i.e.: inc and src.

We can then use target_include_directories.

I don't know if this will affect your branch.

I also added a linking directive to apps_anc. Other apps will need a similar adjustment.

awesome. as im working off only the first commit of your series, this should mean that now we have no conflicts whatsoever and the merge should probably go through without requiring any further changes from either of us.

[shymega]

Yeah, you might need to rebase though. I edited the commit back in the history, so it's been rewritten. It's in the cmake branch still, and I had to recreate the rust branch. However, that had no Rust commits in it.

[OneDeuxTriSeiGo]

I've been working on the license identification for a while now and I can finally start presenting some results. I'm keeping them in a separate repository since they are fairly extensive and wouldn't fit easily in a single file.

As of this post, the master branch has the analysis of upstream sources. The working branch contains a preliminary pass of all files that are open sourced elsewhere on the internet but I still need to identify alt sources for those open sourced files that have been significantly modified but don't include a license header in our version.

Once that's done, I'll pin the commit hashes for the alt sources and generate the diffs for the repository.

I'm also working on generating the lists of contributors per file and I'll focus on finishing that once the rest of the copyright license source identification is done.

https://github.com/OneDeuxTriSeiGo/openpinebuds-source-analysis/

What's left after this:

• compile list of BES licensed sources that will be the highest priority for re-licensing.
• compile secondary list of "nice-to-have" BES licensed sources for re-licensing.
• add copyright and license details to files for REUSE compliance.
• collect and verify signoffs for relicensing.
• decide on a new license to relicense to.

there's more to do after that of course but getting through this list should be the brunt of it.

[shymega]

Really great work on this. Wouldn't know where to start, myself.

Also, to avoid burnout, don't feel you're obliged to do this. Take any and all breaks you need - we'll still be here :)

[OneDeuxTriSeiGo]

So we need to officially decide on a license still. I'm not sure what the decision making process is but I'm putting forward 3 suggestions (listed below). I'm also planning that any files with an established upstream be dual licensed as the original license OR our license rather than AND so we can attempt to upstream changes where possible.

I will list each option in a comment below. thumbs up the ones you support and thumbs down any that you refuse to support/use.

---

• LGPL-3.0-or-later

  • Strong Copyleft.
  • Copyleft only applies to "our" code.
  • Compatible with closed sources as they can stay closed as long as the LGPL code can be modified. i.e. as long as they provide object files (if they don't provide source code) and the ability to flash new firmware to the device.
  • Probably the easiest copyleft license to use while refactoring partially closed source files into an open source and closed source component.

• MPL-2.0

  • Strong Copyleft.
  • Copyleft is only per file so it doesn't "spread" like the GPL does.
  • Compatible with closed source files as it acts on a per file basis.

• Apache-2.0

  • Permissive
  • Easily compatible with closed source code as it doesn't require the closed source code to be open sourced.
  • Easiest to attempt upstreaming changes with if we only use one license.

---

For context the following licenses are currently in use in the repo:

• MIT
• BSD-2
• BSD-3
• Apache-2.0
• FDK AAC Codec License (modified BSD license)
• GPL-2.0 (utils/crc16/crc16.{c,h} which will need to be replaced as the GPL is incompatible with closed source code)
• GPL-2.0-or-later OR MIT (can be used as either or so we can treat it as MIT).
• GPL-2.0-or-later WITH GCC-exception-2.0 (still GPL but if we want to support clang, we'll need to replace this file)
• Closed sources

[OneDeuxTriSeiGo]

LGPL-3.0-or-later (👍 for support, 👎 to veto)

[OneDeuxTriSeiGo]

MPL-2.0 (👍 for support, 👎 to veto)

[OneDeuxTriSeiGo]

Apache-2.0 (👍 for support, 👎 to veto)

[shymega]

Hi,

Are there any updates ?

No, and asking pings everyone involved in this issue - please see #76 and subscribe to this issue and that one for notifications.