6 ms·

The problem with the readline library example is that there are BSD versions of the library. So you can do something like this: https://git.kernel.org/cgit/fs

by tytso 12y ago

The problem with the readline library example is that there are BSD versions of the library. So you can do something like this: https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/ss/get_readline.c https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/s... https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/ss/listen.c https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/s... So riddle me this. The ss library is under an MIT-style copyright license. Suppose you have a proprietary program (Say, the Solaris kerberos v5 administration daemon client, to take a not-so-hypothetical example). Now suppose it dynamic links against a version of libss that might dlopen readline, or might dlopen editline, and if neither is available, libss will fall back to fgets. Now suppose Solaris distributes their kadmin program independent of the version of libss distributed as part of e2fsprogs. Quick! Is there a copyright violation, and if so, who committed it?

dllthomas 12y ago
There are now BSD versions of the library. This was not true for several years, after the license was picked.
- yuhong 12y ago
  Yea, this is an old article.
  - mzs 12y ago
    I wonder what changed? "Updated: $Date: 2014/04/12 12:39:52 $" Maybe someone could look in archive.org, it's blocked for me.
    - LukeShu 12y ago
      The CVS log of the page: http://web.cvs.savannah.gnu.org/viewvc/www/licenses/why-not-lgpl.html?root=www&view=log http://web.cvs.savannah.gnu.org/viewvc/www/licenses/why-not-... The only change of substance since at least 2001 (when they started using CVS) is the rename of "Library GPL" to "Lesser GPL" (the 2001 version had a notice that the rename had occurred, but the article had not been updated). Most of the changes are adding additional translations, and minor markup changes (the most recent is "Remove empty <p> element.")
deleted 12y ago
[deleted]
mzs 12y ago
There is this interesting claim in the readline homepage: http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html "Readline is free software, distributed under the terms of the GNU General Public License, version 3. This means that if you want to use Readline in a program that you release or distribute to anyone, the program must be free software and have a GPL-compatible license." That's interesting, it does not say it must use GPL (which is what I expected, it seems a direct contradiction to the article we just read) and so libss being MIT seems fine. Nothing in libss source seems to include anything from readline, no header file, no copying portions of header file even, just some very small words in the dl loader like"readline", "add_history", "rl_forced_update_display", and so forth. I would hope that is fair use. I would say that Oracle though might have a problem though if can't study the source freely for their client. But it seems wrong in someway that they should have such a problem since they copied so little and so indirectly. To be safe, they should modify libss and distribute a version where DEFAULT_LIBPATH in their private source includes no traces to readline. It's sort of ironic though regarding the recent Oracle v. Google ruling, to be sure theyu really should also modify most editline function names to something like oracle_foo_0, oracle_foo_1, ... shouldn't they ;) Seriously, this is a very interesting question, it's a good one for a lawyer in fact.
comex 12y ago
As it happens, this exact argument was put forth by the "at least one application program" that converted to free software: http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-... It was never actually resolved, because the CLISP author decided that making his program free software would be a good idea for other reasons anyway. In the past, I would have disagreed with RMS's insinuation that a GPL violation would occur, because, as stated: > So the only reason why you may object is that my lisp.a has an INTERFACE that allows it to be linked to libreadline.a . As far as I know, only the readline CODE is copyrighted, not its INTERFACE. (Would you object because my libnoreadline.a has a similar interface?) Only... we just got a US court decision that APIs are copyrightable. Although readline's API is much simpler than large parts of Java, it's substantial enough that I'd argue the decision nevertheless implies that libedit is a copyright violation. Which I find ironic, since most of the programs affected by the decision are free software clones of proprietary software, not the other way around.
- saurik 12y ago
  The court opinion stressed pretty strongly that Google's usage of the Java API was never actually intended to build an interoperable implementation (stating that Google was unable to point to any specific examples of code that would even be interoperable ;P) but instead to build a non-interoperable platform that was heavily inspired by the work that was put into Java. I think Google could have made a better case for attempting to be interoperable in certain ways (such as with libraries as opposed to "apps"), but apparently they didn't, and in fact came off quite strongly as trying to build their own unrelated-to-Java platform for various technical and business reasons. It still seems to be the case that if you are building a system whose goal is truly to be interoperable (such as libedit is to libreadline) you would not run into problems. For much more detailed commentary and argument (as well as quotes from the opinion), I encourage you to read my comment from that thread: https://news.ycombinator.com/item?id=7723853 https://news.ycombinator.com/item?id=7723853
  - zAy0LfpBZLC8mAC 12y ago
    I don't have a clue what Google's specific goals were, but couldn't an argument be made that compatibility with existing knowledge of developers is also a form of interoperability, and in particular one that needs to be protected from monopolization?
