Licenses...
Locked
1234
1234
 
|
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] |
|
|
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] |
|
|
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] |
|
|
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] |
|
|
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] |
Re: Licenses...
|
|
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] |
Re: CA embeded in Java client
|
|
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] |
|
|
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] |
|
|
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] |
|
|
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) |
|
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] |
|
|
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] |
Re: Licenses...
|
|
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] |
|
|
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] |
|
|
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] |
|
|
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. > > 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] |
|
|
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] |
|
|
>-----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] |
Re: Licenses...
|
|
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] |
|
|
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] |
«
Return to OpenSSL - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |