Dne 12.4.2017 v 16:57 Takashi Iwai napsal(a):
On Wed, 12 Apr 2017 16:50:57 +0200, Liam Girdwood wrote:
On Wed, 2017-04-12 at 16:54 +0800, fuweix.tang@intel.com wrote:
From: Fuwei Tang fuweix.tang@intel.com
Add the intel UCM configs to a dedicated UCM conf repo and release them using the BSD license.
We are still missing the LICENSE/COPYING file. We need to add it the top directory level so it's clear to users.
The other non intel UCM files can be moved over when there is agreement with the file authors, but in the mean time they will stay in alsa-lib. The configs are moved from alsa-lib repo. The original authorship and commit message of all config files will be reserved.
Takashi, how do you want to manage the move ? We could add the files to the new repo first and then only delete them in alsa-lib after the next alsa-lib release ? This would give time for distros to pick up the new conf package. I'm easy on whatever works best here.
We really need a consensus before dealing with such patches. It's just a copy / move of some files to another repo, so a patch is just a waste of bandwidth.
If the only question is about the license, why can't we put another license to UCM profiles in the repo, while keeping LGPL for others as is? You can declare it in README or maybe better in another text file to explaining about the licenses in the repository.
I'm asking it because, possibly, UCM syntax may be extended in future, and then there is mismatch with UCM profile and parser. By providing in a single repo, at least, we can avoid the mismatch in the source level.
Other than that, I myself have no objection to factor out to another repo. But, as previously mentioned, it's rather a request to Jaroslav, who maintains the repositories in alsa-project.org.
I'm ready to do anything we settle. There's another option - keep ucm config files in alsa-lib and publish/mirror them also in the separate repository (assuming that there are other frameworks which may use them - like on android). And I agree with the point that the UCM files may have different licence than other files in alsa-lib, because they are not a direct part of the executable binary.
Jaroslav