First, copyright law in many countries makes it almost certain that the C64 font resulted in the creation of copyrights for someone at some point. This is the easy starting point.
The next question is who owns the resulting copyrights today, following the multiple liquidations of Commodore-related entities.
Another question is, given that no one has been prosecuting those copyrights for many years now, what impact does this have on their enforceability.
Yet more questions arise because it is has been noticed that the C64 and Atari 8-bit computer fonts have identical lower-case characters, with the ones on the Atari pre-dating the C64 ones considerably. I.e., it is probable that the lower-case characters of the C64 font were created by someone other than Commodore.
Then arises some more interesting questions.
Commodore had tried on occasion to update the C64 font, but gave up when they realised that in various subtle ways that software depended on the exact contents of the C64's character ROM to function correctly. Apparently they tried just moving the dot on the lower case I and found that it caused at least one program to fail.
Thus it may be argued that the C64 font is required, 100% verbatim, to create a computer that is compatible with the C64. This rather exotic legal argument is important for countries that have a copyright exemption for the purposes of interoperability. Australia is one of those.
The relevant Australian legislation is section 47D of the Copyright Act, 1968:
Reproducing computer programs to make interoperable products (1) Subject to this Division, the copyright in a literary work that is a computer program is not infringed by the making of a reproduction or adaptation of the work if:Given that the character ROM has been acknowledged by Commodore employees in the past as being vital to providing interoperability with the C64, does this section apply?
(a) the reproduction or adaptation is made by, or on behalf of, the owner or licensee of the copy of the program (theoriginal program ) used for making the reproduction or adaptation; and
(b) the reproduction or adaptation is made for the purpose of obtaining information necessary to enable the owner or licensee, or a person acting on behalf of the owner or licensee, to make independently another program (the new program ), or anarticle, to connect to and be used together with, or otherwise to interoperate with, the original program or any other program; and
(c) the reproduction or adaptation is made only to the extent reasonably necessary to obtain the information referred to in paragraph (b); and
(d) to the extent that the new program reproduces or adapts the original program, it does so only to the extent necessary to enable the new program to connect to and be used together with, or otherwise to interoperate with, the original program or the other program; and
(e) the information referred to in paragraph (b) is not readily available to the owner or licensee from another source when the reproduction or adaptation is made.
(2) Subsection (1) does not apply to the making of a reproduction or adaptation of a computer program from an infringingcopy of the computer program.
First, if you own a C64 character ROM, it is clear that you could rely on sub-section 1(a) to make a copy, and include that in your own FPGA bitstream. That would require you to run the synthesis process yourself. Not very convenient.
Since that test fails, we must now satisfy 1(a) through 1(e) for a developer of the C65GS to be able to distribute a bitstream that includes the C64 character ROM.
1(a) requires that the ROM be sourced from a legal copy. This can be done by reading the ROM from a real C64.
1(b) is satisfied if such a legally sourced copy is used to satisfy the needs of interoperability with any program. Since there exists programs that I would like to make the C65GS interoperable with, that are understood to rely on the exact contents of the C64 character ROM, this is satisfied.
1(c) is satisfied because we need the entire ROM to provide the interoperability. Having only part of the ROM would not suffice.
1(d) is satisfied because such programs require the ROM to be available just as it was on the original C64 -- i.e., mapped to a particular memory location, and visible by default to the video controller in particular ways -- in order for the C65GS to interoperate with them. Failing on any point of this would not suffice to provide interoperability with the C64's software portfolio.
1(e) requires that the information (the contents of the ROM) is not readily available from another source. This is where it gets a bit interesting again.
The C64 & C65 ROMs can be freely downloaded from the internet in many places. Thus, it can be argued that they are readily available. However, if they are readily available in this way, then it must be on the basis of those copies being legal copies. If they are not legal copies, then they are not candidates to contradict 1(e).
This is a bit interesting, because depending on the answer to this unanswerable question, indicates from where the ROM should be sourced -- and existing online source, or from a real C64 ROM chip (or other undeniably legal source).
To add to the complexity is JiffyDOS, which is an adaption of the C64 ROM set, and for C64C's the JiffyDOS ROM contains the character ROM. JiffyDOS is apparently still available for purchase. However, what is not clear is whether JiffyDOS includes the C64 character ROM on the basis of an interoperability exemption, or on the basis of a license from a past or present owner of the ROM.
The JiffyDOS situation has yet another facet: To provide interoperability with a JiffyDOS-enabled C64, it is just as necessary to have the complete C64 character ROM as for a non-JiffyDOS-enabled C64.
So what is the situation? Can I include the C64 character ROM or not, and if so, where should it be copied from?
I think the answer is clear as mud.
Then there is the question of whether any of the symbols defined in ASCII 1963, ASCII 1967 or Unicode which have only one or very few possible representations in an 8x8 grid are actually copyrightable at all. Similarly, the publishing of PETSCII as a de facto standard probably makes the ordering of the characters unenforceable in terms of copyrights.
It is rather frustrating that the situation is so horribly vexed.
The simpler solution to avoid all possible problems in this regard, is that I should include a freely-distributable 8x8 font, which gets replaced in memory by the correct font when the C65GS loads a ROM from the SD card, so that the bitstream contains material that could be subject to an external copyright claim.
Fortunately, there are some free 8x8 fonts out there, like this one or this one.
So the only down side is that the kickstart display will not be in the C64 font.
Of course, if I get the OS a little further, it could boot up with a proportional font for the boot display, and side-step this sticky problem altogether... So I have a couple of solutions open to me.
Hi,
ReplyDeleteYou could ask Cloanto how they handle this problem in their "C64 forever" distribution.
And for JiffyDOS, just ask Jim Brain if it would be possible to officially license it for your customers (as soon as the C65GS will be available for purchase *g*).
Regards,
acn128
Hello,
DeleteGood idea re Cloanto. Do you have contact details?
As for licensing the ROM from Jim Brain, I really don't want to have to pay a per-user license, because the C65GS core is free and open-source software. As I mention, there are some pretty easy fall-back solutions anyway.
Paul.
Hi,
DeleteYou can find Cloanto's contact information e.g. here:
http://www.amigaforever.com/
And concerning JiffyDOS, maybe something like a "plug-in" option for the user to optionally purchase it could be an option.
Regards,
acn128
Danke. Yes, it would be quite possible to load a JiffyDOS ROM image on the C65GS. In fact, there is really nothing to stop you from being able to do it now, except that the C65GS then wouldn't be able to see the 3.5" floppy drive DOS, which is implemented in the C65 ROM.
DeletePaul.
Hey Paul,
ReplyDeleteDoes the C65 motherboard support same cartridge expansion as the real C64? If the answer is yes, then you do not have to worrky about JIffyDOS ROM as then the user himself have to purchase the cartridge and use it. You do not have to worry at all about copyright issue.
JiffyDOS is not a cartridge (like e.g. the Action Replay), but a ROM replacement.
DeleteYou have to replace the C64 ROM chip inside the C64 with the JiffyDOS ROM and also the ROM in your floppy station(s) to fully use JiffyDOS.
Regarding cartridge port, a real C65 does have a (somewhat) compatible cartridge port. However, the C65GS doesn't yet have a cartridge port (physical or virtual), because there isn't really much need, and the extra addressing complexity would cause some problems. For cartridge games, these can usually be made to run from RAM, and for utilities like the Action Replay, if you still need that on the C65GS, then we haven't done our job properly! For starters, the normal loading speed is now faster than the Action Replay's fastest loading speed.
DeletePaul.
This is a really interesting concern! Although I'm afraid I can't add anything to the discussion, I for one would really like to see the official C64-font used from start to finish including - of course - any ROM initialization messages! In fact, I would go as far as saying that not using the C64-font would be like depriving the C65 a big part of its graphical identity and its relationship to its 8 bit cousins!
ReplyDeleteHello,
DeleteI agree that it isn't nice that it isn't completely clear whether I can include the C64 CHARROM in the bitstreams that I supply.
Now, that said, there is probably nothing stopping people from resynthesising their own bitstream with it included -- it is just a 5.6GB download of the ISE tools, and a few hours of CPU to do this.
Also, if others are willing to find a plausible legal way to include the CHARROM, I would welcome it, but I am not going to have the project held up by me doing this.
I should also say that if the font is loaded from the SD card, it will just as likely be loaded by the time your monitor obtains sync on the video signal, and if you hit reset (as compared to FPGA bitstream reload), then the loaded font will still be there -- it will be only for <3 seconds during first power on.
Also, we can of course use a font which looks quite similar, if we can find one -- or indeed if someone wants to design one. Kickstart actually only needs A-Z, 0-9, $, ?, !, @, ., &, :, comma and just a few other symbols. It wouldn't take to long for someone to generate such a font.
Meanwhile, I have found some interesting things:
1. Copyright on bitmap fonts does not exist in the USA, Japan or several other countries: http://en.wikipedia.org/wiki/Intellectual_property_protection_of_typefaces In those countries, the CHARROM thus seems to be fine to include and redistribute. Sadly Australia is not on the list.
2. In the UK and a number of other countries, the maximum copyright period for a typeface is no more than 25 years -- in which case the CHARROM would be fine there. Apparently Australia isn't one of those either.
3. For Australia, this seems to be a conservative guide of what is okay: http://www.copyright.org.au/admin/cms-acc1/_images/6479575575265eb6dc1948.pdf and has some interesting points. It implies that in Australia, if one has a license (possibly implied) to reproduce a typeface in documents, that they can reproduce the image of the font (last paragraph before "Further Information"). Thus it *may* be acceptable to sit down at a real C64, and display each of the characters on screen, and then using that to transcribe a new charrom (with identical content to the original!), and then we have a solution for Australia, the USA, Japan, the UK and Eire. The EU legislation would then remain the major outstanding item.
Paul.
If I had known rebuilding the C65 would be a journey filled with obscure legal quirks like these, then I probably would have thought twice before raising the sails. That being said, I'm glad I'm not at the helm! :)
DeleteAs far as the discussion about placeholder fonts goes, you may want to check out this page [ http://kofler.dot.at/c64/ ] - a lot of the 8x8 bitmap fonts may be commercial, but I'm almost positive that there are a few interesting candidates suitable for the default C65 bitstreams (at least until some kind of workaround has been found).
Everything interesting has obscure legal quirks to worry about.
DeleteNow, regarding the font, what I have almost done, and will do a proper blog post about when I get it finished, is that I have put the necessary characters for Kickstart in a charrom, sourcing those characters from a public domain 8x8 font (the VGA one). The aesthetic of that font is not great (I have already hand-edited away a number of the serifs), but it is functional. I have modified the design to allow the CPU to replace the CHARROM contents on the C65GS, so now I am doing the final piece of modifying kickstart so that it sets the CHARROM from the character ROM part of whatever ROM it loads. I have some bugs in that, but it shouldn't be too hard to fix.
Now, what would be great if you are willing would be if you can find a nice looking 8x8 public domain or permissively licensed font that I can use in place of the VGA one for the few seconds while Kickstart loads the proper ROM on first boot.
Thanks for the update, and I totally agree with you - the old VGA font won't win any awards! As far as doing some digging of my own (on your behalf), I just may take you up on that offer! If I find anything, you'll be the first to know :).
DeleteNo worries. As you will see in the next post on this blog, I have implemented the load-the-font-from-SD-card solution. I also have someone who is going to create a nice looking font to use in kickstart. Also, kickstart is typically finished by the time the monitor gets video sync, so you probably won't even see the kickstart message unless you really want to.
DeletePaul.
I am not so sure about the status here. Have the copyright issue resolved?
ReplyDeleteWe haven't got a clear outcome on this, so we have made our own font to use in the bitstream, until it loads whatever font you like from the SD card. So the copyright issue is nicely avoided in the FPGA bitstream.
DeletePaul.
GREAT! Does that mean I can buy the hardware and you send me the core via email??
ReplyDeleteIn principle, yes, but we have some fine details to arrange for this to happen, partly because the bitstreams will be updating fairly often as development continues. I'll be posting about this once we are ready to be able to distribute bitstreams. So please hold on just a little longer.
DeletePaul.