Michael scherer a écrit :
On Sat, Dec 11, 2010 at 10:52:16AM +0100, Romain d'Alverny wrote:
On Sat, Dec 11, 2010 at 10:42, Michael scherer<m...@zarb.org> wrote:
On Fri, Dec 10, 2010 at 02:26:32PM -0500, andre999 wrote:
Romain d'Alverny a écrit :
- for packaging/shipping the distribution
Evidently easier to package. (One less consideration.)
As well, the problem doesn't exist in France, so Mageia itself won't
be a target.
This is a over simplification.
PLF is not only for patented softwares, but also for softwares that
have others issues ( DMCA, copyright claim, etc ).
So from a packaging point of view, we would still
have a separate repository, so the consideration would
likely still exist.
Indeed. But it then shows that it really makes sense to separate
issues per packaging media (so that end-users may decide on a
case-by-case basis), provided each issue is not valid worldwide,
neither uniformely.
PLF has a policy ( enforced by a rpmlint module and a check at upload, iirc )
of explaining why a package is in plf, and let user decide.
I think that is is quite important to know why a package is in such
repositories,
and later, once we have a better view of what are the exact requirements of
mirrors,
and if this is worth, we can find a more granular system ( ie, filtering for
just
2 mirrors when we will already have many others do not seem like a wise idea ).
And so basically, we have 2 groups :
Users and mirrors.
We push the responsability to users to decide what they want to install.
And for mirrors, we provide them with a simple system to decide. People
who do not care do not care. People who care would likely not spend
days checking every packages.
Sounds reasonable.
As for the mirrors, I would say the best thing to do is use PLF for
constrained packages, with their accompanying explanations.
But I would be very conservative about putting patent-constrained
software in such a repository.
Why ? Firstly, the risk has been shown to be largely hypothetical.
It is the companies that make a profit by selling patent-constrained
software that are pursued.
Besides the potential of monetory benefit from this practice, I think
that there is another factor involved. The companies want these patents
to be used, in order to collect royalties. They know that non-profit
distributions will not lead to royalties. But at the same time, the
fact that their patents are used by such distributions increases the
prevalence of the usage, thus tends to limit the development of
alternate technologies. The last thing they want is a viable free
alternative to become widely available, as then profit-making royalty
payers will have a less expensive alternative.
So as contradictory as it may seem, it is in the interest of patent
holders to avoid discouraging open source software from using their
patents for free.
For this reason, I would favour waiting until we (or our mirrors) are
actually approached regarding a particular patent before considering
removing a package from regular repositories for patent reasons.
Putting everything under a "tainted" repository will just push the
problem one step aside. Putting issues separately helps having a clear
policy, per type of issue (because the problem is different).
Either we have 1 repository, or we have more.
I think that one PLF repository for constrained packages, with
explanations of why it is there, could be a reasonable compromise.
(Most but not all PLF packages carry an explanation.)
Some things in PLF should definitely be excluded from Mageia, such as
copyrighted material without permission to distribute.
1 per global type of issue do not seem useful. For example, patents
are per country ( or group of country ), despites some efforts to global
harmonisation. The same apply to local laws ( DMCA, etc ). So saying
"everything patents related go there" do not help much, neither mirrors or
users.
As I explained above, I think we should not separate patent-constrained
software until we are approached by the patenting party in question.
This will help minimize (and maybe eliminate) the need for a set of
constrained repositories.
And have the side effect of simplifying our process, by avoiding dealing
with the ambiguity of deciding what should be treated as
patent-constrainted software.
...
- André