stonemetal 12y ago
There was no distribution of GPLd code so I don't think there was a violation of the GPL. On the other hand I could see the claim there was a violation with the proprietary app being at fault. They should have verified all of their dependencies not just the direct ones.
- tytso 12y ago
  The proprietary app in this example, has no idea whether they are dynamic linking with a version of libss that has the dlopen functionality (which is the case in the version of libss distributed with e2fsprogs), but there is also the version of libss distributed with Solaris SEAM and the MIT Kerberos v5 distribution which does not dlopen readline. This is the problem of whether the GPL infects across dynamic linking. Yes, it is possible for GPL and proprietary code to be in the same process address space, without any knowledge of the owner of the proprietary address space. It was the user who decided to use a particular version of libss, not Solaris.
  - stonemetal 12y ago
    * It was the user who decided to use a particular version of libss, not Solaris.* That is exactly why I don't think there is a violation. Sun didn't ship code that linked(dynamically or otherwise) to GPL code. The end user did something to make that happen. It would be a violation by the end user if they shipped their combined product.
    - tytso 12y ago
      Sun shipped could which _could_ link dynamically to GPL code. The problem with this "GPL infects across dynamic linking" argument is that you are therefore trying to make the claim that whether or not kadmin is infected by GPL code is dependent on whether there exists another library which is not licensed under the GPL. This gets perilously close to claiming copyright infringement, with the added wrinkle that the simplest way for someone to take code that was previously claimed to be GPL infringing is to create and ship a new library which is ABI compatible. So something could be a GPL violation, and then when a new library ships, et voila!, it's not no longer a violation. And something could orignally clearly not be a GPL violation, but when a new library ships which has a dependency (implied or explicit or even conditional in the case of an optional dlopen) on GPL code, now that proprietary binary can now run with GPL'ed code in its address space.
tzs 12y ago
This is reminiscent of the RIPEM situation ~20 years ago. This was a program that did email encryption using RSA. RSA was implemented using a library from RSA (the company) that was freely distributable but not free software, and because RSA (the encryption method) was patented, there was no way in the US to replace this library with free software. RIPEM also needed a big integer math library. The two main free software libraries for this were the GNU one and the the BSD one, which had different interfaces. RIPEM could be built to use either. This was an option you could set when you ran the build script. The FSF said that distributing the RIPEM source code was a GPL violation, even though they did not claim copyright on any code in the RIPEM distribution. In particular, they were adamant that they were not claiming a copyright on the GNU mp library interface. Their claim was that since RIPEM contained code (the conditional code that used the GNU mp interface) that was only useful with GNU mp, distributing that source code would lead to some people downloading GNU mp, which they would then link with RIPEM and the non-free RSA library, and that this meant that the RIPEM people had effectively distributed GNU mp with non-free software. See note [1]. The RIPEM people finally put an end to this nonsense by making a "new" mp library that had the same interface as the GNU mp library and was either (memory is hazy) just a thin wrapper for the BSD mp library, or was just a quick and dirty implementation of the simple, classical mp algorithms that any decent programmer can knock out from Knuth fairly quickly. This meant that people receiving the RIPEM source and choosing to build using the GNU mp interface might not actually build with GNU mp. They might instead build with this new library. Now induced distribution can no longer be inferred. This satisfied FSF. This was pretty astounding. If X is written first, and Y is written second, the answer to the question of whether or not Y infringes the copyright of X does not change if a third thing, Z, comes along AFTER X and Y. Copyright law obeys the arrow of time. :-) [1] I may not be remembering their theory exactly correctly. The general outline (RIPEM not distributing any GPL code, but FSF thought they were liable anyway if someone downloaded RIPEM source, downloaded GNU mp source, and linked them together) is right.

