From: guido@trentalancia.com (Guido Trentalancia)
Date: Fri, 07 Sep 2012 14:51:06 +0200
Subject: [refpolicy] state of core/contrib split
In-Reply-To: <5049E761.7020002@tresys.com>
References: <5048D6E2.3030303@tresys.com> <5048DA26.3080703@trentalancia.com>
	<5049D3CE.7020806@trentalancia.com> <5049E761.7020002@tresys.com>
Message-ID: <5049EDBA.30502@trentalancia.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 07/09/2012 14:24, Christopher J. PeBenito wrote:
> On 09/07/12 07:00, Guido Trentalancia wrote:
>> On 06/09/2012 19:15, Guido Trentalancia wrote:
>>> On 06/09/2012 19:01, Christopher J. PeBenito wrote:
>>>> The core/contrib split in the refpolicy repo has been around for a year.  Unfortunately, I don't think it has gone as originally planned, as the people with commit access haven't really been committing anything.  Differences between refpolicy and distro policies are pretty severe in some cases.  What can we do to improve the situation?
>>>
>>> In my opinion, file contexts are probably impossible (or at least
>>> extremely expensive) to tackle in a one-fits-all way for all possible
>>> distributions and at the same time they are sort of silly blockers.
>>
>> In addition to the above, simple patches sometimes don't get through.
>>
>> Take for example, the cpucontrol module patch that I recently posted. It
>> just ended up in nothing without sufficient follow-up.
>
> I'm not sure why you're saying this about cpucontrol.  From what I can see in my emails, I gave you feedback, and you said you would be making a new version, but I haven't seen any new patches.

I can easily make a new version. But licensing issues on a wide range of 
deployed systems is something I prefer not to deal with.

In my opinion, hardware vendors should not impose licensing restrictions 
that are much more restrictive than forbidding the use of their products 
for building or trafficking weapons or conducting illegal practices 
(which is of course is rather generic as in general it depends on local 
and sometimes also international jurisdiction).

The rest of the licensing should probably happen in software. And this 
opens the door to another opportunity: as SELinux introduced TE 
(possibly a trademark), the policy should probably introduce a maximum 
software-licensing acceptable level (e.g. GPLv1, GPLv2, GPLv3 and so on).

As far as I know, at the moment, on most or all distributions it is not 
possible for the user to impose a restriction such as: "I do not want to 
expose my machine to any other licence than GPLv3", for example, by 
easily configuring a simple centralized system-wide configuration file 
that cannot be modified by others.

Kind regards,

Guido