[arch-dev-public] License rebuild: last step

[Eric Bélanger]

On Mon, May 4, 2009 at 1:52 AM, Allan McRae <allan at archlinux.org> wrote:
> Eric Bélanger wrote:
>>
>> Hi
>>
>> The license rebuild for core/extra is almost done. Only a few
>> problematic packages remains. I'll post the list here with potential
>> solutions. Read along and comment/discuss as apropriate.
>>
>
> First up, a big cheer for Eric here!  He has done a lot of work to get this
> finished.

Thanks.

BTW, this will need to be done for the community repo as well although
we'll need to wait until it uses svn before hosting the (L)GPL sources
of community packages. However, I won't be doing it. I've done enough
rebuild for a while.  It will be up to these packages' maintainers
and/or TUs. I've made a list:
http://wiki.archlinux.org/index.php/User:Snowman/License_Rebuild_TODO#Community_repo_x86_64_TODO_list
and there's a bug report in flyspray.

>
> <snip>
>>
>> codecs:
>> emovix-codecs:
>> - There is no license information in the tarball or on mplayer's site.
>> <snip>
>> If we assume that we are allowed to package these codecs, my favorite
>> license is the NetBSD one.  Only avifile in community has a specific
>> depends on codecs. If it's not a true dependency like in mplayer (not
>> tested), we could just remove them from the repo.  Any comments?
>>
>
> Can't we just use "unknown" as in the packages below.
>

We could. But these codecs were made by big companies with money and
lawyers and they care about licensing issues much more than the
creators of vim plugins, say. I'm thinking that it might be better to
have something more explicit. If the consensus is that  "unknown" is
OK, then we could go with it.

>
>> dgen-sdl:
>> FS#12564 and license issue. x86_64 package will probably be removed
>> because of this. I guess I could go ahead and add the license to the
>> i686 package.
>>
>
> Or the whole package could go to unsupported...

That's another possiblity. That was my initial intention before
realizing that removing the x86_64 package would be enough to fix the
issue. It has a usage of 4.67 % so it's not really popular.


In fact, for the rest of
> the packages with issues you mentioned, I am fine with them going to
> unsupported.  Most seem to be cruft at first glance.
>
> Allan
>
>
>
>