Licenses...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
65 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Licenses...

Tyler MacDonald
Eric,
        OpenSSL has become an almost universal component in servers and
operating systems. Unfortunately, GPL types don't like linking against a
product that has an advertising clause (go figure).

        I'd like to see this war end. I don't think removing the advertising
clause from SSLeay and OpenSSL would be admitting defeat, or even really
doing anything bad. Everybody *knows* what openssl is nowadays, it doesn't
need to be advertised anymore.

        Things are going in two directions right now with GPL projects; some
products are modifying their GPL to add a special exemption to allow linking
against OpenSSL. Other products are moving to GnuTLS instead. Other projects
get left in the middle, breaking the "law".

        And it's not always even that simple: for example, the freeradius
project's postgresql plugin links against the postgresql client library
(naturally). Postgresql may or may not link against OpenSSL. If it does,
then the freeradius-postgresql plugin is breaking the GPL's rules, but how
the postgresql client library was compiled isn't neccessarily under
freeradius's control.

        I think that these programmers could be more happy and productive
and get back to moving our planet forward if they didn't have to spend so
much time thinking about licensing issues, coding around the problem, etc.
Can you please, please consider removing this requirement from the next
version of SSLeay's license, so that OpenSSL can follow suit, so that we can
go back to solving the *real* problems instead of all this legal mumbo
jumbo?

        Thanks,
                Tyler

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Licenses...

Ted Mittelstaedt

Hi Eric,

  I hope you leave the license alone.

  I have seen increasing examples of GPL code used in embedded products,
and
for all the philosophizing the GPL people do, they roll over when it
comes to suing
people.

  Take for example the ActionTec DSL modem, this is sold by ActionTec and
runs embedded Linux.  It is the standard modem Qwest sends out for DSL
there
are probably 100,000 or more of these in service in the Western United
States.
Yet you cannot obtain the modified GNU code from the ActionTec website
as required by GPL.  Oh sure, you can obtain stuff like iptables from
ActionTec,
or thttpd, but not the modified bootloader code or the black box
interface itself,
so it makes it impossible to create your own firmware, or modify theirs,
which
defeats the purpose of the GPL.

  I have not read a peep in the trade rags about FSF or anyone in the GPL
camp filing a lawsuit against ActionTec against GPL violations.

  All the Linux people want to do is to simply take OpenSSL and apply
a GPL license to it, and get rid of your license.  That's what all this
is about.
They are happy to see the GPL used everywhere but when it comes to
putting
their money where their philosophy is, they run for the nearest exit.

  When I see the GPL filing license violation lawsuits and actually
standing up
for the license they are advocating, then I would say to do as Tyler says
and
modify your license.  But until then, let them write their own openssl if
they
don't like your license.  They can always use a different license than
GPL.

  Further, what Tyler is saying is incorrect anyway.  A GPL program can
be distributed that links against openSSL.  All they have to do is
compile it
to dynamically link at runtime.  It won't run if the dynamic openssl
libraries aren't present
on the system, of course, but it is only when you distribute a GPL
program
and openssl as a unitized whole, (whether statically compiled or
dynamically
linked) does the GPL license on redistribution come into play.  And, I
might
point out that the GPL itself requires a copy of the GPL to be
distributed with
the program, so for them to claim your license has an advertising clause
is
extremely hypocritical.

Ted

