All of lore.kernel.org
 help / color / mirror / Atom feed
From: guido@trentalancia.com (Guido Trentalancia)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] state of core/contrib split
Date: Fri, 07 Sep 2012 14:51:06 +0200	[thread overview]
Message-ID: <5049EDBA.30502@trentalancia.com> (raw)
In-Reply-To: <5049E761.7020002@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

  reply	other threads:[~2012-09-07 12:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-06 17:01 [refpolicy] state of core/contrib split Christopher J. PeBenito
2012-09-06 17:15 ` Guido Trentalancia
2012-09-06 18:03   ` Dominick Grift
2012-09-06 18:45     ` Miroslav Grepl
2012-09-06 18:55       ` Daniel J Walsh
2012-09-06 19:21         ` Dominick Grift
2012-09-07 11:00   ` Guido Trentalancia
2012-09-07 11:22     ` Daniel J Walsh
2012-09-07 12:24     ` Christopher J. PeBenito
2012-09-07 12:51       ` Guido Trentalancia [this message]
2012-09-07 13:25         ` Guido Trentalancia
2012-09-07 12:48   ` Russell Coker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5049EDBA.30502@trentalancia.com \
    --to=guido@trentalancia.com \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.