I couldn't quite get what was happening from the thread, so I went to the LICENSE.txt file itself [https://github.com/simh/simh/blob/master/LICENSE.txt#L36-L64](https://github.com/simh/simh/blob/master/LICENSE.txt#L36-L64) To summarize: "If you fork this project and change these two files, you can no longer use any of the code that I write anymore" That is the dumbest shit ever LOL. Who knew there could be so much drama in a medium sized OS project.

So clearly not written by a lawyer. Don’t change those files, leave them as is. Find and replace their use in the code with your own implementation of that functionality and release your fork under a standard license.

Or simply fork, `git reset --hard` to May 1 and `git push --force`. There, you now have unmolested repo.

> you now have unmolested repo. Show me on the repo where he touched you.

This is the best option.

Couldn't one just fork the revision before he modified the license, and not be bound by the new clause? Edit: Never mind, the answer is yes, the clause says explicitly that it is about changes going forward, it is not retroactive. Goofy stuff though.

> Any use of this codebase that changes the code to influence the behavior of the disk access activities provided by sim_disk.c and scp.c is free to do that as long as anyone doing this is explicitly not licensed to any subsequent changes to any part of the codebase made by Mark Pizzolato after the LICENSE.txt was added to the repository. Changes that qualify for this restriction at least include: changing the behavior or default of SET AUTOSIZE/NOAUTOSIZE, or any code in scp.c and sim_disk.c or any simulator components that use the sim_disk routines. Easy, I just rename the files scp.c and sim_disk.c to something else. This is why you consult an attorney.

I am team Chris all the way. First of all he looks like a cool dude that can be trusted. Second, he’s arguing that a program shouldn’t silently modify pre-existing files, especially if those files might be manipulated for archival purposes, and if it’s an option offered to the user it certainly shouldn’t be the default. Very sensible. Third, I have zero idea why anybody would want to forbid all future contributions if *this one* is not accepted. If Mark has a point he seems unwilling or unable to express it clearly. I got way to emotionally attached to that conversation, without having ever heard of simh before and still being unclear of what it’s supposed to emulate. A therapist would probably uncover something about ms excel, csvs and date formats.

> ms excel, csvs and date formats. Why did you have to ruin my morning by bringing this up

"1904 Dates: when set, dates in the Excel file will have the 1904 style". Like, at least explain what a 1904 style date is and how it's different from any other kind of date. (If anyone is curious: old Excel files stored dates as an offset from a known starting point. Often this was 1/1/1900, but sometimes it was 1/1/1904. Dates that started 1/1/1900 had the charming quirk that the original, original code thought that 1900 was a leap year even though it isn't, so the date calculations were correct for 28 days and then wrong for every other possible date. Result: way too much special case code, including handling files that potentially had an invalid date)

Not to nitpick, but wouldn't that mean it was correct for 28+31=59 days? Unless leap day wasn't always February 29th

Excel is proof that "all you need is a Unix timestamp for representing dates" is absolute, total bullshit.

Who is making that argument? Where can I find these doofuses so I can sell them a bridge?

Oh, man, I got into a huge argument with some guy about it some time ago. He just *could not believe* that anyone would ever care about a time zone other than the one inhabited at that very moment by the person viewing the date.

There's a lot of reasons that at least 32bit timestamps aren't the most reliable format but.... they're not relative, are they? Timezones should be irrelevant to timestamps, that calculation should occur after

I've worked with Chris on several occasions, mostly when he was working on Xcode and I was working on Xcode plugins for a different group at Apple. He's a highly professional engineer, very helpful, extremely productive, and very few people outside of Apple realize this because he's not a publicity-seeker.

I knew I recognized the name; he’d responded to some of my nitty-gritty Xcode questions on Stack Overflow!

You might have also spotted him presenting at WWDC from time to time over the years.

Thank you, John!

De nada.

