Closed mlund closed 1 week ago
hth313
commented
1 year ago It is probably not so important, but even with the suggested license I am not going to include this library in the Calypsi package. I currently have no (L)GPL code and I prefer to keep it that way. This is for the benefit of my users. I do not want them to even have to consider the possibility that there may be (L)GPL code being linked in.
nobruinfo
commented
1 year ago @gardners In Discord you stated:
This cannot be found in readme.md, nor in LICENSE in the meg65-libc project. Also I very much doubt you can change a given LGPL license statement and remain OSS compliant.
@mlund Unfortunately the strongest argument against further using mega65-libc is its discussed limitation to owners of the Mega65 original hardware. This is a profound limitation which locks out other board users or Xemu developers like me unconditionally. I fear the discussion there is held with low to none legal framework for the project in place. This statement is simply not present in the license.
It's actually not that bad. We also had the discussion over at llvm-mos Discord how not suitable the lib's functions are to directly deliver them with the SDK of llvm. It was said they should be closer to cc65's syntax, which they are not. I was about to add functions for file mgmt (saving, formatting, disk sector write) for the lib which this way I sure won't do. So let's simply drop the existing lib, close this issue and rewrite those very few lines of code properly. I have no fear to even drop static as on a Iow memory for executable code unit I want to remain able to directly access all variables and memory and do nothing overflow secure. :)
There is however a handling problem for a lib like this in llvm-mos. The Mega65 project is a quite vivid one, constantly breaking compatibility. Also LLVM might later implement support for additional Opcodes of the 45GS02 CPU. The commit histories of the two projects will never fit and a lookup table will have to help on which version goes with which. Not ideal. So I'm still not sure if such a lib should be attached to the compiler suite.
mlund
commented
1 year ago Thanks @nobruinfo it's good points. I think what @gardners suggested was to add those lines in a future revision of the license text; a suggestion for this is shown above under "License Notice". Finally LLVM already supports all 45gs02 opcodes :-)
nobruinfo
commented
1 year ago @mlund I'm fully aware the additional license paragraph is already present in the description of this ticket. You made an excellent summary of things suggested which is handy to discuss and maybe later decide. My point only was I'm not sure this license even allows additions or removals. Also part of the discussion was that every letter changed in such a license seems to need full consult of all previous contributors. It was feared reaching all to be impossible.
Great to hear LLVM already improved support for the Mega. I am in general always surprised about the speed of work.
Btw, we still can do it both. Leave mega65-libc as is, work further on it and in parallel add own functions to llvm. Simply use different names (if not using namespaces because of older standard C) and decide after years to come. No license forbids being a contributor in both projects. Simply don't copy code from one to the other.
mlund
commented
1 year ago 👍🏻 I also do not know the legalities of changing a license, but it was done for llvm via an online form.
I like the idea that mega65-libc works with multiple compilers as programmers need to know only one API. It also seems laborious to maintain several compiler-specific libraries with identical functionality. While convenient it's not strictly needed to package mega65-libc with compilers. And it seems neither Calypsi nor LLVM are willing to do that even with the proposed update. I agree that libc is still evolving, but not at a very rapid pace. The only breaking change that I know of was from 0.2 -> 0.3 when moving headers into a mega65 sub-folder.
nobruinfo
commented
12 months ago @mlund Thank you for all your work for it. Leaving the legal issues behind to me mega65-libc is:
I don't mind breaking changes in such libs as an application will only ever be fit for a specific version of it. Also the slow progress is absolutely no problem for me, I tend to see the Mega65 platform as something for years to play with. :)
Nothing in between the to of us: Sometimes it's a bit sad people bringing up things, mostly well intended. Then I ask, "but have you considered?" No intention to push my opinion but only meaning: "If this were the case would you still stick...?" This I do to equilibrate a decision is resilient and everyone was able to interpret. Unfortunately folks tend to go quite on that.
mlund
commented
12 months ago @nobruinfo I'm very happy for your input and it's only well recieved. And yes I fully agree that retro projects are supposed to take time :-) I'll leave this issue open for some time, hoping to get input from more folks.
My personal opinion is that mega65-libc should be as compatible and available as it can possibly be.
This issue is for discussing a possible update of the license for mega65-libc. Currently LGPL3 is used which can be problematic for distribution closed source projects, see snippets below.
Requirements (input wanted!)
Suggestion for revised license
The following are to be added at the top of all relevant sources files.
License notice
This file is part of MEGA65-libc.
MEGA65-libc is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. In addition to the rights and responsibilities granted under the LGPL, you are also granted the right to use this software under the terms of the zero-clause BSD license, but only for software that is exclusively for use on the MEGA65 platform.
MEGA65-libc is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with Foobar. If not, see https://www.gnu.org/licenses/.
Snippets from Discord (chronological order, roughly)
I think there are disadvantages with having mega65-libc and possibly other parts of the open source software around MEGA65 licensed under LGPL3. It makes it difficult to distribute projects that uses e.g. libc and it prohibits inclusion in cc65 and llvm-mos since they both have more permissive licenses. Something like Apache or MIT is easier to handle in derived project, but a transition would require approval from all past contributors.
If you distribute a closed source software, it will be difficult, as you need to provide ways to relink the software with a modified version of mega65-libc - which is not really possible. So, in essence, no way to distribute a closed source commercial software that uses mega65-libc
that's common way to handle LGPL, yes. Provide pre-compiled objects and allow user to link, or use DSOs (.so/dlls) Not really fitting poor Mega65 due to lack of runtime-linking
Anything written in C/C++ or Rust would likely rely on libc for accessing disks, DMA copy etc. It's entirely possible to write a game or other software in a high level language (C is still much faster than BASIC) and it seems unnecessary to complicate distribution of closed source projects
I Am Not A Lawyer, but IIRC the process for an electronic signature essentially amounts to collecting an agreement that the signer's intent is to provide an electronic signature, then capturing that the signer agrees to the thing being signed.
A signature is mostly just a verifiable signifier of intent. Intent can be mostly implicit when it's in line with general expectations about e.g. how a normal open source project operates. When a big deviation from that occurs, like a relicensing, it can be useful to make things more explicit, since it removes ambiguity about whether or not consent was given down the line.
I'd also add that llvm-mos also adds LLVM's exceptions to the Apache license to remove the attribution requirement. Even traditionally permissive licenses like BSD, possibly MIT, etc, require including the text of the license with distribution of object code. For e.g. ROM cartridges, that means shipping a little paper booklet full of legalise. There's only a few licenses that don't have this requirement; zlib (used by cc65), LLVM Apache, Boost, and zero-clause BSD are the only ones that spring immediately to mind
I realize that LGPL for this library is a problem for me in distributing it with Calypsi. I cannot silently include this library in a build for the user, as it would affect their ability to license their application
I'm fine for us to add additional license options for the mega65-libc. This should be as simple as a release for inclusion in linked/compiled programs without further requirements
Indeed, then zero-clause BSD might be very easy, as you don't need to mention its use anywhere as mysterymath mentioned earlier
I'd still like it qualified that the extra license is only for use on MEGA65, so that folks can't take the code and use it closed-source on some other platform. e.g. "In addition to the rights and responsibilities granted under the LGPL, you are also granted the right to use this software under the terms of the zero-clause BSD license, but only for software that is exclusively for use on the MEGA65 platform."
Perhaps better to say "must be released first for Mega65," similar to the way I modified the CC for MegaKitty... so long as Mega65 gets the MegaKitty game first, porting seems fine. Maybe same for the libs.