>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]]On Behalf Of Tyler MacDonald
>Sent: Sunday, April 09, 2006 11:04 AM
>To: [hidden email]
>Cc: [hidden email]
>Subject: Licenses...
>
>
>Eric,
> OpenSSL has become an almost universal component in servers and
>operating systems. Unfortunately, GPL types don't like linking against a
>product that has an advertising clause (go figure).
>
> I'd like to see this war end. I don't think removing the
>advertising
>clause from SSLeay and OpenSSL would be admitting defeat, or even really
>doing anything bad. Everybody *knows* what openssl is nowadays,
>it doesn't
>need to be advertised anymore.
>
> Things are going in two directions right now with GPL
>projects; some
>products are modifying their GPL to add a special exemption to
>allow linking
>against OpenSSL. Other products are moving to GnuTLS instead.
>Other projects
>get left in the middle, breaking the "law".
>
> And it's not always even that simple: for example, the freeradius
>project's postgresql plugin links against the postgresql client library
>(naturally). Postgresql may or may not link against OpenSSL. If it does,
>then the freeradius-postgresql plugin is breaking the GPL's
>rules, but how
>the postgresql client library was compiled isn't neccessarily under
>freeradius's control.
>
> I think that these programmers could be more happy and productive
>and get back to moving our planet forward if they didn't have
>to spend so
>much time thinking about licensing issues, coding around the
>problem, etc.
>Can you please, please consider removing this requirement from the next
>version of SSLeay's license, so that OpenSSL can follow suit,
>so that we can
>go back to solving the *real* problems instead of all this legal mumbo
>jumbo?
>
> Thanks,
> Tyler
>
>______________________________________________________________________
>OpenSSL Project                                 http://www.openssl.org
>User Support Mailing List                    [hidden email]
>Automated List Manager                           [hidden email]
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.385 / Virus Database: 268.4.0/305 - Release Date: 4/8/2006
>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

CA embeded in Java client

Severine-3
In reply to this post by Tyler MacDonald
Hi all and thanks in advance for your answers.
Here is my problem :

I have a c++ ssl webserver and I want to connect to it using a java client.
I have manually (with keytool) imported my CA and everything works fine
like that.
But when my java client is installed, I'd like that no manual things are
done to be able to connect succesfuly to my server.

So, is there a way to embed the CA in the java code ? I mean, I'm
looknig for the equavalent of the following CC++ code in Java.

Here os the C++ code :

******* start of code*****************
X509 *cert =NULL;
    X509_STORE *store = NULL;
   
    if (!(store = SSL_CTX_get_cert_store (ptrSocket->ctxSSLContext)))
    {
        printf ("Can't make X509 store");
    }
   
    const unsigned char *cert_data = &szRootCa_certificate[0];

    cert = d2i_X509 (NULL, &cert_data, sizeof (szRootCa_certificate));
    X509_STORE_add_cert (store,cert);
    X509_free (cert);
******* end of code**************


Thanks for your answers
Severine
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: CA embeded in Java client

Ambarish Mitra

Yes, the JVM has a keystore for all the trusted certificates, the path is
jre/lib/security/cacerts.

This file has all the trusted root CA certs. Please import the CA cert in
here, and it should work.


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Severine
Sent: Monday, April 10, 2006 2:55 PM
To: [hidden email]
Subject: CA embeded in Java client


Hi all and thanks in advance for your answers.
Here is my problem :

I have a c++ ssl webserver and I want to connect to it using a java client.
I have manually (with keytool) imported my CA and everything works fine
like that.
But when my java client is installed, I'd like that no manual things are
done to be able to connect succesfuly to my server.

So, is there a way to embed the CA in the java code ? I mean, I'm
looknig for the equavalent of the following CC++ code in Java.

Here os the C++ code :

******* start of code*****************
X509 *cert =NULL;
    X509_STORE *store = NULL;

    if (!(store = SSL_CTX_get_cert_store (ptrSocket->ctxSSLContext)))
    {
        printf ("Can't make X509 store");
    }

    const unsigned char *cert_data = &szRootCa_certificate[0];

    cert = d2i_X509 (NULL, &cert_data, sizeof (szRootCa_certificate));
    X509_STORE_add_cert (store,cert);
    X509_free (cert);
******* end of code**************


Thanks for your answers
Severine
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CA embeded in Java client

Severine-3
Thx for you answer.
Yeah, That is was I did, but what I'm looking for is to do it in my java
class. I'm looking for java code to do that.
And I eventually would like to hard code the content of the CA in my
code. and import the string in the keystore using java code.




Ambarish Mitra a écrit :

