Hi everybody,

If it's commercial, the company in question should (and must) allow an
ebuild for is product, like what happens with rpms and other packages.
Adding commercial ebuilds to portage is like tainting the kernel with binary
drivers.

Maybe a better solution comes with gensync? If companies want ebuilds, sure.
They go to the "commercial" portage. Hell, even put a price on maintaining
those ebuilds.

Remember that are a lot of people that don't want to use that kind of
software. There are people that doesn't have even xorg and have to sync all
the ebuilds from portage.

On 9/21/05, Matthew Marlowe <mattm@gentoo.org> wrote:
>
>
> >> We could add a license, called "commercial" into the tree. This license
> >> would look like the following.
>
> I would definitly support adding "commercial" as a license group as part
> of
> GLEP23 implementation.
>
> As part of adding any new commercial license to the tree, developers would
> have
> to add the license to the commercial group.
>
> >> While this will break completely
> >> interactive ebuilds until GLEP23 is fully implemented, a user can add
> >> the license to make.conf in an ACCEPT_LICENSE variable, to keep portage
> >> from asking again.
>
> We wouldnt break anything (hopefully) if we just do this as I specified
> above.
>
> Also, I'm wondering if we truly need check_license in ebuilds. Instead, we
> could
> require that all licenses listed in the commercial group be manually added
> to
> the ACCEPT_LICENSES line /etc/make.conf before emerging. If the license
> wasnt added, emerge would stop and ask the user to add the license
> manually.
>
> Therefore, the user would be explicitely indicating their approval of the
> license by
> adding it. Implementation could be as simple as ACCEPT_LICENSES not
> allowing
> "+commercial" to be defined. It makes no sense, or at least we shouldnt
> encourage
> someone to say they agree to all commercial licenses so easily anyway. The
> default
> portage ACCEPT_LICENSE would be -commercial.
>
> MattM
>
> --
> gentoo-dev@gentoo.org mailing list
>
>