Re: silc license change before v1.0 ?

[Anders N. B. <de...@de...>]

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

But which would you consider more (likely to be) secure, an
implementation based on the reference implementation, or something
written from scratch, with development time in mind?

> 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.

True. But we can add a clause to the license saying closed source
implementations may not directly advertise using the silc toolkit if
modified.

> 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.

The not holding up in court argument was for certain parts of LGPL
(and not GPL as you later in this post state), I didn't even try to make
it sound like anything else.

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

Yes I did. GPL will limit adaption. Why would pekka and for that matter,
the rest of the group bother to continue development if no one wants
to use it? Remember, not everyone wants to develope their client under
the terms of the GPL.

>> 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 :-)).

Not that "kind". :-)

> 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.

Distribution was assumed, but sorry, I'll explicitly refer to that next
time. :)

> 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).

Actually, we might both be right here, but I don't count the x11 split as
the official wine project. All the contributors are still contributing to
one of the wines, just not the official wine.

> 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.

But GCC isn't a reference implementation.

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

Yes I am.. :-(

But assume I said propetiary client for a second, wouldn't that make my
argument more valid?

> 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.

Doesn't apply to other licenses, at least not for the same reason. LGPL
assumes among other things that you can hold a copyright on devices. BSD
and MIT certainly doesn't.

But as you said, noninteresting discussion. See above for closing
statements. :-)

> In first one, you have the peer review.

See above for possible solution.

- Anders Nor Berle