> Yes, the JVM has a keystore for all the trusted certificates, the path is
> jre/lib/security/cacerts.
>
> This file has all the trusted root CA certs. Please import the CA cert in
> here, and it should work.
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Severine
> Sent: Monday, April 10, 2006 2:55 PM
> To: [hidden email]
> Subject: CA embeded in Java client
>
>
> Hi all and thanks in advance for your answers.
> Here is my problem :
>
> I have a c++ ssl webserver and I want to connect to it using a java client.
> I have manually (with keytool) imported my CA and everything works fine
> like that.
> But when my java client is installed, I'd like that no manual things are
> done to be able to connect succesfuly to my server.
>
> So, is there a way to embed the CA in the java code ? I mean, I'm
> looknig for the equavalent of the following CC++ code in Java.
>
> Here os the C++ code :
>
> ******* start of code*****************
> X509 *cert =NULL;
>     X509_STORE *store = NULL;
>
>     if (!(store = SSL_CTX_get_cert_store (ptrSocket->ctxSSLContext)))
>     {
>         printf ("Can't make X509 store");
>     }
>
>     const unsigned char *cert_data = &szRootCa_certificate[0];
>
>     cert = d2i_X509 (NULL, &cert_data, sizeof (szRootCa_certificate));
>     X509_STORE_add_cert (store,cert);
>     X509_free (cert);
> ******* end of code**************
>
>
> Thanks for your answers
> Severine
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>  
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Licenses...

Richard Levitte - VMS Whacker
In reply to this post by Tyler MacDonald
In message <[hidden email]> on Sun, 09 Apr 2006 11:04:12 -0700, Tyler MacDonald <[hidden email]> said:

tyler> I think that these programmers could be more happy and productive
tyler> and get back to moving our planet forward if they didn't have
tyler> to spend so much time thinking about licensing issues, coding
tyler> around the problem, etc.  Can you please, please consider
tyler> removing this requirement from the next version of SSLeay's
tyler> license, so that OpenSSL can follow suit, so that we can go
tyler> back to solving the *real* problems instead of all this legal
tyler> mumbo jumbo?

+1!

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CA embeded in Java client

Sukanta Kumar Panigrahi
In reply to this post by Severine-3
Yeah you can do that using CertificateFactory class which can generate
the certificate on the fly from an InputStream. And then you can add the
Certificate to the Keystore using setCertificateEntry(...) method. And
lastly use the same keystore object with TrustManagerFactory to get the
TrustManager instances.

For this you just need to have a way to read your CA using an InputStream...

Hope this helps.

Severine wrote:

> Thx for you answer.
> Yeah, That is was I did, but what I'm looking for is to do it in my
> java class. I'm looking for java code to do that.
> And I eventually would like to hard code the content of the CA in my
> code. and import the string in the keystore using java code.
>
>
>
>
> Ambarish Mitra a écrit :
>
>> Yes, the JVM has a keystore for all the trusted certificates, the
>> path is
>> jre/lib/security/cacerts.
>>
>> This file has all the trusted root CA certs. Please import the CA
>> cert in
>> here, and it should work.
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]]On Behalf Of Severine
>> Sent: Monday, April 10, 2006 2:55 PM
>> To: [hidden email]
>> Subject: CA embeded in Java client
>>
>>
>> Hi all and thanks in advance for your answers.
>> Here is my problem :
>>
>> I have a c++ ssl webserver and I want to connect to it using a java
>> client.
>> I have manually (with keytool) imported my CA and everything works fine
>> like that.
>> But when my java client is installed, I'd like that no manual things are
>> done to be able to connect succesfuly to my server.
>>
>> So, is there a way to embed the CA in the java code ? I mean, I'm
>> looknig for the equavalent of the following CC++ code in Java.
>>
>> Here os the C++ code :
>>
>> ******* start of code*****************
>> X509 *cert =NULL;
>>     X509_STORE *store = NULL;
>>
>>     if (!(store = SSL_CTX_get_cert_store (ptrSocket->ctxSSLContext)))
>>     {
>>         printf ("Can't make X509 store");
>>     }
>>
>>     const unsigned char *cert_data = &szRootCa_certificate[0];
>>
>>     cert = d2i_X509 (NULL, &cert_data, sizeof (szRootCa_certificate));
>>     X509_STORE_add_cert (store,cert);
>>     X509_free (cert);
>> ******* end of code**************
>>
>>
>> Thanks for your answers
>> Severine
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    [hidden email]
>> Automated List Manager                           [hidden email]
>>
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    [hidden email]
>> Automated List Manager                           [hidden email]
>>
>>  
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: CA embeded in Java client

