Subject Re: [Firebird-Architect] Crypto Code
Author Jim Starkey
Alexander Klenin wrote:

>Perl comes standard with any flavour of Unix you can encounter
>nowdays, and ActiveState port is very straitforward to install on any
>Windows version past Win98. So it is not a big issue, in my opinion.
The problem isn't with Perl. The problem is with an environment that
requires a static configuration before something is built. I like dirt
simple build procedures -- a make or maybe a command file of makes in
different directories. I'm looking for crypto code to simplify my life,
not complicate it.

>>Young put his work out there so any
>>developer can use and build upon it, which is something that I admire.
>>Firebird has the same philosophy.
>Not true. By excluding developers who prefer to license their work
>under GPL, he did exclude whole lot of developers, just different ones
>than those who are excluded by GPL.
I wish to exclude developers who wish to exclude developers. Is that
circular? It is, however, simple.

>>The GPL is trying to build an
>>alternative world without commercial software, and idea that I do not
>>adhere to. For the record, Netfrastructure code that I've donated to
>>Firebird has a proviso that it can't be re-issued under other
>Here is the first of possible problems: what if you want to modify SSLeay?
>If modifications are minor, you simply change the files and leave the
>license as-is, since it explicitly allows modifications. But as the
>number of modifications grow, you might come to a point when there is
>more of your code than original code in the module. So what do you do
>then? According to your principles, the module should be put under
>your preferred license, but that would be a violation of the original
There is no question here at all. Any and every line of code is covered
by a license. When I make source available to a commercial product, the
rule applies. Use one line of code and you owe me a full royalty.

What I said was the modules that contain any code from SSLeay will
retain his license.

>Now imagine the big project with lots of components each requiring its
>own license, and forbidding to change it. That is what once happened
>to BSD.
It's a problem, but not a hard one for sane licenses. You just can't
combine two modules with difference licenses. If you have GPL code that
dictates what over code can be linked with it, you're screwed.

This isn't new. FSF has declared (have they repented?) that it is
illegal to link GNU code with Mozilla derivatives licenses like the
IDPL. Personally, I think telling people what they can and can't do
with code I didn't write is pretty outrageous, but I understand this is
a minority opinion.

>And finally, just to stay on-topic: does not no-relicensing provision
>contradict the terms of IDPL itself? What do other developers think of
>incorporating such code into the project?
It has no effect on the IDPL license whatsoever.


Jim Starkey
Netfrastructure, Inc.
978 526-1376