[Mageia-dev] Gstreamer pfl codecs/plugins

Thu Mar 24 15:28:48 CET 2011

On Thu, Mar 24, 2011 at 14:55, Frank Griffin <ftg at roadrunner.com> wrote:
+> On 03/24/2011 09:45 AM, Romain d'Alverny wrote:
+>>
+>> http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses
+>>
+>> "The tainted section accepts software under a license that is might be
+>> free or open source and which cannot be redistributed publicly in
+>> certain areas in the world, or due to patents issues."
+>>
+>> and
+>>
+>> http://mageia.org/wiki/doku.php?id=mirrors_policy#tainted
+>>
+>> "stuff we think we can redistribute, but that may have some patent
+>> issues or other restrictions in other countries"
+>>
+>> look like consistent with each other, althought the "what belongs / is
+>> allowed here must still be discussed" indeed looks like it's not
+>> frozen yet.
+>
+> The reason I ask is that, in perusing the PLF package descriptions which
+> include the reason the package is in PLF, the criteria seems to be "Mandriva
+> was afraid to include this in main/contrib for <fill in your own reason from
+> a large list>" .
+
+So in the MDV context, that was valid for anything, true.
+
+>  The Mageia policies try to enumerate specific reasons why
+> things will be put in tainted, but don't explcitly say that there's anything
+> we *wouldn't* put in tainted.  So it's hard to know whether tainted == PLF
+> or not.
+
+Well I believe you should see this first as a concentric thing: Mageia
+is made of core, nonfree and tainted.
+ * free software (OSI/FSF) goes in core;
+ * that for which we don't have source but can redistribute go in
+nonfree; checked on a case-by-case basis;
+ * all the rest goes into tainted on a case-by-case study again;
+things that likely either:
+   - have no free license but under really significant patent-threat;
+
+Indeed, it should be distinctively made clear whether:
+ * tainted keeps a focus on free software that is under risk,
+ * or if it has a "all the rest that doesn't qualify for core or nonfree"
+
+I'd favour the latter as a default rule, keeping the case-by-case
+study for inclusion and leaving real life situations help us sort this
+out - it's really not easy to draw a general rule out of only a few
+practical cases.
+
+Anyway, two definitions is bad, so we should move it in a single place.
+
+Romain
+