Severine-3
Great, that helps. In fact, I have an external CA file that I use in
both my C++ server and my java client.
So I'll just need the setCertificateEntry.  and the following stuff.
Thanks again

Sukanta Kumar Panigrahi a écrit :

> Yeah you can do that using CertificateFactory class which can generate
> the certificate on the fly from an InputStream. And then you can add
> the Certificate to the Keystore using setCertificateEntry(...) method.
> And lastly use the same keystore object with TrustManagerFactory to
> get the TrustManager instances.
>
> For this you just need to have a way to read your CA using an
> InputStream...
>
> Hope this helps.
>
> Severine wrote:
>
>> Thx for you answer.
>> Yeah, That is was I did, but what I'm looking for is to do it in my
>> java class. I'm looking for java code to do that.
>> And I eventually would like to hard code the content of the CA in my
>> code. and import the string in the keystore using java code.
>>
>>
>>
>>
>> Ambarish Mitra a écrit :
>>
>>> Yes, the JVM has a keystore for all the trusted certificates, the
>>> path is
>>> jre/lib/security/cacerts.
>>>
>>> This file has all the trusted root CA certs. Please import the CA
>>> cert in
>>> here, and it should work.
>>>
>>>
>>> -----Original Message-----
>>> From: [hidden email]
>>> [mailto:[hidden email]]On Behalf Of Severine
>>> Sent: Monday, April 10, 2006 2:55 PM
>>> To: [hidden email]
>>> Subject: CA embeded in Java client
>>>
>>>
>>> Hi all and thanks in advance for your answers.
>>> Here is my problem :
>>>
>>> I have a c++ ssl webserver and I want to connect to it using a java
>>> client.
>>> I have manually (with keytool) imported my CA and everything works fine
>>> like that.
>>> But when my java client is installed, I'd like that no manual things
>>> are
>>> done to be able to connect succesfuly to my server.
>>>
>>> So, is there a way to embed the CA in the java code ? I mean, I'm
>>> looknig for the equavalent of the following CC++ code in Java.
>>>
>>> Here os the C++ code :
>>>
>>> ******* start of code*****************
>>> X509 *cert =NULL;
>>>     X509_STORE *store = NULL;
>>>
>>>     if (!(store = SSL_CTX_get_cert_store (ptrSocket->ctxSSLContext)))
>>>     {
>>>         printf ("Can't make X509 store");
>>>     }
>>>
>>>     const unsigned char *cert_data = &szRootCa_certificate[0];
>>>
>>>     cert = d2i_X509 (NULL, &cert_data, sizeof (szRootCa_certificate));
>>>     X509_STORE_add_cert (store,cert);
>>>     X509_free (cert);
>>> ******* end of code**************
>>>
>>>
>>> Thanks for your answers
>>> Severine
>>> ______________________________________________________________________
>>> OpenSSL Project                                 http://www.openssl.org
>>> User Support Mailing List                    [hidden email]
>>> Automated List Manager                           [hidden email]
>>>
>>> ______________________________________________________________________
>>> OpenSSL Project                                 http://www.openssl.org
>>> User Support Mailing List                    [hidden email]
>>> Automated List Manager                           [hidden email]
>>>
>>>  
>>
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    [hidden email]
>> Automated List Manager                           [hidden email]
>>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Licenses...

JoelKatz
In reply to this post by Ted Mittelstaedt

