Calculator Users: If you're searching for a solution to the "NEED LIBLOAD" error, follow this link:
https://github.com/CE-Programming/libraries/releases/latest

If you have further questions, follow the steps in this video tutorial: Installation video

This will also solve issues related to "Error: Missing Library"

I'm very excited that this is finally here! I'll do my best to post a news article about this and the other tools you've been releasing lately at some point today; in the meantime, I have a few questions:
1) What made you choose $C0,$C0 as the library header bytes?
2) I see that the library version number is a single byte. Does that mean it's something of an ABI number rather than a build number-style version number?
3) Do you have a sample of the launcher code to be embedded in programs? For something like Doors CE, I'd probably experiment with embedding this launcher code as a library call within the shell itself to be able to further reduce the size of ASM and C programs, since I'll be providing a few rudimentary libraries anyway.
4) I see that the code is GPL'd. Just to make sure that I correctly understand the terms of the license, that precludes using it as a component of another project without forcing that project to become GPL'd as well, correct?

I'll post more thoughts as I have them. Obviously I find this both a useful and technically-impressive piece of work; keep it up!

I originally choose $CE,$CE, but then I preferred to go with $C0,$C0. They are basically just header bytes in the appvar itself, so they really aren't too important. A 'ret nz' and 'retnz' don't appear often at the start of variables anyway


Yes, a new version means added functions. If you change the functionality of some function, you don't necessarily have to update the version byte. Libraries are expected to be backwards compatible with previous versions of the same library.


I have the whole library development interface, which builds the includable asm include and C header file for you. There is also a few sample programs as well using libraries, and a template to start a new one.


This isn't something you would use in a project. It is just an AppVar that sits nicely on your calculator in the archive doing absolutely nothing. It would be pointless to have a shell create it, as then if a bug was discovered in LibLoad, the shell would also have to update. Headaches all around. Anywho, yes, libraries and programs can still be closed source and still use this. However, that is kind of pointless and unreasonable in my opinion, because it only helps the developer, and is really silly as a community library system. Who's going to fix it if the developer decides to drop the project? I mean, seriously.

My experience is that the vast majority of end users can barely understand how to unzip a program from a zip file, let alone understand that they need to download LibLoad and send it to their calculators. Therefore, a shell intended to be user-friendly to as many users as possible would probably want to have the option of providing LibLoad itself. If the shell simply contained the code for LibLoad and created the AppVar if it didn't already exist, then the end user could have a newer LibLoad with bugfixes if the developer had for some reason dropped the shell project, or if the user didn't have LibLoad, at least the shell could provide something.

Since LibLoad is licensed under GPLv3, this is only possible if the shell is also open source. This isn't because I am against closed-source software by any means, but it simply doesn't make sense to do as it is a deterrent for both developers and users. Having to rewrite functions and figure out on their own how to program something is by no means a fun task. Opening up the community to more open source software can only be a good thing. LibLoad can be distributed along with a shell; not in the binary unless as stated above. In addition, users better get used to transferring files, as libraries are AppVars on their own. Maybe that will prompt more people to join the community as they might have to learn something

If you're not opposed to closed-source software and want to promote use of LibLoad, I might suggest the LGPL instead. This will prevent people doing a runner with your code, while still allowing it to be used in other projects.

I'm fairly confident that it can be promoted just fine without a license change since it can be bundled as part of other stuff (in the same .zip). But Mateo will/does have the last word anyway.

Making it directly part of other binaries just doesn't make sense, in addition to adding version issues.

Libs themselves will have to be transferred at some point anyway, and those too wouldn't be part of a shell, so users will have to download them (or at least transfer them from the same zip file if they're bundled too) thus already making a need of several downloads/transfers. One more (and possibly one time) for libLoad/libs will be easy enough, IMHO.

Okay, in all seriousness, the whole point is to make it easier to write programs. That's it. I don't have any qualms about anyone taking the code and using it in whatever they please; if I didn't feel it was best to promote a collective community rather than a closed source one, I would have licensed under the WTFPL license. Also, if anyone can actually use the LibLoad code for anything and understand it, more power to them. Its only use is loading libraries that have a plain and flexible structure. My simple stance is that an open source toolchain for a really limited platform is perfectly acceptable; this way in the future it can easily be adapted or added to. If you don't want to use libraries, you don't have to. This just makes it easier and faster for anyone who wants to actually do something, so they don't need to write their own fast line, circle, and other routines.