by tytso 12y ago

dllthomas 12y ago

There are now BSD versions of the library. This was not true for several years, after the license was picked.

yuhong 12y ago
Yea, this is an old article.
- mzs 12y ago
  I wonder what changed? "Updated: $Date: 2014/04/12 12:39:52 $" Maybe someone could look in archive.org, it's blocked for me.
  - LukeShu 12y ago
    The CVS log of the page: http://web.cvs.savannah.gnu.org/viewvc/www/licenses/why-not-lgpl.html?root=www&view=log http://web.cvs.savannah.gnu.org/viewvc/www/licenses/why-not-... The only change of substance since at least 2001 (when they started using CVS) is the rename of "Library GPL" to "Lesser GPL" (the 2001 version had a notice that the rename had occurred, but the article had not been updated). Most of the changes are adding additional translations, and minor markup changes (the most recent is "Remove empty <p> element.")

deleted 12y ago

[deleted]

mzs 12y ago

There is this interesting claim in the readline homepage: http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html "Readline is free software, distributed under the terms of the GNU General Public License, version 3. This means that if you want to use Readline in a program that you release or distribute to anyone, the program must be free software and have a GPL-compatible license." That's interesting, it does not say it must use GPL (which is what I expected, it seems a direct contradiction to the article we just read) and so libss being MIT seems fine. Nothing in libss source seems to include anything from readline, no header file, no copying portions of header file even, just some very small words in the dl loader like"readline", "add_history", "rl_forced_update_display", and so forth. I would hope that is fair use. I would say that Oracle though might have a problem though if can't study the source freely for their client. But it seems wrong in someway that they should have such a problem since they copied so little and so indirectly. To be safe, they should modify libss and distribute a version where DEFAULT_LIBPATH in their private source includes no traces to readline. It's sort of ironic though regarding the recent Oracle v. Google ruling, to be sure theyu really should also modify most editline function names to something like oracle_foo_0, oracle_foo_1, ... shouldn't they ;) Seriously, this is a very interesting question, it's a good one for a lawyer in fact.

comex 12y ago

As it happens, this exact argument was put forth by the "at least one application program" that converted to free software: http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-... It was never actually resolved, because the CLISP author decided that making his program free software would be a good idea for other reasons anyway. In the past, I would have disagreed with RMS's insinuation that a GPL violation would occur, because, as stated: > So the only reason why you may object is that my lisp.a has an INTERFACE that allows it to be linked to libreadline.a . As far as I know, only the readline CODE is copyrighted, not its INTERFACE. (Would you object because my libnoreadline.a has a similar interface?) Only... we just got a US court decision that APIs are copyrightable. Although readline's API is much simpler than large parts of Java, it's substantial enough that I'd argue the decision nevertheless implies that libedit is a copyright violation. Which I find ironic, since most of the programs affected by the decision are free software clones of proprietary software, not the other way around.

saurik 12y ago
The court opinion stressed pretty strongly that Google's usage of the Java API was never actually intended to build an interoperable implementation (stating that Google was unable to point to any specific examples of code that would even be interoperable ;P) but instead to build a non-interoperable platform that was heavily inspired by the work that was put into Java. I think Google could have made a better case for attempting to be interoperable in certain ways (such as with libraries as opposed to "apps"), but apparently they didn't, and in fact came off quite strongly as trying to build their own unrelated-to-Java platform for various technical and business reasons. It still seems to be the case that if you are building a system whose goal is truly to be interoperable (such as libedit is to libreadline) you would not run into problems. For much more detailed commentary and argument (as well as quotes from the opinion), I encourage you to read my comment from that thread: https://news.ycombinator.com/item?id=7723853 https://news.ycombinator.com/item?id=7723853
- zAy0LfpBZLC8mAC 12y ago
  I don't have a clue what Google's specific goals were, but couldn't an argument be made that compatibility with existing knowledge of developers is also a form of interoperability, and in particular one that needs to be protected from monopolization?