> Take for example the ActionTec DSL modem, this is sold by ActionTec and
> runs embedded Linux.  It is the standard modem Qwest sends out for DSL
> there
> are probably 100,000 or more of these in service in the Western United
> States.
> Yet you cannot obtain the modified GNU code from the ActionTec website
> as required by GPL.  Oh sure, you can obtain stuff like iptables from
> ActionTec,
> or thttpd, but not the modified bootloader code or the black box
> interface itself,
> so it makes it impossible to create your own firmware, or modify theirs,
> which
> defeats the purpose of the GPL.

        I think you misstate the purpose of the GPL. It is pretty well understood
in the GPL camp that the GPL is not about any right to use hardware that you
purchased however you want but that it's about the right to use software.
Because their modified GPL'd software *is* available, others who use that
same software can benefit from their changes. That is the purpose of the
GPL.

        The GPL is not intended to force open hardware.

        The truth is, you can create your own firmware, just not for *their*
hardware. GPL does not infect hardware.

        DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Licenses...

Jeffrey Altman
In reply to this post by Tyler MacDonald
Tyler MacDonald wrote:

> And it's not always even that simple: for example, the freeradius
> project's postgresql plugin links against the postgresql client library
> (naturally). Postgresql may or may not link against OpenSSL. If it does,
> then the freeradius-postgresql plugin is breaking the GPL's rules, but how
> the postgresql client library was compiled isn't neccessarily under
> freeradius's control.

Maybe the problem is the GPL rules.

Jeffrey Altman


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Licenses...

Tyler MacDonald
Jeffrey Altman <[hidden email]> wrote:
> > And it's not always even that simple: for example, the freeradius
> > project's postgresql plugin links against the postgresql client library
> > (naturally). Postgresql may or may not link against OpenSSL. If it does,
> > then the freeradius-postgresql plugin is breaking the GPL's rules, but how
> > the postgresql client library was compiled isn't neccessarily under
> > freeradius's control.
> Maybe the problem is the GPL rules.

        I agree 100% and no software I'm developing is licensed under the
GPL. But there is a lot of useful software out there that helps a lot of
people that *is* developed under the GPL, and OpenSSL has become a universal
open source component that people use to make their applications more
secure.

        I'm not saying that the advertising clause is at fault, or the GPL
is at fault. Honestly, I think aspects of them both are at fault. However, I
think that removing this clause from the license of this one product,
OpenSSL, will increase the productivity of the development world in a lot
less time than it would take to change the license of every single GPL app
out there.

        And as a result, OpenSSL will be used by even more pieces of
software and OpenSSL will benefit from the added attention from hard-working
open source developers. I see it as a win-win situation.

        Cheers,
                Tyler


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Licenses...

JoelKatz
In reply to this post by Jeffrey Altman

> Tyler MacDonald wrote:

> > And it's not always even that simple: for example, the freeradius
> > project's postgresql plugin links against the postgresql client library
> > (naturally). Postgresql may or may not link against OpenSSL. If it does,
> > then the freeradius-postgresql plugin is breaking the GPL's
> > rules, but how
> > the postgresql client library was compiled isn't neccessarily under
> > freeradius's control.

> Maybe the problem is the GPL rules.

        In this case, at least, it's just the interpretation of them. For example,
a piece of software cannot break GPL rules. Even generously assuming the
phrase "the freeradius-postgresql plugin is breaking the GPL's rules" means
that the person who distributed the plugin is violating the rules, it still
makes no sense. The freeradius-postgresql plugin is not a derivative work of
the OpenSSL library just because postgresql is capable of linking to
OpenSSL.

        Part of the problem is that a number of GPL advocates don't understand the
license they advocate for. Particularly, they don't understand that:

        1) The GPL only 'infects' derivative works.

        2) What is or is not a derivative work is defined by copyright law, not the
GPL itself.

        3) The GPL only applies to someone who exercises a right they could not get
any way other than by the GPL giving it to them.

        4) There are other ways you can get rights to a work, particularly fair
use, first sale, scenes a faire, and by taking only non-protectably
functional content.

        5) There is no right under copyright law to restrict the distribution of
lawfully created derivative works to those with the right to use the
original work.

        DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Licenses...

Richard Levitte - VMS Whacker
In reply to this post by Jeffrey Altman
Hi Jeffrey, long time!

