Re: License issue on tiny Javascript fragment
Ken Arromdee writes: > On Sat, 7 Feb 2009, Bernhard R. Link wrote: > > 1) The safe way: See what it does, describe someone else not > > knowing the code to write code doing this for you and use that > > code. > > Does that actually work? The description is a derivative work of the > code; I don't think that's true. A derivative work is one that, in the judge's opinion, re-uses part of the original creative expression. If you express entirely in your own terms (modulo terms that have no other reasonable alternative, such as API names) how the program functions, you have not made a derivative work. > the new code is a derivative work of the description Again, by the same argument, I don't think that's correct. -- \ “I know the guy who writes all those bumper stickers. He hates | `\ New York.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: License issue on tiny Javascript fragment
Ken Arromdee writes: > On Sat, 7 Feb 2009, Bernhard R. Link wrote: > > 1) The safe way: See what it does, describe someone else not > > knowing the code to write code doing this for you and use that > > code. > > Does that actually work? The description is a derivative work of the > code; Here's an analogy that I think demonstrates why your assertion isn't so: Person A has written a novel. Person B can write an encyclopedia article that describes in detail (but in their own words) that book. Person A's copyright is not infringed because person B did not make a derivative work of the book. Likewise, I don't think a prose description of the operation of a program is thereby a derivative work of the program. -- \ “If you make people think they're thinking, they'll love you; | `\ but if you really make them think, they'll hate you.” —Donald | _o__) Robert Perry Marquis | Ben Finney -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: License issue on tiny Javascript fragment
* Ken Arromdee [090209 05:39]: > On Sat, 7 Feb 2009, Bernhard R. Link wrote: > > 1) The safe way: See what it does, describe someone else not knowing the > > code to write code doing this for you and use that code. > > Does that actually work? The description is a derivative work of the code; > the new code is a derivative work of the description and therefore the old > code. Again, I've no legal training, so all educated guesses, ask a lawyer if you want to be sure. I think the main point of that is to make the description in a form that is not a derivative work. The form is monopolizeable, the ideas and algorithm behind it are not. Thus a description that only describes parts that are not protectable should effectively cut all chains of copyright. (This of course requires that the description is only describes the ideas and algorithms and is nothing like "first there is an if, then a open parenthesis, then..."). Note that I do not claim this is the only way, just that is a way so safe that I cannot immagine any judge to see any problems there... Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: smssend - GPLv2 without SSL exception - What to ask to upstream ?
Didier Raboud writes:
> Hi debian-legal,
>
> smssend was removed from Debian due to licensing issues (#399685 and
> #487523). As far as I understand it, the problem is/was the following :
>
> * the code efectively links to OpenSSL (through skyutils2)
> * its licence is GPLv2+ _without_ OpenSSL exception
> * the upstream author was unreachable (email address is now dead - domain
> for sale and without MX).
>
> Assuming that :
> * I would be willing to handle upstream and Debian packaging
> * I would be able to contact the upstream author, either per email or per
> written mail.
>
> What should I ask the upstream author to do ?
>
> * Re-licence with OpenSSL exception => I would be able to "fork".
> * Make the code "Public domain" => ditto, but possible ?
> * Grant me or some{body,thing} the intellectual property => FSF, SPI ?
> => Would this organisation then be allowed to relicence as needed ?
>
> My guess is that the upstream author has forgotten for long his program and
> would prefer the "easiest", but which one is it ?
The first option seems easiest to me, if there is a single authorship
that is able to grant the re-licensing.
Using public domain may be complicated depending on the jurisdiction.
Granting some external body the ownership is nice, but probably requires
dead-tree papers to exchange hands, which doesn't seem like the
"easiest" choice.
Another option you could explore it to replace the code that uses
openssl with something else. Skytils2 doesn't seem to link to openssl
here?
Package: skyutils2
Depends: libc6 (>= 2.3.2.ds1-4)
So maybe there isn't a problem. I can't find the smssend source code so
I can't tell what it really does. This option may be the really
simplest depending on how much code that uses openssl.
/Simon
--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: smssend - GPLv2 without SSL exception - What to ask to upstream ?
Le lundi 9 février 2009 13:37:49 Simon Josefsson, vous avez écrit : > Didier Raboud writes: > > Hi debian-legal, > > > > smssend was removed from Debian due to licensing issues (#399685 and > > #487523). As far as I understand it, the problem is/was the following : > > > > * the code efectively links to OpenSSL (through skyutils2) > > * its licence is GPLv2+ _without_ OpenSSL exception > > * the upstream author was unreachable (email address is now dead - domain > > for sale and without MX). > > (...) > > * Re-licence with OpenSSL exception => I would be able to "fork". > > (...) > > The first option seems easiest to me, if there is a single authorship > that is able to grant the re-licensing. Hi, According to the "AUTHORS" file of the last .orig.tar.gz, there are various authors, but one copyright holder. > Another option you could explore it to replace the code that uses > openssl with something else. Skytils2 doesn't seem to link to openssl > here? > > Package: skyutils2 > Depends: libc6 (>= 2.3.2.ds1-4) skyutils2 build-depends on libssl-dev. And in its latest shape, smssend did build-depend on skyutils2-dev and libssl-dev. I don't know how this influences the licence imbrication. > So maybe there isn't a problem. I can't find the smssend source code so > I can't tell what it really does. This option may be the really > simplest depending on how much code that uses openssl. > > /Simon You can download the latest smssend source code here : http://archive.debian.org/debian/pool/main/s/smssend/ To summarize what I understood : * skyutils(-dev) is LGPL and build-depends on libssl-dev - it visibly links statically against libssl-dev, because the resulting binary package does not depend on libssl. Can LGPL link to OpenSSL without exception [0] ? * smssend is GPLv2+ (without exception) and links against skyutils and builds with -lssl . Both are from the same upstream author and the only rdepends of skyutils is smssend. I guess that the simplest (but not the easiest) solution for me would be to fork the code of skyutils2 of and convert it to use GnuTLS, huh ? Best regards, OdyX [0] If not, it would have to be removed too. -- Didier Raboud, proud Debian user. CH-1802 Corseaux did...@raboud.com signature.asc Description: This is a digitally signed message part.
Re: smssend - GPLv2 without SSL exception - What to ask to upstream ?
> You can download the latest smssend source code here : > > http://archive.debian.org/debian/pool/main/s/smssend/ > > To summarize what I understood : > > * skyutils(-dev) is LGPL and build-depends on libssl-dev - it visibly links > statically against libssl-dev, because the resulting binary package does not > depend on libssl. Can LGPL link to OpenSSL without exception [0] ? I believe so, see e.g. http://lists.debian.org/debian-legal/2008/06/msg7.html > * smssend is GPLv2+ (without exception) and links against skyutils and builds > with -lssl . > > Both are from the same upstream author and the only rdepends of skyutils is > smssend. > > I guess that the simplest (but not the easiest) solution for me would be to > fork > the code of skyutils2 of and convert it to use GnuTLS, huh ? Yes, although looking at the code in skyutils2, it seems its only use of openssl is to download web pages or something like that. Can't you use libcurl instead? That might be a better abstraction level. However I didn't look closely at the code, so it may be doing something that libcurl cannot. /Simon -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: License issue on tiny Javascript fragment
On Monday 09 February 2009 03:08:14 am Bernhard R. Link wrote: > * Ken Arromdee [090209 05:39]: > > On Sat, 7 Feb 2009, Bernhard R. Link wrote: > > > 1) The safe way: See what it does, describe someone else not knowing the > > > code to write code doing this for you and use that code. > > > > Does that actually work? The description is a derivative work of the code; > > the new code is a derivative work of the description and therefore the old > > code. > > Again, I've no legal training, so all educated guesses, ask a lawyer if > you want to be sure. > > I think the main point of that is to make the description in a form that > is not a derivative work. The form is monopolizeable, the ideas and > algorithm behind it are not. Thus a description that only describes > parts that are not protectable should effectively cut all chains of > copyright. (This of course requires that the description is only > describes the ideas and algorithms and is nothing like "first there is > an if, then a open parenthesis, then..."). Just to add a bit more weight here, the above is more or less correct. When we talk about functionality we are, by definition, talking about patents. When we are talking about expression we are, by definition, talking about copyright. While the same physical object can be protected by both copyright and patent simultaneously, the two legal theories protect different aspects of that physical object and there is no overlap. Which means that if you can describe the javascript fragment at a purely functional level, then you are only describing those parts that are subject to patent, in which case you are free to reimplement that code provided no patent has been granted to the original inventor. Debian's policies on patents have been fairly forgiving in the past (essentially only worrying about patents which are being actively enforced), so I think the clean-room development idea being proposed is likely the safest route to go. But be certain to only describe functionality... once you start talking about implementation you enter into the world of creative expression, and now you are infringing on the copyright. But honestly, the function is trivially easy to describe in a pure functional sense and should take someone familiar with javascript all of five minutes to write once they understand what you are asking for. -Sean -- Sean Kellogg e: skell...@gmail.com w: http://blog.probonogeek.org/ Change will not come if we wait for some other person or some other time. We are the ones we've been waiting for. We are the change that we seek. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: smssend - GPLv2 without SSL exception - Rewrite the code, joung Padawan.
Le lundi 9 février 2009 15:22:01 Simon Josefsson, vous avez écrit : > Yes, although looking at the code in skyutils2, it seems its only use of > openssl is to download web pages or something like that. Can't you use > libcurl instead? That might be a better abstraction level. However I > didn't look closely at the code, so it may be doing something that > libcurl cannot. > > /Simon Hi again, for the record : it took me one hour to write a bash script that does exactly what smssend + its configfile did (with curl as you proposed). I think that in one week of bash scripting, I would be able to parse the *.sms smssend configfiles in a backwards compatible way and produce a new tool, based on curl, that fully replaces smssend (and skyutils2). The conclusion to the story is : don't mess with the licences and rewrite the code with the right tools ! Best regards, OdyX N.B. Many thanks for your enlightened piece of advice Simon ! -- Didier Raboud, proud Debian user. CH-1802 Corseaux did...@raboud.com signature.asc Description: This is a digitally signed message part.
Re: License issue on tiny Javascript fragment
Ben Finney dijo [Mon, Feb 09, 2009 at 07:24:22PM +1100]:
> > > 1) The safe way: See what it does, describe someone else not
> > > knowing the code to write code doing this for you and use that
> > > code.
> >
> > Does that actually work? The description is a derivative work of the
> > code;
>
> I don't think that's true. A derivative work is one that, in the
> judge's opinion, re-uses part of the original creative expression. If
> you express entirely in your own terms (modulo terms that have no
> other reasonable alternative, such as API names) how the program
> functions, you have not made a derivative work.
If you confuse patents and copyright, it might be true. However,
copyright deals with the exact, specific implementation
("materalization") of ideas or other creative forms, not the ideas
themselves.
--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: smssend - GPLv2 without SSL exception - Rewrite the code, joung Padawan.
Didier Raboud writes: > Le lundi 9 février 2009 15:22:01 Simon Josefsson, vous avez écrit : >> Yes, although looking at the code in skyutils2, it seems its only use of >> openssl is to download web pages or something like that. Can't you use >> libcurl instead? That might be a better abstraction level. However I >> didn't look closely at the code, so it may be doing something that >> libcurl cannot. >> >> /Simon > > Hi again, > > for the record : it took me one hour to write a bash script that does exactly > what smssend + its configfile did (with curl as you proposed). > > I think that in one week of bash scripting, I would be able to parse the > *.sms > smssend configfiles in a backwards compatible way and produce a new tool, > based > on curl, that fully replaces smssend (and skyutils2). > > The conclusion to the story is : don't mess with the licences and rewrite the > code with the right tools ! If you chose the right tools, most things are easy. :) Good luck finishing this. (Although maybe perl or python is more capable than shell script?) /Simon -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
