Re: silc license change before v1.0 ?

[Juraj B. <ju...@be...>]

Hello,

> > If they use Pekka's and other's code, they can just contribute. Anyways, I feel
> > having a proper independent (even commercial) implementation of the protocol _NOT_
> > based on the Silc Toolkit.
> 
> We want to ensure quality though don't we? If people don't feel they've got the neccesary
> skills in security and programming to produce a quality piece of software, it'll only
> damage silc's reputation if they make an inferior, insecure program. And there's nothing
> stopping them from contributing their modifications.

Yes, but the GPL way, you ensure peer review and not allowing insecure
implementations, that are based on reference implementation and then
being closed.

There are always two views, nothing is black and white. 

By allowing proprietary code based on the silc toolkit, you can end up
in a situation, where someone makes a bug, invisible to others and they
feel secure by the reputation of silc toolkit. 

Especially -- GPL is nice in disallowing security by obscurity.

> > In our courts, neither MIT license or any other Free Software license won't hold up.
> 
> I think that's wrong. The copyright holder is allowed to grant/reserve permissions to do
> anything with his product, which is what these "simpler" licenses do.

So do I (think that's wrong). But for example our law does not allow you
to disclaim warannty, or to produce software without being rewarded.
Both do apply to MIT and BSD license, too. Is this a problem? No,
because noone is going to sue me, because I didn't get reward. And
nobody is going to sue me because they have no warranty, because that
would mean they're using the software illegaly. 

But your argument for license ,,holding up in court'' is absolutely
irrelevant. You did not mention which court and why would somebody sue
the author. 

You didn't state the problem -- WHAT are you going to solve?

> > Still, you make an assumption about ,,holding up''. For this to happen, there must be
> > someone to actually try it there :). The question is -- why?
> >
> 
> Just refering to what kind of people wrote the licenses. :)

The same applies to all the other licenses in different countries. You
can not be so anglo-americano-scandinavio-centric :-)).

...and in China, they would probably kill you after that ,,appereance in
court'', because you use cryptographic software.

> Yes, you should. *Should*. Not *must*, just *should*. With GPL, it's *must*. :)

again wrong. You don't have to return it. Only when you distribute
something, you *must*. And if you distribute something, distribute it
with the rights, that came. Simple.

> But we see how BSD and BSDish licensed projects (Apache, FreeBSD, etc) tends to be of high
> quality with a high number of contributions. The copylefting of wine (the *nix windows
> emulator) actually reduced the number of contributors to the project. So I don't see why
> it's bad.

This is again wrong. The number of contributors of wine is the same. I don't
know from where you get this information. But that's the issue for
private talk, not for this list (/msg juraj).

The quality of the project does not depend on the license, but on the
code. GCC is of high quality, even under commercial unixes, you often
install gcc to compile your stuff. Absolutely irrelevant argument IMO.

> And I will contribute any changes I make too, if I don't have to make my own
> implementation in order to make a commercial client.

you don't, use the silc toolkit. Commercial client does not mean it has
to be proprietary. You are mixing the terms :).

> Many world catastrophes could've been avoided if people realised the problems in time:)
> Seriously though. I can see obvious problems with the project being GPL, as mentioned in
> my previous post.

I didn't see any problem you are trying to address, you just wrote, that
you feel GPL is bad, BSD is better backing with arguments such as GPL
won't hold up in court (which also applies to other licenses, as I
said).

You did not state your problem.

> > Not allowing proprietary modifications of the libraries? What's the problem?
> > No ,,embrace and extend'' practices and if someone makes compliant
> > implementation, it is good for the project. If not, it will simply not be ,,silc''.
> It can be compliant and still have more holes than Titanic. For obvious reasons, it's sort
> of hard to state "must not have security holes" in the specs.

yes. You missed the point. Scenarios:

it's gpled

 - there's a hole -- someone finds it and fixes it
 - you gain the peer review

it's bsd-licensed

 - there's a hole in proprietary implementation
 - it's possibly not caused by the original code
     - people assume, that the silc is buggy, since it's the same code
       base
     - no peer review

In first one, you have the peer review. 







 J.