In message <[hidden email]> on Mon, 10 Apr 2006 22:28:22 -0400, Jeffrey Altman <[hidden email]> said:

jaltman> Tyler MacDonald wrote:
jaltman>
jaltman> > And it's not always even that simple: for example, the
jaltman> > freeradius project's postgresql plugin links against the
jaltman> > postgresql client library (naturally). Postgresql may or
jaltman> > may not link against OpenSSL. If it does, then the
jaltman> > freeradius-postgresql plugin is breaking the GPL's rules,
jaltman> > but how the postgresql client library was compiled isn't
jaltman> > neccessarily under freeradius's control.
jaltman>
jaltman> Maybe the problem is the GPL rules.

I don't agree with that assesment.  The GPL rules are there for a
reason, and within the GNU world, they are well balanced.  The same
goes for the BSD type of license, they're well balanced within the BSD
camp.  No license is really wrong per se.  However, when the worlds
are mixed, we have a conflict, and the real issue seems to be
two-fold:

  1. do we want to resolve the conflict?
  2. how do we resolve the conflict?

I can only speak from my own perspective when I answer those.  The
first is easy for me to answer, it's a resounding YES.  The second
takes a little bit of thinking, and is deeply connected with what I
want for OpenSSL.  I've come into this project with the vision that
OpenSSL should be as available to anyone as possible without
compromising its freedom to exist.  If someone wants to embed it into
their software, regardless of who that is, my vision is unthreatened.
However, if someone can't use OpenSSL because of some idiotic thing as
a license clash, I'm getting upset because it doesn't match my vision.
As has already been said, OpenSSL is very well known and stands on its
own two feet (so to speak) and its own merits with no real need for
every user to tell everyone that they use it[1].  From that point of
view, I see zero harm in removing a clause that seems to generate more
conflict and confusion[2] than good from our license.

Cheers,
Richard

-------
[1] You know, I'm I'm sure some will give us the credit without having
    to be asked, just because they like OpenSSL.  And for those who
    don't want to, check if I care.  I wouldn't be surprised if a lot
    use OpenSSL in their software without saying a word about it.
[2] We regularly get questions about what the advertisement clause
    means.  It seems to be the single question that gets asked about
    the license, really.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Licenses...

Ted Mittelstaedt
In reply to this post by JoelKatz


>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]]On Behalf Of David Schwartz
>Sent: Monday, April 10, 2006 4:41 PM
>To: [hidden email]
>Subject: RE: Licenses...
>
>
>
>> Take for example the ActionTec DSL modem, this is sold by
>ActionTec and
>> runs embedded Linux.  It is the standard modem Qwest sends out for DSL
>> there
>> are probably 100,000 or more of these in service in the Western United
>> States.
>> Yet you cannot obtain the modified GNU code from the ActionTec website
>> as required by GPL.  Oh sure, you can obtain stuff like iptables from
>> ActionTec,
>> or thttpd, but not the modified bootloader code or the black box
>> interface itself,
>> so it makes it impossible to create your own firmware, or
>modify theirs,
>> which
>> defeats the purpose of the GPL.
>
> I think you misstate the purpose of the GPL. It is
>pretty well understood
>in the GPL camp that the GPL is not about any right to use
>hardware that you
>purchased however you want but that it's about the right to use
>software.
>Because their modified GPL'd software *is* available, others
>who use that
>same software can benefit from their changes. That is the purpose of the
>GPL.
>
> The GPL is not intended to force open hardware.
>
> The truth is, you can create your own firmware, just not
>for *their*
>hardware. GPL does not infect hardware.
>

That is silly, you can't create something like the ActionTec without
modding
the software your putting in it, to run on the hardware.  When Cisco AKA
Linksys
did the same thing (using embedded Linux) they published what they had
done
with it, and there's at least 3 groups now who have come out with their
own
firmware versions.

Operating system software doesen''t run in a vacuum - it interfaces to
the hardware.
If you don't publish specs on what registers do in your hardware then you
are
not really opening your source.  Nvidia does that and that is why nobody
can
write a driver for their stuff even though quote-open-source-endquote
drivers
exist for them.