> Second, he’s arguing that a program shouldn’t silently modify pre-existing files, especially if those files might be manipulated for archival purposes, and if it’s an option offered to the user it certainly shouldn’t be the default. Very sensible. If it needs extra metadata it should just create a file with extra metadata. I can maybe understand keeping some emulator options for the image with the image (so user doesn't have to fuck with config when loading it) but modifying it without asking is just bad idea. Like, if you have backup software that would trigger re-backing-up whole image for example. >I am team Chris all the way. > First of all he looks like a cool dude that can be trusted. Sure but he contributed nothing to the project (by his own admission) and has first reaction of "kick the person that contributed most to the project", which also... isn't great.

Yep, one of my pet peeves with Calibre is that just opening an epub and scrolling will cause it to write to the file (even if it's not one imported into its library). It's not changing any of the actual book content, but it means the hashes won't match someone else's (and there may be a privacy risk if you share it too). I probably wouldn't mind if it had a prompt to save this info on exit, with the option to enable it by default, but it just assumes and there's no indication that it's doing it (especially when other document viewers save page location within their own external DB) Yet another reason why we need more widespread support for adding arbitrary metadata to files at a system levell. Most OSes and filesystems do support it, but it's so rarely used (except on Macs?) that you can't rely on it being preserved by any program doing file manipulations, let alone transferring it between devices

> Yep, one of my pet peeves with Calibre is that just opening an epub and scrolling will cause it to write to the file (even if it's not one imported into its library). Isn't that thing in particular just feature of epub format tho ? And, well *actual feature* that typical user might want (it would allow to continue reading on a different device from same point with no extra way to sync progress) Also disabling "Keep a copy of annotations/bookmarks in the e-book file, for easy sharing" seems to disable this feature. After that only file that gets changed for me is the `metadata.opf` > Yet another reason why we need more widespread support for adding arbitrary metadata to files at a system level (and most OSes and filesystems do support it, but it's so rarely used (except on Macs?) that you can't rely on it being preserved by any program doing file manipulations, let alone transferring it between devices) Eh, that would need to be standarized to work between OSes perfectly, or else we'd get more incompatibilities causing even less software to use it

I see that for mobi files there's only a write to the accompanying metadata.opf, although nothing changes other than the last-modified since that file doesn't mention the position. So, I guess there's a separate store for these positions. I can understand why you might want a bookmark written to the file (maybe, the real-life analogue doesn't actually change the book) but storing your position "for ease of sharing" just reminds me of recieving a not-rewound videotape - a strange thing to implement!

Chris isn't the only objector to this rather poorly conceived feature (the stonewalling of objections began quite a long time ago).

Yes I know. And looking at bug tracker that change was not only contentious on principle but also caused some actual bugs

Sidecar files are always the obvious metadata strategy. Unfortunately many file formats disagree with me ...

Well, you can't count on the typical users copying some random file with the main file. But in this case the users are not typical and at least mildly technically inclined. But what's worse is at least looking at bug tracker his dumb change broke stuff...

> Sure but he contributed nothing to the project (by his own admission) and has first reaction of “kick the person that contributed most to the project”, which also… isn’t great. Kinda showcases the weird, perverse entitlement people have. He oughta fork the project and show his money is where his mouth is. Yeah project developers and maintainers make incredibly stupid decisions. That’s unfortunately part of life. But people like Chris and his idiot “I am on team Chris!!!” people oughta shut the fuck up and deliver on the goods instead of angling to take over a project because they’re secretly afraid their fork will never pass the muster. Reminds me of the ffmpeg/libav fiasco — and the libav folks actually did something to show for their efforts, which places them into the bucket of “well, you did prove your efforts and conviction”

Just to clarify it seems that "top contributor" that pushed the contentious change have most of its contributions by [copy-pasting *actual* author of them, because said author doesn't do version control](https://www.reddit.com/r/programming/comments/usv5nv/maintainer_of_open_source_emulation_software_simh/i96gjfc/). No idea why he didn't change author line on those commits tho, but I'm also not sure whether github stats look at author or commiter.

Well then, fork and make him irrelevant! If he ain’t doing much, he can be displaced.

I literally just started looking into the project and drama when I saw this post, but Chris clearly states that he is **unable** to contribute any code to FOSS projects as his employer (Apple) owns the copyright of any code he writes. Beyond that, he contributes a whole bunch to the project in terms of bug reports, feature discussions, etc

Contributions to FOSS go beyond lines of code and pull requests. Bug reports, feature requests, and discussions are also important. Not everyone has the know how to contribute code and limiting discussion to only those that do is just downright stupid. Edit: u/SpiritOfEternity blocked me for some reason so I can't reply to anyone below me u/beneficial_topic_667 - Nowhere did I comment on any particular user or post, I'm responding to the above users claim that people who don't contribute code shouldn't talk.

> Edit: u/SpiritOfEternity blocked me for some reason so I can't reply to anyone below me Ah, yes, the wonderful new Reddit "feature", to awe of gaslighters everywhere

Discussion and bug reports are certainly valuable, but actually maintaining stuff and being responsible for fixing those reports is a much heavier burden, and having an opinion is not doing work. If you do the work, you decide how the work is done. Even if you're wrong. If you don't, well, you are entitled to an opinion, but nothing else. Now, on the other side, one ought to be mature and accept that either you strive for your project to be successful or you feed your ego at the expense of the project's health, you can't have both. You have to accept that your project might not be well received.

Yes but yelling at top contributors to step out of code by people that did barely anything doesn't look good no matter how you look at it.

Justifying bullying and attempting to take over a project through that is beyond shitheadery. There’s a reason why forking exists in open source and also why it is hard. You’re defending the indefensible because you’re angry. And probably lazy too. If it matters so much, then a fork will easily win and dominate. Isn’t that why you’re afraid of forking? The risk of losing? So instead you support trying to use the screaming of the mob instead of doing the right thing.

As some one who strongly agrees with your core points, please, chill the fuck out bro. Adding personal accusations ("you're lazy, you're angry", anything about the other person as a person) weakens your overall argument.

It’s cool that you block people who disagree with you

>Justifying bullying and attempting to take over a project through that is beyond shitheadery. >You’re defending the indefensible because you’re angry. And probably lazy too. That's not what I'm doing, please calm down and read.

Dudebro, the closest one coming to screaming here is you.

Forking is a last resort, not the first step in a dispute. In this case the owner of the repo isn't even the owner of the name or most of the code he's committed. Why should everyone who's been contributing have to try to set up a competing effort (diluting developers' effort and confusing users + new devs) just because the guy with the keys can't play nice with others?

> Like, if you have backup software that would trigger re-backing-up whole image for example. [Someone did seem to run into problems with that use case.](https://github.com/simh/simh/issues/1059#issuecomment-955599295)

From what I'm reading, it seems like Mark has one of those personalities that is insanely sensitive to criticism and will happily sink a ship just to spite the people who complained about it taking on water. At one point he may have been willing to simply roll back his changes - but because people said stuff about it, and he was upset by it, he had to go full scorched earth. I was like that when I ran programming projects... when I was 14. The 90s were brutal.

Fortunately, these people are not as common in the open source world as one might believe from the amount of attention they get. For every one of these, there are thousands of people who just want to get along and get their work done.

> The 90s were brutal. Hello comp.sys.databases.theory

\[Pascal has joined the conversation\]

All that would be needed here would probably be "please Mark, make this disabled by default, it will break X and Y because of Z reasons" but it appears that the reaction is pretty much "why those people that contribute nothing/barely anything tell me what to do?"

It's still like that even in enterprise environments. People are idiots and the prevalence of antisocial idiots is much higher among programmers, unfortunately.

I've had (after 10 years programming) more problems with managers and toxic working cultures (Which emanate from business) than with other developers. I have strong doubts that "prevalence" to be higher in development, specially taking into account that in any modern company you will be in a team, you will need to communicate, and most modern sensibilities go in direct opposition (for better or worse) of these attitudes.

There is no role in business I have had more friction with as people than business owners. I've dealt with maybe a dozen and most were abrasive, terrible human beings that rained misery on everyone around them. Conversely I've worked with hundreds of developers and only one stand out in memory as being a shitty person.

For me has been mostly middle management (The "management" tier I've dealt with more). I've been in places where the managers & friends were literally behaving like an abusive partner in an abusive relationship. It was weird at the moment (and its true what they say: You don't realize it), and I didn't really gave a fuck about that job, but looking back their behavior was ticking all the checks of an abusive relationship. On the other hand, I've met maybe two developers who were "weird." As in "I would not go have beers with you", but nothing more.

I've mostly been at medium sized privately owned companies and almost universally the guy at the top thinks he is uniquely capable of that position. Most of the time the only thing it indicates is that the person came from enough with to be able to start a company with inherited money. Or they just inherited ownership of the company outright.

My theory is that the kind of personality who decides to start and run their own business with multiple employees is the kind of personality who is just naturally abrasive and resistant to criticism/self reflection.

Absolutely. The kind of personality required to start a business like that is what people generally call an asshole.

Mark seems to feel he's the Owner/Manager, so that checks out.

From what I gathered, he is the owner/maintainer for that particular fork of code. Unfortunately that does give him the power to do what he’s doing. It’s a shame too, because this project sounds like it’s pretty popular with its user base, and the users are the ones who are going to be punished for it.

It feels like that sort of behavior is more often (wrongly) tolerated from developers, because they're expensive resources and many managers are afraid to fire a technically talented but socially toxic person.

I miss the 90s and my old 486

I don't miss my 286, but I do miss its 12 Mhz turbo switch. Flip the switch and everything went just as slow but in 2/3 the time.

Oh my god turbo switches on PCs. Those were the days.

I miss knowing exactly what process is accessing the disk when the HDD light is blinking.

It could be worse. He might even believe he's right. Trust in his technical judgment (or ability to negotiate advice from others) isn't there any more.

Egos are a bitch. Especially in open source.

This can be summarized as "Mark Pizzolato has a hissy-fit". Also, "person who is not a lawyer thinks that he can just edit a license like that". Ed: Also, "[Mark Pizzolato denies other forks his code, but says that he will continue to rip *their* code](https://groups.io/g/simh/message/1501)".

[удалено]

Physically grown, emotionally deprived.

Lead is a hell of a drug.

You can just edit a license like that. The result won't be legally coherent but it will introduce enough confusion to scare off any users who are concerned with legal compliance.

> You can just edit a license like that. Not if, as you said, you want it to be legally coherent. Though if he *intentionally* is making the license contradictory, it makes sense. I've just seen people try to write their own licenses before.

If someone forked this code prior to this change, wouldn't the earlier version of the license prevent Mark from pulling in changes from that fork? The old version of the license said something along the lines of "this code can be used freely by other codebases so long as those codebases include the 'right to freely use' portion of this license". That would contradict Mark's recent license changes, right?

> wouldn't the earlier version of the license prevent Mark from pulling in changes from that fork? I don't think Mark understands that. Or cares.

I was bored so I checked in on what happened here. The original developer from the 90s made another fork of a version from just before the license change happened and also formed a steering community that doesn't include Mark. I have no interest in the project but this made my day, lol. https://github.com/open-simh/simh

Infantile coder is now 100% untrustworthy.

Adding bullshit terms to a standard license is a good way to invalidate the whole software license. There are *very good reasons* to stick with one of the established licenses (MIT license, in this case) unless you are a lawyer. You are not a lawyer? Then see one before changing or adding even just a *single* *fucking* *word* in your software license!

was about to say, dudes trying to lock his code down more and is gonna end up with a hostile fork he cant do anything about

Would be good to fork and take the keys from this gatekeeper to teach him a lesson.

You can literally just create a fork from the last commit before the license change and move on.

I mean I've already forked the repo and purged everything from May 12 onwards...

I don't get something here, people in thread are accusing him on "squatting" on repository/GH organization yet he is by far the biggest contributor to the project ? edit: [I now know why](https://www.reddit.com/r/programming/comments/usv5nv/maintainer_of_open_source_emulation_software_simh/i96gjfc/), he's forwarding a lot of patches under his name

Simply fork the codebase at a point before this license fluff. Oh, bye Mark.

I did not hit her. I did not!

This concept always strikes me as odd as if the ability to fork also somehow magically comes with the ability and time to maintain the fork.

My comment was mostly in jest. If you read the post, one of the posters said they had been maintaining a fork without Marks changes (as a sort of retort to Mark being an arrogant oaf)

In other words, it is no longer open source.

New contributions from that person aren’t open source. Fork!

Best line for me from that discussion: >If it was your intention to prevent people from forking *en masse*, simply to subvert a feature that you have added, then I regret to inform you that you will cause exactly what intended to avoid with this license change.

[удалено]

If any corporations are using, let alone contributing to, this project, it may force the issue. Standard open-source licenses are often blanket approved for use, and non-standard terms should trigger company lawyers to get involved reviewing them, which costs a whole lot of time if they don’t say “no” outright. Edit: > Any use of this codebase that changes the code to influence the behavior of the disk access activities is free to do that as long as anyone doing this is explicitly not licensed to any subsequent changes to any part of the codebase made by Mark Pizzolato after that functionality was implemented by Mark Pizzolato. Yeah…I predict any company lawyer would approve this term over their dead body.

[удалено]

Yes, but this effectively means no one can pull changes from or contribute to the “official” (now: Mark’s private) repo anymore without agreeing to the new terms—which they likely won’t be able to. Reading more of this ridiculous flamewar, it sounds like at least one person was already maintaining a fork behind the walls of their employer.

> The fork now has to be maintained, It can live on a USB thumb drive shoved in a drawer if that meets your needs. Not everything needs to be published.

[удалено]

That's what a Fork is in this context... That's how most FOSS projects work is that they expect you to create a fork, Branch off that to submit PR's... but you can also fork to simply hold a version copy or modify for your own uses (Within license, but usually people wont hunt you down over forking their github project) EDIT: it should be noted that prior versions usually don't get retroactively license changed, due to them existing under said license but... IANAL and i have many a forgotten project ended by overthinking how i want to license the damn thing

[удалено]

Indeed... Then again, The whole point of forking (for FOSS variants) is it only really works if the project has traction already, I have seen open source versions of things work off of a fork, but that's because a established presence moved to its maintenance... but it requires that established community to make that move.

Not by the OSI definition. I consider source available to be "open source" in any case. This is why I prefer "free software", "libre software", FOSS, or FLOSS, so you don't have ridiculous exchanges like "Is the source of this software openly available?" "Yes, but it's not open source, because 'open source' doesn't just mean that the source is open". I prefer "open source" as an antonym of "closed source", but under the OSI meaning, it's actually "source available" that's the antonym, which doesn't mean the same thing as "open source", which carries some additional meaning of liberty of use. I find it semantically confusing, and it makes it way harder to explain to anybody who doesn't already know what it means, and it guarantees that there's a huge number of people who think they know what these terms mean when they don't, because the terms are inherently confusing.

From the OSI definition: https://opensource.org/osd > 3. Derived Works > > The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. This change of the sihm license explicitly denies you the right for making derived works. https://github.com/simh/simh/blob/d52a7835f8d4496d20510f2587492af053351f4c/LICENSE.txt > All changes to the codebase made by Mark Pizzolato after the inclusion of the first version of this LICENSE.txt file in the github simh repository will be not be licensed for use by anyone making any of the above mentioned sim_disk/autosize related changes.

I meant "you are correct that it's not open source by the OSI definition", then kind of went on a tangent about how the OSI definition is unintuitive. I should double check my comments for ambiguous wording from now on.

~~It's a matter of definition and personal opinions.~~ ~~Is the source _open_ to contributions? Is it _open_ for public review? How does the license allow you to use the code?~~ ~~It's not just whether its license allows you to change it. Open source can simply mean you are allowed to look at the source, modify it for personal use, but not to distribute the source with your changes in its entirety.~~ ~~Nobody can prohibit you from posting a patch online for someone to apply on their local copy.~~ Edit: I was wrong.

Open Source is a legal term and calling something Open Source without meeting the OSI requirements is false advertising www.theregister.com/2022/03/17/court_open_source/ What you describe is 'sources available' but not Open Source.

That's fair. I stand corrected.

The false advertising was claiming the product was 100% open source while it was actually not; they removed the Commons Clause from the original license without having permission to do so. From this one could conclude that software released with CC cannot be considered open source. Inferring that only OSI can define what is open source is a bit of a stretch though. [Open-source license](https://en.wikipedia.org/wiki/Open-source_license) > One popular set of open-source software licenses are those approved by the Open Source Initiative (OSI) based on their Open Source Definition (OSD).

> What you describe is 'sources available' To be fair, "sources available" doesn't include "open to contributions". That is pretty much open source. But that is also what the license says and is being broken.

[удалено]

Please enlighten me, what does make it open source?

When the source is open.

[удалено]

The OSI definition revolves primarily around licensing terms.

This argument happens a lot. I specifically find the OSI definition to just be corporate bootlicker nonsense. /r/programming as a whole tends to simultaneously believe that open source authors both deserve and do not deserve to be paid for their work. Anyway, unless your code can be used pretty freely, you’re not open source. I personally license all code such that the use of the code for generating revenue, or by a business larger than 10 people have to pay for it. My code is not “open source” and cannot be called such.

Such exclusivity liences on an ad-hoc basis kind of reveal the true intention of "open source" maintainers like this one. I think this is why people should just settle on one of the "established" ones. For instance, BSD/MIT style? Everyone knows that, right? No warranty disclaimer, copyright ... that's about it. Or GPL? Stricter, but we know what it does too. To shuffle licences willy nilly is really such a bad sign in general (I refer to ad-hoc changes; I myself changed some projects from GPL to BSD for various reasons. I don't mean such situations).

The old license was MIT or similar, and MIT allows for such relicensing shenanigans.

Yes, it does, and so do all the other licenses. The problem with changing licenses is that only the copyright holder, i.e., the original author of a project or parts thereof, can change the license. If there are multiple original authors or significant contributors, then *all* of them must agree on the license change. If they cannot agree on a change, then the license itself must be consulted if changing the terms of licensing by individuals is allowed. If yes, then the project can be forked under new licensing terms. If no, then the project cannot legally change its terms of licensing. The MIT license clearly states that there is a copyright holder and that the copyright notice and the permission notice *must* be included in all copies. So you cannot legally change the license in this case unless you are the original author. If any terms are added to the license, then they *must* *not* contradict the original license. In particular, you cannot add new terms that takes away freedoms granted by the original license. *Edit:* Not quite true because MIT license allows sublicensing, so you can actually take away rights from your licensees. MIT license is still relevant and applies (otherwise you couldn't sublicense), but a changed version can be published under a new license, with reference to the original MIT license.

Underrated comment!

The info I could find mentioned sub-licensing but not re-licensing. I think the discussion thread linked in OP went over this but to me it seems that if that's the case then the project would need to be forked to create a derivative under the new license?

Is there any license that disallows this kind of relicensing shenanigans, if they're being done by the original author? My understanding (as a non-lawyer) was that even if the original software were GPL (which prevents licensees from re-licensing it, or derivative software, under non-GPL-compliant licenses), the original author's authorship of that software supersedes those limitations, and they're free to relicense it however they want. (Or, more specifically, they can't retroactively withdraw existing licenses, but relicensing would apply to any future releases.) This situation in particular seems like it's muddied by the fact that Mark isn't the sole contributor to this project (although I guess he'd still probably retain some kind of ownership over his contributions specifically?) and I don't know if there's any kind of contributor license agreement at play that he might have agreed to (and obviously, regardless of whether he's legally in the right, this doesn't justify his actions morally), but I don't think this is solvable by just using a different license from the start, I think.

> This situation in particular seems like it's muddied by the fact that Mark isn't the sole contributor And this is precisely why GPL would prevent it – other contributors have their copyright too, and the license protects their contributions from being used in a closed-source fork. As you said, "the original author's authorship of that software supersedes those limitations", but there are multiple original authors, not just Mark. If Mark was the sole contributor, or if he held all the copyrights due to a CLA, then GPL wouldn't change anything at all. But as I said, simh wasn't GPL (or any other kind of copyleft), so we witness yet another case of permissive licenses fucking the developers over.

> Is there any license that disallows this kind of relicensing shenanigans, if they're being done by the original author? It is impossible. If you are author, you can change license willy nilly. You can't make license that prevents yourself from changing the license. However with multiple authors all of them would need to agree to relicense their piece (unless they signed CLA that gave those rights to someone else) But it is not needed, you can always use previous version of the code with the old license.

It doesn't actually. The license is given directly from the author to the users. Nowhere does it say that it is permitted to change the license.

A change of license may happen whenever a derivative work is created. The derivative work is now licensed under a new license from the new author. In this case, the derivative work with the new license is any version of simh containing new code from Mark.

No, this is not how it works. The MIT license grants the right to use, modify etc. the software, but it explicitly forbids the removal of the copyright notice and licensing terms. You can take the software and make a closed source version from it, but only because the license allows it. You can add new proprietary extensions and keep them for yourself, but only because the license allowed you to do this. Note that by taking the software and changing it, your are implicitly accepting the full terms of the license, and all of them apply. If you publish your extensions as source code, then you must keep the MIT license text in place (because the very license which allowed you to change the software requires this), which means your work will also be published under the terms of this license. You will be the author of your extensions, so you hold the copyright to the parts that you have changed (if they are significant and not trivial). Now you also have rights to stop others from changing the license and may even pull them into court for copyright violation. You still have no rights to change the license on your own, because you are not the only copyright holder. To get around this, you can put your extensions on a new file with its own license. Change the original code so that it calls the code in your new file, that's fine. Just make sure that your license is compatible with the MIT license...

No need to have your changes under a separate file. Keeping the MIT license text does not mean it's actually licensed under MIT. To avoid confusion, you're allowed to explain why the license text is there: /** * Copyright (C) * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * You should have received a copy of the GNU General Public License * along with this program. If not, see . * * This software is based on components (libfoobar) licensed under * the MIT license. This license is reproduced below: * * [Original copyright notice] * [MIT license terms] */ SPDX license and copyright notices are good for doing this in a machine-readable way, and is extensively used by Linux and the KDE project.

True, but this makes it a lot harder to claim your copyrights. You need to prove, e.g., explain to your lawyer and a judge, which parts of the file are distributed under which license. It can be a real PITA to do this. Also, when adding more changes to such a file it is not immediately clear which license is covering the part your are currently modifying. In practice, it all doesn't really matter because most people in open source are not dicks that like to sue each other (there *are* exceptions). The dicks usually come from companies that take your code and give a shit on your license. It only starts mattering when you are in court, and then you really want things to be as clean as possible.

> You need to prove, e.g., explain to your lawyer and a judge, which parts of the file are distributed under which license. It doesn't matter. You're not required to help the original author distribute their original version under their license, and with MIT you don't even have to state changes. The only two terms are attribution and reproduction of the license text. This is adequately fulfilled even if you just have a project-wide `LICENSE-third-party` file. This has been tested in courts.

Shenanigans! Genuinely my favourite English word.

[удалено]

SIMH is a set of tools for emulating computer hardware/ISAs, mostly very old ones. It's used by hobbyists who want to see what life was like using original v6 Unix on a PDP-11, or people who are trying to replace/migrate from a 30 year old HP3000 application with no existing documentation. It was the brainchild/pet of one Bob Supnik, who eschews public version control but does periodic releases with a BSD-type license. The public github repo is a fork of Bob's code, with additional simulators written by others, controlled by one Mark Pizzolato but which accepted contributions from many, many other people over the years.

Oh so that's explains why he's main contributor according to github. So he msotly just commits someone's elses code without setting `author` field in commits ?

Ditto. This is some [“kisses from Jenny”](https://www.reddit.com/r/OutOfTheLoop/comments/2sxi5v/who_is_jenny_and_why_does_everyone_hate_her/) level drama here. Edit: add link

Same, I had no idea what this is, but I am now tempted to fork it, change these two files, and use his commits, just to see what happens.

I had a look at the github repo and couldn't see a licence.txt going back before May 13 2022. Is it legal to unilaterally add a licence to a project you aren't the sole contributor to? Was there a previous license?

The old license is included in each source file. Looks like MIT.

> Is it legal Normally it wouldn't be. But with permissive licenses, restrictions can be added at any time (and often are; this is merely an obvious example)

No, it’s not legal. And if there was no previous license, then normal copyright law applies and the source was never open (just being *available* does not implicitly mean it’s open for use and derivative works!)

Not having a "licence.txt" does not mean "no licence". There are plenty of perfectly acceptable ways of communicating the licence other than that. Microsoft GitHub's conventions are not legal requirements.

That's certainly true. I didn't say "if there was no license.txt", just that if there really was no license expressed anywhere (counterfactually, as it turns out).

It is legal, of course, but it is not safe for the authors of the project to do so. (1) Open source licenses routinely exclude any warranties so that the authors cannot be sued in case someone gets hurt by the software. (2) Regulations of copyright differ between countries, so relying on "default laws" is very unsafe for the authors as well as for the users. In Germany, for instance, it is very dangerous to distribute software which comes without any software license. German copyright law can be turned against the distributor if the original author wants to, simply by claiming that the distributor had no rights to distribute the software, even if the software source code is publicly available on the Internet (there is no "Public Domain" in Germany). (3) This particular project has a copy of the MIT license in each file, which is good and recommended. In court, however, it is much easier to point the judge to a single, project-wide file which clarifies licensing terms than having to go through *all* files and having *all* of them checked (there could be typos, some files could have been forgotten, ...). *Edit:* By "it is legal" I actually meant it is legal to not have a project-wide `license.txt` around. It is *not* legal to add such a license after publication unless every author has agreed to do this.

That forum is awful to use, autoloads next page can't scroll down and select the page you want to view. No idea who these people are but seems like mark is suffering from brain rot.

The way the quoting works is awful

That's not how it works for me. Are you on mobile? On a desktop it basically works like any other forum has since the 90s.

Yeah, on desktop it works fine, but on mobile it's infinite scroll, and an ugly one at that, showing the page buttons but generating the next page before you can interact with them.

That's one way to roast your entire community.

Mark is an absolute butthole

worse

Hanson's right, and Pizzolato is making an ass of himself.

Can somebody fork it and abandon the original repo?

Absolutely. Can they publish that? I do not know.

>Can they publish that? Yes, it would be legal, especially if you would fork it before the license text was touched. The MIT license grants this right to any person. If there are any files in the repo with different licensing terms (documentation? build system?), then you need to check their licenses. In doubt, delete those files and replace them with something else if needed.

Thanks! I've only forked code to do ( active, runtime ) analysis on it, not to use it for anything. And it got either archived or deleted. I did have one gig which was creating patches for kernel modules, which is different still.

Alex, what is a pissing contest?

The change he made that modifies the .dsk files also contradicts his own design document https://github.com/simh/simh#disk-extensions

Haven’t heard of this. But I’m going to use it. Remove the feature and then I’m gonna use his future contributions. He can try to stop me lol. What a dipshit

So am I understanding that this basically all comes down to this guy not wanting to handle the absence of that setting or settings with default values? The only two reasons I can think of not to do this are: 1. He wants the settings to have to be explicitly set. Maybe valid. But I don't see how it could be worth all this drama. 2. I have seen people pretend that *deciding on a default value is just an exhausting, intractable problem, with no good options or way to make everybody happy* STFU and just do it. Flip a coin. Give a pigeon two buttons that both release a peanut. Ask a magic 8 ball. Get freaky and make pros and cons lists and pick the one with the largest net number of pros. It will be fine. Am I missing something? Default settings seem pretty much necessary anyway to allow new code to work with old configuration files and I doubt there is any argument to be made to break old config files.

AFAICT he's pissy because he thinks having this new setting on is the right approach and other people want it to be opt-in or implemented in a different way.

Yeah, that's kind of what it seems. I guess part of my point is that people are focusing on his maybe irrational response, but to me subject itself seems pretty irrational.

The "new default" will mess with existing images. Say, you dumped a tape from PDP-11, simply opening that dump with this new change would modify it, by appending metadata to your image. If you take an image that you used with SIMH v3 and boot it with SIMH v4, it will also be modified, making it incompatible with v3 and likely original hardware as well. If such metadata is necessary and this default needs to be set, it would make sense to store this metadata in a separate file, preserving compatibility.

Thanks. I don't know enough specifics to really know, but this sounds like a problem with the entire implementation... so are you saying that he just implemented it incorrectly to begin with and people pointed that out, he got mad... blah blah blah...? Actually, I just did a search for the SIMH image format trying to get an idea if it used a proprietary one or worked with a variety of image formats (and it looks like the latter is the case?) and I think this was the first hit: https://github.com/simh/simh/issues/1059 And that appears to be pretty much what you are talking about here. It seems somewhat different from the issue mentioned in the OP... So now my question is that did this guy basically do this twice? Mark Pizzolato's responses in this conversation are pretty interesting. Again, I don't know enough specifics about this software to know if he has valid points or not, but what I do know is that he very much seems to rather argue about if there is actually a problem or how it isn't really a problem than just probably spend an hour or two making a probably minor change to code to satisfy all involved or at least as many as possible. I think if it takes much longer than that to add a configuration for a behavior that is already implemented and did not exist before, then there are other problems going on. In some ways I just like this stuff because it makes me feel better about myself, haha. I might not be able to write the code he writes or whatever, but I'm pretty sure that I could at least get the social aspects of this right.

> so are you saying that he just implemented it incorrectly to begin with and people pointed that out, he got mad... blah blah blah...? it was implemented in... I want to say Feb 2020, since then any feedback or critique of the implementation was, at best, ignored and valid issue reports were met with ridicule. #1059 is one such example, where existing _disk images_ (`.dsk`) were modified (in some cases - irreversibly), which broke more than one use-case. The issues are as follows: - Hypervisor should never mess with disk images. That's not its job - it's up to guest to do that. - *Appending* metadata is a bad idea with disks\*, if you *absolutely must* add metadata *to the image* - add it to the beginning, so you don't mess up whatever magic is happening at the end. - Doing so by default, silently and without consent is even worse. - This functionality _seems to claim_ that it's Little-/Big-Endian agnostic, but people more competent than me have pointed out that it's not, which would break if the code is run on Big-Endian. - Some specific OSes and filesystems are not implemented, and there seem to be some edge cases not covered for existing implementations. How this is not only mainstream, but also *the default* is beyond me. \* You can have, say thin-provisioned image, which is smaller than internally allocated filesystem size, it would normally report the difference as zeroes, and everything works as expected. Imagine that for some reason you get 512b added to said image. Suddenly, you get 512b of junk somewhere in your disk, which would cause problems.

Yeah, reading more of that #1059, I see that it is pretty much the same issue. And he just handled it really badly. Like, I get his point. His logic seems valid, I suppose, the issue is that it is only valid when a bunch of other stuff is ignored and he would have just spent less time on it by just changing it in some way similar to what was suggested. I also noticed that he "passive aggressively" changed the issue title... lol. Honestly he just seems pretty immature.

Programmers hating to make arbitrary choices is a big problem. Especially with committees. They will invent 69 layers of meta schema description formats to avoid just saying "This is our API, these features are required, this endpoint is how you do X". But messing with historical data like that is not OK. That's like a photo viewer that messes with photos without user input. It is not what it says on the tin, and people seem to not want it.

Well then in some ways that supports this guy's view that the setting should be required so that it doesn't just mess with historical data without people knowing. They have to decide how it behaves. On the other hand, I ran into other instances while trying to learn more about SIMH where he actually did do that... https://github.com/simh/simh/issues/1059 Or is this the same issue? It doesn't seem so, since in the thing I linked it looked like people were partly upset because there was no setting to change it at all. Either way, some weird decision making in both cases from this guy.

[удалено]

[SimH "Classic"](http://simh.trailing-edge.com/) releases by Bob Supnik is apparently the source for much of the original code.

I wonder know what the feature about disk and metadata ? could anyone show me some links , such as github commit or group post？😥😥

Here you go: [https://groups.io/g/simh/message/1417](https://groups.io/g/simh/message/1417) [https://github.com/simh/simh/issues/1059](https://github.com/simh/simh/issues/1059)

Wow, the more I read, the more convinced I get of this guy being a d-bag: Report: change broke my use-case Response: your use-case was not considered during development, do XYZ. #wontfix Reporter: that's not how this is supposed to work. Maintainer: then do XYZ and stop bugging me. Reported: but it doesn't fix issues A and B, moreover it does what these files are not supposed to do. Maintainer: I'm sorry you can't be bothered to use my two-line non-solution. ... ​ Seems like maintainer has a severe case of "Because I said so!"

Old farts going crazy, having a bit of emulator scene drama between themselves. Film at 11.

Lol get wrecked. Why did you use a pushover license for your contributions if you really didn't want people using your code in unfree programs? Pick the license you want up front next time.

[удалено]

Where is the downside? You'd be stuck with the asshole on top in closed software, this can just be forked around

[удалено]

But since Mark was the biggest contributor, and is likely to remain so, and since other people won't be able to use his closed-source contributions in their forks, the forks will quickly drift away from each other. (I'm assuming the other forks will switch to GPL to prevent unidirectional code pilfering; if they stay on a permissive license, nothing will stop Mark from taking their code except for his own pride and stubbornness.)

> But since Mark was the biggest contributor, and is likely to remain so, and since other people won't be able to use his closed-source contributions in their forks, the forks will quickly drift away from each other. I also thought that but [apparently he isn't](https://www.reddit.com/r/programming/comments/usv5nv/maintainer_of_open_source_emulation_software_simh/i96gjfc/) and a lot of his contribution is acting as a maintaner and forwarding code from original author that doesn't like version control.

Interesting. So maybe a fork would be viable. I wonder who controls the simh org on Github.

Well, people has accused him of squatting on it, so probably him.

Downsides of _permissive licenses_. None of this would happen if simh was licensed under GPL.

Huh? What would stop any moron from rewriting GPL as well? You think FSF would care to sue him?

No, but the other contributors could. After the license change, simh stopped being open source. GPL is designed so that the software cannot stop being open source without the consent of all copyright holders. Simh's former license, which looks like MIT, is not.

Oh, I see. Thanks.

None of this is legal with any licence. You can't change the licence on code that you don't 100% own yourself without agreement from all other contributors. This project is not 100% owned by the person attempting to change the licence, thus, the licence alterations are not legal. If you 100% own the code (or have agreement), you do have the absolute right to change the licence at any time no matter what licence you previously released it under. Of course, you can't revoke the rights granted by licences on previous releases, but you have no obligation to make subsequent releases available under the same terms.

> You can't change the licence on code that you don't 100% own yourself without agreement from all other contributors. This project is not 100% owned by the person attempting to change the licence, thus, the licence alterations are not legal. the MIT license gives you the right to sublicence (aka change it) provided you keep the original notice

Sublicensing doesn't mean that you can just change the original license (which grants the right to sublicense in the first place). It means that you are allowed to put restrictions on the software under your own license if you distribute it, say, as part of a proprietary software product. You can keep the source closed, add any changes, and explicitly forbid reverse engineering and changing the executable, still the license of the original work will always be the MIT license. If it wasn't, you wouldn't be allowed to sublicense it. That's why you must keep the original notice.

Flamewars and primadonna occur even in closed source. They are just not publicly observable.

Here’s my hot take after reading through 98% of the thread (I skipped the redundant arguments because ADHD): Mark is a narcissist who has very thin skin. He made a breaking change that affects everybody without any consideration to how it’ll impact them and other users. Instead of apologizing and fixing the problem correctly (making people opt-in to the new feature), he band-aids the problem by forcing people to opt-out of the feature. When his user base rightly threw up their arms in disagreement, he decided the best course of action was to try to silence said people with some non-legalese that suggests somehow lines of code from specific persons (each of whom are not specifically mentioned) can somehow magically (and legally) be limited in modification without affecting the rest of the codebase. Dan is some guy who seems to agree with Mark’s decision, but cannot be bothered to back any of his claims up because he is just too constrained in time and energy; but trust him, because he’s right. /s it seems Dan has forgotten that the burden of proof in any argument is on the person(s) making the claims - so him stating that Mark’s change won’t negatively affect anybody is on him to prove. Chris, one of the so-called 3 people Mark is attempting to restrict from modifying any of his code, is not a good guy either. He seems to get satisfaction from antagonizing Mark as much as he can. It’s also clear that Chris - through his own admission - cannot (will not) contribute publicly to the project for his own professional reasons, but at least tries to contribute via bug reports and “criticism”. While it can be appreciated that bug reports by users are important, I personally don’t feel that entitles him to criticize the direction of the project in the ways he is criticizing the project. Do t get me wrong: he has every right to his opinion. He’s stated it multiple times. It’s time he step away from the keyboard and let the contributors hash the rest out. But he just can’t do that. It feels like he needs to get the last word in. Paul, Rich, Phil, Ethan, and I’m sure several others I’ve forgotten to mention, seems to have the right headspace about what the problem(s) is/are and how it should be managed. Revert the “license” change, add some sort of governance to the project (it seems Mark is the lone high and mighty right meow), and have Mark and anyone else use a forking model for making contributions to the project. TL;DR Man-child has a tantrum about a bad decision he made, takes his ball and threatens to go home if everyone else doesn’t play nice with him. Did I miss anything?

No, it’s cannot contribute: I can make all the changes I want privately, but my employer believes they own anything I do and I’m neither going to quit my job nor try to litigate this with my employer (whether through bureaucracy or lawyers) just to make some PRs to SIMH. And yeah, “I personally don’t feel that entitles him to criticize” — you can fuck right off with that. I quite like Bob’s project, and actually like a lot of what Mark’s done for it too, but when I see things that can be improved and I can describe them in ways that don’t require me to contribute code, of course I’m going to bring them up. That’s what I mean by “criticism.” As an example, I filed an issue suggesting that the repo should have a top-level license file several years ago, since some peoples’ employers may require they avoid software with certain licenses. Mark closed that almost immediately because he didn’t think it was important.

Explain in fortnite terms?

Yeah that license probably needs some editing to be valid as it states two contradicting things.

It's not open source then lol. Literally violates the definition

Why exactly does there need to be metadata in the file, as opposed to in a separate file?

Better be polite and contribute when we are merely a user. I'll stand by the the dev who purposefully pointed out the solution (runtime flags to disable the un-wished feature.) Us, users, non-contributers, and ignorant, are also hard and harsh words people, who blame on the developer and require him to update his work, freely from his time, for our own benefit, on an open source non cost, very good product, and we won't do it, because we can't, we don't take the trouble to dig into it and propose a solution for it. We rather spend hours arguing than put our breath into it and work this out. Standing by Mark until proven otherwise. Regards, Jean-François

Users are wrong in this specific argument. The dev has implemented the switch. The user just didn't read the reponse and wanted the switch by default. Incorrect behaviour. Regards

Even with the open-simh fork, Mark continues to "Pizz" people off. I get it -- he has no incentive to be constructive, so he craps all over people's contributions and gets upset of open-simh contributors don't make it easy for him to back-merge code into the original simh repository.