TO CLEAR THINGS UP:
Libraries, programs, and such can remain closed source and still use the LibLoad AppVar. I don't care what your interpretation of the License says, this is how it is. Programs such as shells that want to create the AppVar for whatever reason can, but they must be in some way open source. Note that because this system is not shell dependent, it can easily be cross-compatible across many shells at once. If this goes against your beliefs, don't create the AppVar and just include it in the distribution, or go write your own library loader that is closed source so no one can make it better, and break everything in the process for users and developers. Blame me for this decision all you want, but it is pointless to keep a thing as simple as a library loader closed source. Axe is closed source to protect its functionality, but this isn't a library. It loads libraries.

Thank you for the clarifications about the licensing and intents; that clears everything up.

Here's the problem: the GPL, as it stands, requires any code that *links* to your code to be open source. This isn't just shells, it's also the client programs. Your verbal description of what you expect sounds very much like you intend a linking exception, but as it stands, we can't just "Libraries, programs, and such can remain closed source and still use the LibLoad AppVar." The safest way to do this in a way that protects both the rights you want to hold, and the rights you intend to provide the users of LibLoad, is to use the LGPL, rather than rolling your own linking excpetion, but either way, you should definitely read the article I just linked to.

[edit]
The Classpath linking exception uses decent phrasing too:

In practice, the "viral" aspect of the GPL wrt. dynamic linking is not as clear-cut as it is wrt. static linking, as shown by e.g. proprietary Linux kernel modules.
Open source is the norm nowadays, especially in a community like ours.

Mateo: Regarding your deleted post, people just want to make sure that they're respecting and not violating your license; I don't see people as trying to nitpick it. I know I speak for all of us when I say that your work on making more TI-84+CE programming possible is greatly appreciated.

"not clear-cut" being the operative phrase. A linking exception immediately resolves the issue. Certainly the plain intent of the license is that all forms of linking are considered derivative ("combined") works.


Yes, and this is certainly a good thing, but that doesn't mean we have any right to impose that norm. Moreover, while Mateo is certainly free to require anything he likes for the users of LibLoad, I'm merely pointing out that his stated intentions differ from the stated intent of the license he chose.



It's also a good idea to resolve these sorts of issues now, while the copyright is in the hands of a single individual. If, at this stage in the game, he starts accepting pull requests, or any forks gain traction, we'll be stuck with things the way they are.

Okay then. The license has been changed to the LGPL v3, and past releases have been updated to reflect this. I really wish I knew how all this licensing stuff works, but meh. Thanks for your help and input everyone!

EDIT: Before I break something else, BSD 2 clause is fine for libraries themselves, right? People can use libraries without copyright information needed?

MIT/BSD/Apache licenses are all "permissive" licenses, which means they can be used for pretty much everything. The downside is that people can release closed-source improvements on your original work.

The GPL, in contrast is a "copyleft" license, which means, essentially "you are prohibited from making closed source releases, but can make closed-source changes for personal use if they are never publicly released as a binary". The stock GPL also prevents you from incorporating GPL software as a component in closed-source projects, which is sometimes referred to as "viral" licensing. "Linking exceptions" disable the viral component, while still protecting you from someone making closed-source releases of modified versions of your project. This strikes a good balance for library code that you want to be widely used. There's also an "extra viral" version of the GPL called the AGPL, aimed at webservers, which requires you to make an open source release if you're running the software with a publicly facing user interface, even if you don't otherwise release it.



As a resource to help figure this stuff out, I recommend checking out http://choosealicense.com/

This was moved to the last topic to help silly users:

LibLoad is basically a dynamic library loader for both C and ASM libraries for the TI84+CE/TI83PCE line of calculators. This allows programmers to not have to clutter memory with duplicated routines, and also provides a way to create faster programs than otherwise would be possible in normal C. If you are looking to create a LibLoad library, simply make your way to the WIP documentation page, available here:
http://ce-programming.github.io/documentation/tutorials/asm/lib-creation/

If you are interested in the technical details behind LibLoad, check out this page:
http://ce-programming.github.io/documentation/resources/asm/libload/

If you wish to download the latest version of LibLoad, make your way to the GitHub page:
https://github.com/CE-Programming/libraries/releases/latest

If you want to see the process that LibLoad takes in assembly in order to perform dynamic relocation of libraries, check out this flowchart: (Note that it is a little off; if a library requires no absolute relocations, it remains in the archive to save RAM space.)

One issue is that not every program author might make it clear in their readmes that LibLoad is required, so encouraging authors to do so or convincing Travis to add a TI-84 Plus CE Assembly Games (requires LibLoad) directory in their archives might be a good idea in the future.