According to the writings of the FSF the GPL is all about keeping
software
free - free to use, free to modify.  There is no talk of JUST the right
to "use"
the software, the FSF defines use as being able to modify it as well as
run
it, and what ActionTec is doing is in violation of this principle,
although they
obviously feel they are technically within the GPL.

Ted

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Licenses...

Ted Mittelstaedt
In reply to this post by Tyler MacDonald


>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]]On Behalf Of Tyler MacDonald
>Sent: Monday, April 10, 2006 7:43 PM
>To: [hidden email]
>Subject: Re: Licenses...
>
>
> And as a result, OpenSSL will be used by even more pieces of
>software and OpenSSL will benefit from the added attention from
>hard-working
>open source developers. I see it as a win-win situation.
>

This was the same argument used by the Linux people to get the University
of California, Berkeley to revoke it's "advert clause"

However, once that happened the GPL people simply grabbed what bits they
wanted and ran off.  Berkeley software hasn't seen any additional
attention or
benefit from the GPL people as a result of revoking this, and neither
will
OpenSSL.

Ted

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Licenses...

Wes Kussmaul
In reply to this post by JoelKatz
David Schwartz wrote:

>>Take for example the ActionTec DSL modem, this is sold by ActionTec and
>>runs embedded Linux... Yet you cannot obtain the modified GNU code from the ActionTec website
>>as required by GPL... or thttpd, but not the modified bootloader code or the black box
>>interface itself, so it makes it impossible to create your own firmware, or modify theirs,
>>which defeats the purpose of the GPL.
>>    
>>
> I think you misstate the purpose of the GPL. It is pretty well understood
>in the GPL camp that the GPL is not about any right to use hardware that you
>purchased however you want but that it's about the right to use software.
>Because their modified GPL'd software *is* available, others who use that
>same software can benefit from their changes. That is the purpose of the
>GPL.
>
> The GPL is not intended to force open hardware.
>
> The truth is, you can create your own firmware, just not for *their*
>hardware. GPL does not infect hardware.
>  
>
Are you suggesting that if you embed software in a hardware product,
it's no longer software?

The GPL most certainly applies to embedded versions of software products
which it licenses.

If that were not true then I would be able to put any GPLed software
onto a USB thumb drive and call it exempt.

--
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


My uncle likes to say that the world’s biggest troubles started when the serpent said, “Try this fruit, and by the way if a bunch of people collectively calling themselves Arthur Andersen signs something it’s the same as if a person named Arthur Andersen signed it.” I don’t get the serpent and fruit part. Must be some Swiss mythology thing. He can be a bit obscure.

                         P.K. Iggy
                         _How I Like Fixed The Internet_
                           (Tales from the Great Infodepression of 2009
                           and the prosperity that followed)



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Licenses...

Chris Fowler-2
On Tue, 2006-04-11 at 08:07 -0400, Wes Kussmaul wrote:
> Are you suggesting that if you embed software in a hardware product,
> it's no longer software?
>
> The GPL most certainly applies to embedded versions of software
> products
> which it licenses.
>
> If that were not true then I would be able to put any GPLed software
> onto a USB thumb drive and call it exempt.

I don't think so.  What he is stating is that someone can provided the
GPLed software that they use on their embedded system and then it may be
possible or not possible for you to run your own modified versions on
their hardware.  

I believe it is okay to create a "disti" that runs on a device with
proprietary code and license only that "disti".  You can download the
GPL software from the project but you would not be allowed to download
the proprietary code.  This would make it virtually impossible for you
to run your stuff on that device.

For example.  On one of my devices I have a loader that runs in initrd.
That loader is owned by me.  Without that loader you still could load
the GPL code into memory but you would have to recreate the work that my
loader does.

People that write real embedded devices don't use 100% GPL software.  I
know I don't.  I would suspect that I could use 50% GPL and 50% stuff I
write my own.  So in order to recreate my effort to 100% you would have
to make a similar investment in work.

