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 <[EMAIL PROTECTED]> 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
