On Thu, 23 Oct 2008 17:02:03 -0000
PatRiehecky <email address hidden> wrote:
> To double check my assumptions before going forward:
> 1) Debian holds that GPL software must make some exception for it to be correctly linked with openssl
Correct.
> 2) JYL does not note an exception nor believe it to make any sense to do such
Correct.
> 3) Without such an exception Debian will not link this
Correct.
> 4) Ubuntu follows Debian in such policies
It looks like it, but I've never seen an official statement.
> 5) Without the linkage no ssl is done
Correct.
> A part of me wants to attack 4 for being a bit like a blind man
> following another, but as a loyal Debian and Ubuntu user, I will keep my
> mouth shut on such matters.
>
> Part of me wants to attack 2, while I know that in JYL is standing on
> principles that are personally important, refusing to write a sentence
> on this matter.... I do not intend to criticize someone for abiding by
> their principles in the face of adversity.
Nice. :)
> Instead I will aim at making 5 imply 2. The argument that follows is
> based entirely on premise 1.
>
> A) MN has code in it which links to the openssl library
> B) MN is a GPL program
>
> Does A + B imply 1? Surly if JYL didn't want this code to be linked up
> to openssl no such code would be present. An analysis of the code
> demonstrates it is of high quality and does this linkage intentionally.
> The site documentation provides further support for a deliberate and
> intentional linkage to openssl. The build dependencies even list
> openssl as THE ONLY way to satisfy the SSL/TLS option. I would say that
> it is clear linking this to openssl is permitted by JYL.
>
> Given that it appears JYL has granted permission to link this to openssl
> by the inclusion of code which performs that function, why exactly do we
> need an official statement saying that linkage to openssl and
> distribution to others is permitted?
>
> The only bit that I feel would be needed to close up the leap would be
> an entry in the README indicating that JYL recommends linking the
> software to an SSL/TLS provider at all times. By saying that SSL
> linkage is recommended at all times along with the distribution of the
> source, it seems that anyone who is unable to determine if JYL will
> allow MN to be distributed along side of openssl is not paying
> attention. The key to sliding through the hole is the "at all times."
>
> See http://www.gnome.org/~markmc/openssl-and-the-gpl.html with
> particular attention paid to the Debian template at the bottom. My
> reading of it boils down to, "Yes you can link this with openssl, with
> the caveats expected" (Thanks for the link JYL)
>
> Question 1:
> Did I whiff on the logic? This argument is a form of Original Intent legal argument, but free from some of the problems as we are just dealing with code where the intent is a bit more obvious than ethics. http://en.wikipedia.org/wiki/Original_intent
Your analysis looks reasonable and senseful.
> Question 2:
> JYL are you willing to add this clause to the README? I expect you believe that SSL linkage should be done and as such this shouldn't violate your principles to encourage it.
I obviously encourage enabling the SSL/TLS feature, so I would not
mind adding something along these lines to the README file.
On Thu, 23 Oct 2008 17:02:03 -0000
PatRiehecky <email address hidden> wrote:
> To double check my assumptions before going forward:
> 1) Debian holds that GPL software must make some exception for it to be correctly linked with openssl
Correct.
> 2) JYL does not note an exception nor believe it to make any sense to do such
Correct.
> 3) Without such an exception Debian will not link this
Correct.
> 4) Ubuntu follows Debian in such policies
It looks like it, but I've never seen an official statement.
> 5) Without the linkage no ssl is done
Correct.
> A part of me wants to attack 4 for being a bit like a blind man
> following another, but as a loyal Debian and Ubuntu user, I will keep my
> mouth shut on such matters.
>
> Part of me wants to attack 2, while I know that in JYL is standing on
> principles that are personally important, refusing to write a sentence
> on this matter.... I do not intend to criticize someone for abiding by
> their principles in the face of adversity.
Nice. :)
> Instead I will aim at making 5 imply 2. The argument that follows is www.gnome. org/~markmc/ openssl- and-the- gpl.html with en.wikipedia. org/wiki/ Original_ intent
> based entirely on premise 1.
>
> A) MN has code in it which links to the openssl library
> B) MN is a GPL program
>
> Does A + B imply 1? Surly if JYL didn't want this code to be linked up
> to openssl no such code would be present. An analysis of the code
> demonstrates it is of high quality and does this linkage intentionally.
> The site documentation provides further support for a deliberate and
> intentional linkage to openssl. The build dependencies even list
> openssl as THE ONLY way to satisfy the SSL/TLS option. I would say that
> it is clear linking this to openssl is permitted by JYL.
>
> Given that it appears JYL has granted permission to link this to openssl
> by the inclusion of code which performs that function, why exactly do we
> need an official statement saying that linkage to openssl and
> distribution to others is permitted?
>
> The only bit that I feel would be needed to close up the leap would be
> an entry in the README indicating that JYL recommends linking the
> software to an SSL/TLS provider at all times. By saying that SSL
> linkage is recommended at all times along with the distribution of the
> source, it seems that anyone who is unable to determine if JYL will
> allow MN to be distributed along side of openssl is not paying
> attention. The key to sliding through the hole is the "at all times."
>
> See http://
> particular attention paid to the Debian template at the bottom. My
> reading of it boils down to, "Yes you can link this with openssl, with
> the caveats expected" (Thanks for the link JYL)
>
> Question 1:
> Did I whiff on the logic? This argument is a form of Original Intent legal argument, but free from some of the problems as we are just dealing with code where the intent is a bit more obvious than ethics. http://
Your analysis looks reasonable and senseful.
> Question 2:
> JYL are you willing to add this clause to the README? I expect you believe that SSL linkage should be done and as such this shouldn't violate your principles to encourage it.
I obviously encourage enabling the SSL/TLS feature, so I would not
mind adding something along these lines to the README file.
Thanks for this well-written contribution.
--
Jean-Yves Lefort <email address hidden>