As far as OpenSSL license is concerned I've not had a problem with it.
It is fine.  

I think some people believe that if you run any code on Linux that the
code must be GPL.  That is not true.  So this is where you may have
issues trying to get code from companies that create embedded devices
based on Linux.  Not all the code is straight from the community. Some
of it is written by paid employees and belongs to the organization.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Licenses...

Ted Mittelstaedt


>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]]On Behalf Of Christopher Fowler
>Sent: Tuesday, April 11, 2006 5:23 AM
>To: [hidden email]
>Subject: Re: Licenses...
>
>
>On Tue, 2006-04-11 at 08:07 -0400, Wes Kussmaul wrote:
>> Are you suggesting that if you embed software in a hardware product,
>> it's no longer software?
>>
>> The GPL most certainly applies to embedded versions of software
>> products
>> which it licenses.
>>
>> If that were not true then I would be able to put any GPLed software
>> onto a USB thumb drive and call it exempt.
>
>I don't think so.  What he is stating is that someone can provided the
>GPLed software that they use on their embedded system and then it may be
>possible or not possible for you to run your own modified versions on
>their hardware.
>
>I believe it is okay to create a "disti" that runs on a device with
>proprietary code and license only that "disti".

The phrase "with proprietary code" is very fuzzy.  If your proprietary
code becomes part of a binary file that includes GPL (ie: links into
it) then you are WRONG.

If your proprietary code is NOTHING MORE than a loader then you are
correct.

>You can download the
>GPL software from the project but you would not be allowed to download
>the proprietary code.  This would make it virtually impossible for you
>to run your stuff on that device.
>

No, it wouldn't, because all you have to do is download the GPL software,
mod that, then upload it back to the device.

>For example.  On one of my devices I have a loader that runs in initrd.
>That loader is owned by me.  Without that loader you still could load
>the GPL code into memory but you would have to recreate the work that my
>loader does.
>

Once more, very fuzzy.  If your code is a loader then how am I gonna load
my stuff into your device without it?  All I have to do is take the
firmware
image for your device, separate out your loader, replace the GPL with
my own GPL, and put it back together and put it back into the device.
How is your loader going to know that my GPL is any different than your
GPL unless you modded your GPL - in which case you have to make those
mods
public per GPL.

>People that write real embedded devices don't use 100% GPL software.  I
>know I don't.  I would suspect that I could use 50% GPL and 50% stuff I
>write my own.  So in order to recreate my effort to 100% you would have
>to make a similar investment in work.
>

Only if I want to modify the parts that you wrote that are separate
programs,
like the loader, and like any proprietary device drivers.  But if all I
want
to do is modify the GPL part of your code then if your following the GPL
I will have enough data to be able to do it.

>As far as OpenSSL license is concerned I've not had a problem with it.
>It is fine.
>
>I think some people believe that if you run any code on Linux that the
>code must be GPL.  That is not true.  So this is where you may have
>issues trying to get code from companies that create embedded devices
>based on Linux.  Not all the code is straight from the community. Some
>of it is written by paid employees and belongs to the organization.
>

If it becomes a part of a GPL program then it must be opened, per the
GPL.
Period.  No exceptions.  Ownership isn't an issue here - the copyright
stays with the company - but the code must be made public.

Ted

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Licenses...

Richard Levitte - VMS Whacker
OK, boys and girls, however much I actually enjoy discussing the
intricaties of licenses out the wazoo, I don't think a discussion on
how to interpret the GPL belongs in this list.  Let's move along,
shall we?

Cheers,
Richard


-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte                         [hidden email]
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Licenses...

Tyler MacDonald
Richard Levitte - VMS Whacker <[hidden email]> wrote:
> OK, boys and girls, however much I actually enjoy discussing the
> intricaties of licenses out the wazoo, I don't think a discussion on
> how to interpret the GPL belongs in this list.  Let's move along,
> shall we?

        +1... However, the descussion about how OpenSSL should interact with
GPL software has been quite valuable.

        Cheers,
                Tyler

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
1234