stonemetal 12y ago

There was no distribution of GPLd code so I don't think there was a violation of the GPL. On the other hand I could see the claim there was a violation with the proprietary app being at fault. They should have verified all of their dependencies not just the direct ones.

tytso 12y ago
The proprietary app in this example, has no idea whether they are dynamic linking with a version of libss that has the dlopen functionality (which is the case in the version of libss distributed with e2fsprogs), but there is also the version of libss distributed with Solaris SEAM and the MIT Kerberos v5 distribution which does not dlopen readline. This is the problem of whether the GPL infects across dynamic linking. Yes, it is possible for GPL and proprietary code to be in the same process address space, without any knowledge of the owner of the proprietary address space. It was the user who decided to use a particular version of libss, not Solaris.
- stonemetal 12y ago
  * It was the user who decided to use a particular version of libss, not Solaris.* That is exactly why I don't think there is a violation. Sun didn't ship code that linked(dynamically or otherwise) to GPL code. The end user did something to make that happen. It would be a violation by the end user if they shipped their combined product.
  - tytso 12y ago
    Sun shipped could which _could_ link dynamically to GPL code. The problem with this "GPL infects across dynamic linking" argument is that you are therefore trying to make the claim that whether or not kadmin is infected by GPL code is dependent on whether there exists another library which is not licensed under the GPL. This gets perilously close to claiming copyright infringement, with the added wrinkle that the simplest way for someone to take code that was previously claimed to be GPL infringing is to create and ship a new library which is ABI compatible. So something could be a GPL violation, and then when a new library ships, et voila!, it's not no longer a violation. And something could orignally clearly not be a GPL violation, but when a new library ships which has a dependency (implied or explicit or even conditional in the case of an optional dlopen) on GPL code, now that proprietary binary can now run with GPL'ed code in its address space.

tzs 12y ago

This is reminiscent of the RIPEM situation ~20 years ago. This was a program that did email encryption using RSA. RSA was implemented using a library from RSA (the company) that was freely distributable but not free software, and because RSA (the encryption method) was patented, there was no way in the US to replace this library with free software. RIPEM also needed a big integer math library. The two main free software libraries for this were the GNU one and the the BSD one, which had different interfaces. RIPEM could be built to use either. This was an option you could set when you ran the build script. The FSF said that distributing the RIPEM source code was a GPL violation, even though they did not claim copyright on any code in the RIPEM distribution. In particular, they were adamant that they were not claiming a copyright on the GNU mp library interface. Their claim was that since RIPEM contained code (the conditional code that used the GNU mp interface) that was only useful with GNU mp, distributing that source code would lead to some people downloading GNU mp, which they would then link with RIPEM and the non-free RSA library, and that this meant that the RIPEM people had effectively distributed GNU mp with non-free software. See note [1]. The RIPEM people finally put an end to this nonsense by making a "new" mp library that had the same interface as the GNU mp library and was either (memory is hazy) just a thin wrapper for the BSD mp library, or was just a quick and dirty implementation of the simple, classical mp algorithms that any decent programmer can knock out from Knuth fairly quickly. This meant that people receiving the RIPEM source and choosing to build using the GNU mp interface might not actually build with GNU mp. They might instead build with this new library. Now induced distribution can no longer be inferred. This satisfied FSF. This was pretty astounding. If X is written first, and Y is written second, the answer to the question of whether or not Y infringes the copyright of X does not change if a third thing, Z, comes along AFTER X and Y. Copyright law obeys the arrow of time. :-) [1] I may not be remembering their theory exactly correctly. The general outline (RIPEM not distributing any GPL code, but FSF thought they were liable anyway if someone downloaded RIPEM source, downloaded GNU mp source, and linked them together) is right.