On 05/13/2014 01:07 PM, mlmikael wrote:
...
> Eric,
>
> On 2014-05-13 18:17, Eric Voskuil wrote:
>> I agree. There is little if any commercial (or other) value to be
>> gained in serving up or distributing Bitcoin software without full
>> source disclosure.
>
> If it's ordinary wallet software yes.

Not sure what differentiation you intend by ordinary. Any wallet I use
will be open source.

> Though someone might want to make a special integration of LibBitcoin
> with his proprietary embedded solution or whatever, why force release of
> those updates,

Show of hands, who is going to trust a "proprietary embedded solution"
with their money and/or financial privacy?

> what if it would be so special that he'd want to keep his
> patch, for instance.

He of course has the option to develop his own bitcoin stack. To use
that built by others he's obligated to contribute, just as those others
have done.

> There, the AGPL quickly stops making sense and makes a niché library out
> of an AGPL library in comparison - what about LGPL?

See Amir's comment on the libbitcoin lesser clause. This allows one to
link the library into a non AGPL licensed project but not to modify the
library without publication. In the context above we are talking about
"updates" (to the library).

>> Really we have the opposite problem. We need to make it easier for the
>> user to prove that the software he/she is running is intended.
>> Deterministic build is hard. And of course even with source, ensuring
>> correctness is also very hard (as highlighted by the recent trail of
>> SSL/TLS bugs/backdoors). Them there's the hardware...
>>
>> http://en.m.wikipedia.org/wiki/Tailored_Access_Operations
>>
>> e
>
> Yes, the biggest challenge is to prove that the software is running as
> intended.

Which is of course impossible if the version being run is closed.

> This is why the source is openly available at GitHub.

GitHub is not a license, this provides no assurance whatsoever. A closed
version of the library is what the licensing intends to prevent.

...

e