libera/#commonlisp - IRC Chatlog
Search
22:56:42
aeth
also, by the FSF's writings on the LGPL and Java, the LGPL (no need for the LLGPL) should be compatible with CL as long as the LGPLed files are user-replaceable (like Java's JAR files), e.g. as separate loaded FASLs
22:57:30
aeth
and the implementation files certainly should fall under that, so the LGPL also would work
22:58:46
aeth
moon-child: right, it does make packaging awkward because you'd have to load FASLs via something like ASDF, rather than building an all-in-one binary
22:59:06
moon-child
if my code is closed-source, and I use an LGPL'd macro, the result of that macro is output in my code. Changing the content of the macro won't change my code
22:59:45
aeth
You would have to recompile the dependent files if the dependencies' FASLs are replaced, like QL:QUICKLOAD does, but unlike what packaged Lisp binaries tend to do
23:13:37
etimmons
Doesn't the LGPL say that small enough macros (<10 lines, IIRC) don't make the object file that uses them a derivative work?
23:14:49
etimmons
But that does suggest that trivial macros don't really limit how you distribute your closed source executable
23:15:43
etimmons
(other than the aforementioned requirement to allow people to swap out the LGPL'ed fasls)
23:17:02
aeth
etimmons: well, yes, the language is C-specific, but https://www.gnu.org/licenses/lgpl-java.html
23:17:26
aeth
"FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this."
23:18:26
aeth
Considering that they have 2 Common Lisps (CLISP, GCL), 3 Schemes (Guile, Kawa, MIT), and at least 1 other (elisp), "all known programming languages" has to apply to Lisps
23:21:54
etimmons
aeth: yeah, I've seen that. I was mostly bemoaning the language with respect to macros
3:08:28
beach
1. As jackdaniel pointed out, there is unfortunately a lot of aversion against GPL-like licenses, and it seems to be very bad in the Common Lisp community.
3:08:32
beach
2. I want SICL modules to be used by other implementations, no matter what license those implementations have chosen to use.
3:08:33
beach
3. Code like that of SICL is not unique in that other code bases do the same thing, so there is less need to protect it. I think the FSF has some special exceptions for language processors.
5:41:16
kakuhen
for instance, you will see a lot of calls like (ensure-directory-pathname "ccl:foo;")
5:41:33
kakuhen
is this some relic from the classic mac os days or is there something meaningful with this convention?
5:44:23
specbot
Syntax of Logical Pathname Namestrings: http://www.lispworks.com/reference/HyperSpec/Body/19_ca.htm
5:48:35
kakuhen
That seems correct, but I'm not entirely sure. In the function CREATE-IDE-BUNDLE, for instance, you have a string SOURCE defined as "ccl:cocoa-ide;ide-contents;". This corresponds to .../ccl/cocoa-ide/ide-contents on my actual drive.
5:50:55
conjunctive
Hello, has anyone worked with lisp-binary? Trying to understand how I should represent padding in this DSL.
6:55:05
kakuhen
Doesn't this break the standards? The hyperspec states the function "determines the pathname that corresponds to the user's home directory on host," but CCL always ignores the host.
7:43:30
pjb
kakuhen: note that this is not pathname hosts, but network hosts. Since there is absolutely nothing specified making the link between pathnames and network, it really lies entirely into implementation specific domain.
7:46:00
pjb
kakuhen: but even assuming an implementation that would deal with some kind of network file system. With most network file system in use nowadays (say, NFS and Samba, possibly various cloud FS, such as DropBox, iCloud, etc), you don't get to choose on what host your user-homedir-pathname is on. This is the local system that decides, and your home path is always relative to the local file system, even if it's remotely mounted.