Hi,
u:
> intrigeri:
>> * for everything else, it says "Tails will always be free to use,
>> remix, adapt and distribute"; I think this is correct for what's in
>> our Git tree; but I'm not sure it applies to everything we include
>> in the ISO (e.g. virtualbox requires a non-free compiler, and stuff
>> installed by libdvd-pkg is not exactly FOSS); so in this sentence,
>> "Tails" can't possibly mean "everything that's in the Tails ISO
>> image we ship to users, except firmware". If I'm the only free
>> software zealot who find this confusing and a bit over-promising,
>> feel free to ignore me; but if this is a problem for you too, then
>> perhaps a minor rephrasing would be in order.
> Can you make a proposal please?
Sure. I've looked closer at what we ship from "contrib", in order to
ensure what I wrote reflected reality. I've tried to avoid restricting
our future options more than necessary (it would be a shame if we
ended up bypassing our own Social Contract in a year), while still
making it clear that we don't run closed-source software on the main
CPU. I had to move stuff around a bit, in order to document the
exceptions next to the general rule they're breaking. Here's what
I could come up with:
Equal access to information includes the free availability of our
code and documentation as well as the transparency of our decision
making processes.
All the components of Tails that we create ourselves are, and will
be, licensed them in a manner consistent with the Debian Free
Software Guidelines.
Tails will always be free to use, remix, adapt and distribute.
As the only exceptions to this rule, Tails includes:
* a minor part of non-free firmware in order to work on as much
hardware as possible;
* a few pieces of software whose source code is public but not
compatible with the Debian Free Software Guidelines; they are
needed to support important use cases.
This forbids us from ever including software whose source code is not
publicly available (e.g. a custom kernel built with a grsec patch that
would be available via private channels only, or binary-only drivers
for some GPU found on ARM Chromebooks); I think that's desirable.
This allows us to ship at least the packages from Debian "contrib" we
currently want (and probably most, but not all, packages from
contrib).
What do you think?
I also wondered if we should add a bit about cryptographic signatures
(e.g. when we'll do SecureBoot), but in the end I think it's not worth
the added complexity: I understand this document as a set of
guidelines, not as a legally binding document that would need to be
100% precise.
>>> I agree, this might not be the right place to say this.
>>> And even, that this sentence might not eben have to be in the contract.
>>> For now, i left it in there, until further discussion.
>>
>> An option could be to retitle this section to make this sentence fit
>> better in its scope, but that's a nitpick: let's keep it this way
>> for now :)
> Can you propose a better title then please?
Sure: how about something like "We give users the means to decide how
much they can rely on Tails"?
Cheers!
--
intrigeri
