Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Josh @ Dreamland

136
General ENIGMA / Re: How to use your license choice as a threat
« on: October 20, 2014, 07:09:26 AM »
Oh? Do you actually believe that? Do you think that if I write something that attaches arbitrary bytecode to their runner, and sell it to let users create games in their engine, that they won't pursue litigation? Their EULA is full of clauses to prevent that. An obvious one is that you are forbidden from reverse-engineering their engine in any way. And if you break their EULA, you're up Shit Creek, because they reserve all their rights. In our case, you can assume a comfortable position up Shit Creek, or you can relicense as GPL/exempted GPL and hope for the best. The idea is that you'll be given as much respect as you gave ENIGMA when you have no legal claim.

Even without byte code hacks, go ahead and maintain your own Game Maker written in Game Maker, and see how long you last. Hint: it's been attempted in the past, back when execute_string was a thing. The staff brushed it off as a joke, with warning. Now try selling one.

137
General ENIGMA / Re: How to use your license choice as a threat
« on: October 20, 2014, 12:00:07 AM »
I'm not sure why you view a custom license as destructive to your goals, or to anything else, really. You argued at one point that it was less likely to be trusted, but I don't see how this differs from Yoyo's situation.

138
Proposals / Re: New Theme for LGM?
« on: October 19, 2014, 10:45:36 PM »
Robert's been working on getting supported themes bundled up into a release zipball. I don't see a reason not to include that set. He might already have it, actually.

139
General ENIGMA / Re: How to use your license choice as a threat
« on: October 19, 2014, 06:44:12 PM »
Why do you always assume the worst? This is possible, but there's no way of knowing what would happen if the engine were licensed with the MPLv2.0.
Have you ever written a minimax algorithm? You plan against the worst and hope for the best.

I'm sure the project developers would have a few things to say on the subject. Do you honestly think that the free software community wouldn't spread the news about such a thing? Besides, you and I both agree that an open source project can't be killed.
Right; they'd go straight to CNN and wouldn't stop spamming the media until they found justice. Right? We'd hear about these atrocities. After all, we're all intimately aware of all this planet's atrocities at all times, and  as a culture, we respond swiftly and decisively to each. That's why there are no problems with our economy.

If you're looking for an example of the exploitation of Wine by CodeWeavers, I doubt that you'll find it.
It seems you're right; my aggression in the general direction of WINE is misplaced. But you're missing the whole story if you believe that lack of contributing back was not a reason for the license change. Apparently this transgression belonged to undisclosed parties. Perhaps these are the two you're referring to...? I heard about all of this second-hand, so it's not terribly surprising I didn't have the details straight (especially with the developers being deliberately cryptic about it). Still, a proprietary version of ENIGMA offering primarily bug fixes is not something I'm interested in. The fact that some of Wine's own developers actively contribute to a codebase that does nothing but fix issues in their own software is pretty disturbing to me.

So, the LGPL was the correct license for Wine because Wine is very complex and it had enough developers to keep up with the proprietary features introduced in CrossOver?
Evidently not; from what you've shown me, it seems the people who know WINE best feel like maintaining a fixed-up proprietary version of their own software. It appears they're getting the best of both worlds: they're keeping the code to actually make their software do the thing it's supposed to in a private, proprietary repository, while the nitty-gritty behind it is freely available to the public. So now we have a junky sort of backend that gains improvements apparently as needed to make games run, which seems to be what the largest number of contributors care about. This is great for me, because I get to play Terraria on my Linux box. Meanwhile, the team maintains a layer over WINE that makes Microsoft Office work, but they keep that to themselves and sell it. So you've calmed the impossible pit of rage that erupted from me thinking it was two groups of people, but I'm still seeking to avoid this in ENIGMA. This is largely because (A) I enjoy my current job and (B) I wouldn't forward the money required to gamble on the success of ENIGMA by forming a company around it. It's also because I want ENIGMA to always be free, and I'd kind of like WINE to always be free, but I suppose you can wish in one hand and shit in the other....

At the end of the day, we're just not taking that path.

If a copyleft license that allows for linking to all types of code is appropriate for Wine, then why is it not appropriate for ENIGMA?
I've explained fifty times that I'm trying to avoid proprietary redistribution of our engine as an engine. Rusky just stated it pretty simply, too. I don't know how to state it any simpler.

These business practices may bother you, but it has little to do with ENIGMA and its copyleft license.
They are quite relevant to us; even more so than WINE. We are not using a copyleft license for the engine as observed by a typical user. We are giving them the option of dropping our license completely and using their own proprietary license. We want them to have the ability to reserve rights to their own code. But we don't want to give that freedom to people who redistribute ENIGMA as ENIGMA.

You can't make that decision on the game designer's behalf.
Right, but we can avoid the existence of a proprietary ENIGMA as a choice.

Similarly, if some entity chooses to distribute a modified version of ENIGMA, it is their choice to remain compatible with ENIGMA or not.
It is absolutely, positively not, and as long as I have anything to say in the matter, it never will be. They have NO right to reserve rights to redistributed versions of ENIGMA, now nor ever, so long as I own code in the project. It is MY right to tell them to piss off or use someone else's code if they want to redistribute a proprietary binary version of the ENIGMA Development Environment. Redistributed versions of ENIGMA that are not playable games must use our license, or plain GPL, period. This is the ENTIRE reason for my reservations in selecting a license. I will NEVER stand by while someone sells a CrossOver ENIGMA that is capable of, eg, compiling Iji. If you want to sell something, sell a patch that makes upstream ENIGMA capable of compiling Iji, and then point to upstream ENIGMA to tell your users where to get it. Because I swear to God, if you distribute them together, you'll be doing so under the GPL or the exempted version thereof. You will not hide from your users the capability of the free software that powers your shit. Anyone who buys from you will do so with FULL KNOWLEDGE of what they could have had elsewhere for free. End of discussion.

I'm beginning to question if you want anyone, game developer or otherwise, to be able to make money using ENIGMA.
I am hoping that the previous paragraph gives you a little more context into my actual feelings. Note that it does not concern distribution of games compiled against the ENIGMA engine. I'm extremely happy if a game developer can sell a closed-source game he or she created in ENIGMA. Especially if that user links back to ENIGMA to tell more people how to make their own games, but I would like to avoid requiring that. I'm no less happy if that user created his or her games after buying a proprietary extensions that can be used in ENIGMA, though I personally hope to avoid users wanting to do that. The operative point is that the user in question has free, unlimited access to the compiler and core game engine that produced that game module. It needs to be CRYSTAL CLEAR at all times that at the heart of the codebase you are using to create your games is a free and open-source project, to which you have unencumbered access.

My view on the matter may be extreme compared to the other contributors, but I have asked them on a number of occasions for their input. Robert has little to say, except that he wishes I could come to a decision more quickly. Harri is happy to jump the gun and go LGPL/MPL/WTFPL, but he hasn't indicated a strong opinion on the matter.

That said, I will echo Rezolyze's invitation to contact me, either privately or in the open, regarding your opinion on the licenses.

And let me again repeat the simplest mantra ever assigned to this operation: Forbid ENIGMA clones which forbid ENIGMA clones.

Another simple way to look at this? We use the same license as Yoyo, except our non-compliance alternative is not "you may not redistribute this because it is our code and we own it and copyright law forbids you from doing so," but instead, "you may use, modify, and distribute this under the terms of the GNU General Public License as published by the Free Software Foundation, version 3 or, at your option, any later version."

140
I'll point out that .scr is also a run-ready executable extension. Probably .bat, too.

141
General ENIGMA / Re: How to use your license choice as a threat
« on: October 15, 2014, 09:29:16 PM »
Quote
In all the history of software development, when has a commercial product ever caused the death of an open source project?
The beauty of a free software project is that it can't be killed. Having an ENIGMaker around will not kill ENIGMA, it will just attract people to use, support, and develop for ENIGMaker. Some of these changes and extensions will be open-source; some won't be. Some will be compatible with upstream ENIGMA; some won't be. I'd forward that most won't be, in both cases. By design. That's the problem.

If a company did manage to kill an open-source project, it would be the perfect crime. You'd never hear about it.

That said, if you are asking me for examples of what I'm trying to avoid, you're in luck. You've actually managed to mention one. I harbor immense disdain for CrossOver Office. They were initially so bad, they caused WINE team to change licenses. Before you argue that this serves your point ("oh look; one license change and SomeCorp is on its knees!"), I'll point out that this only happened because the WINE team did have a sizable developer base. WINE is sufficiently large and complex that contributions from its team outweighed the ability to hoard features. As I have said some fifty times already, ENIGMA will not be that lucky. Its current contributor base comprises about six people who know its internals roughly as well as any SomeCorp employee would after a couple weeks of perusing the code base.

Let me put a figure to this point: WINE is about 30 times the size of ENIGMA. Assuming that a professional programmer has perfect memory and constant-time indexing, it will take about 30 times the effort to get a grasp on WINE as it does ENIGMA. Breaking that incredibly stupid assumption, it's probably closer to a few hundred times as hard, optimistically.

The reason CrossOver so thoroughly disgusts me is because their new-feature-to-bugfix ratio was a high zero as opposed to a low one. Their entire purpose is (A) Make WINE do the thing it is supposed to do; (B) Sell copies of it closed-source for massive profit. Not everyone is this damn unscrupulous about it. Apple has given a lot back to FreeBSD, but at the end of the day, OS X is a proprietary operating system running just enough unique software to not be able to share arbitrary software with BSD. I'm not pretending that Apple hasn't contributed back; they certainly have. But at the end of the day, "Mac OS X Snow Leopard is built on a rock-solid, time-tested UNIX foundation," and I don't see one goddamn Adobe Photoshop download for FreeBSD. I don't see FreeBSD on my Logitech mouse, under the OS X logo. In fact, that sticker's missing from quite a bit of hardware.


Every game that compiles in ENIGMaker and not ENIGMA is a loss. It's a loss of a user, yes. If that user's any good, it's a loss of a user's user. "Whoa, am2r is made in a program called Game Maker! I should check that out!"

"Whoa, Iji compiles in a program called ENIGMaker!"

142
Proposals / Re: SWF file support?
« on: October 14, 2014, 06:56:16 AM »
Flash isn't likely to happen, but SVG is. I'm a vector evangelist. I do have other preoccupations, though.

143
General ENIGMA / Re: How to use your license choice as a threat
« on: October 13, 2014, 08:10:10 AM »
You forgot the only scenario I'm concerned about, wherein, rather than beginning "the slow and expensive process of rewriting ENIGMaker's engine from scratch," and rather than "ENIGMaker programmers [being] reassigned to another product or laid off," the ENIGMaker programmers are tasked with doing -exactly- what ENIGMA contributors would be doing—extending the engine further, and recoding only as necessary to fix more bugs.

We then have two teams developing two versions of ENIGMA. Upstream ENIGMA is poisonous to SomeCorp, yes, but you seem to be ignoring the fact that it's the same situation we're in now; it's also bad for ENIGMA users, who can no longer distribute their games closed-source. So sure, we can all pretend that we're hurting them more than we're hurting ourselves (feel free to make this argument; I'll happily use it to ignore the need for a license change in the first place), but in reality (outside of this wishful stargazing), SomeCorp wouldn't allow us to pretend that for very long.

Optimistically, it would take SomeCorp a good five minutes to realize that a GPL ENIGMA is a beautiful weakness about which to spread lies and uncertainty. All they need to do is tell their users that, "well, I wouldn't waste your time playing with the Enigma boys.. They'll take their ball and go home if you don't play along with their rules" (–Nocturne). They tell their users that the ENIGMA team is waiting to use its license against them. Meanwhile, they continue developing their code under a proprietary license shrouded in much more vile threats, which people will ignore for the same reasons that people are ignoring Yoyo's licensing issues (though I have to say, their EULA has improved quite a bit since its original inception—you might remember the huge fuss it generated). Being at the mercy of a corporation is much less threatening to people, simply because they're so damn used to it.

All the while, as the propaganda and smearing propagates, we're slowly losing. I'll point out again, if we go toe-to-toe from any point in ENIGMA's history with a paid, staffed company tasked with developing the same product, we will lose. Our contributors function for a number of personal reasons, none of which will compel them to commit enough to outdo a full-time programming team working off the same code. So while I appreciate your extremely optimistic scenarios, I don't see them happening. Except maybe the third one, which would be our only hope of doing them any harm. It still requires us to have enough bug fixes and general contributions to make a case, and the case would be ugly and hard to prove, but it'd at least be something, yes.

My personal preference is still a custom license. Your main argument against them is that users won't trust them. In my opinion, anyone who would trust Yoyo's hand-assembled, time-failed EULA over our GPL-based exemptions doesn't deserve to use the software. It seems that an effective use of time would be to reword the Yoyo EULA to use "GNU GPL" as a base instead of "ALL RIGHTS RESERVED." My doubt in non-legal people's abilities to do this is the only reason I'm trying to involve lawyers.

144
Tips, Tutorials, Examples / Re: One Script Pong
« on: October 13, 2014, 07:18:07 AM »
A changelog would be useful; what change prevents this from running in ENIGMA/Studio?

145
Off-Topic / Re: DX12 Is it all hype or is this the holy grail of DX!
« on: October 12, 2014, 06:46:01 PM »
Quote
we actually need to decide whether we try going for most of the newer stuff or stick with older

A huge chunk of the reason behind the graphics_systems folder is so you could do both. Any time you can't offer new technology in harmony with the old, but really want to offer it, put it in a breaking graphics system. I imagine those cases will be rare, though—I can't even think of one off-hand that wasn't settled with the GL1/GL3 divide.

146
The standard says no such thing, but a quick googling shows that POSIX decided to reserve them. I don't really fear the wrath of POSIX reservations, but you can name them how you choose. Try to find a consistent naming scheme—I liked _t, personally, and would still argue for it on the grounds that no standard header has business using type names such as window_t. That said, we can expose them to ENIGMA under whatever naming convention we like, so really I'll only debate you at the enigma_user level.

The method uses empty classes by given names as keys for template specialization—it's an old hack that doesn't show up a whole lot. Template specializations are use to look up type metadata, which is used to tell variant what it holds.

147
Programming Help / Re: Why do we use placement new?
« on: October 11, 2014, 08:48:25 AM »
The arrays problem in ENIGMA is that variables of type var, when accessed using [], must be encoded using (), because otherwise 2-D access using commas is not supported. Basically, my_var[1,2] goes in, my_var(1,2) comes out. ENIGMA's current type coercion is woefully inadequate, and as a consequence, this ends up happening for all arrays. So only var arrays work. A quick band-aid on this is to only make that replacement when a comma is detected outside of parentheses inside the brackets.

The lua_table implementation is fine. All it does is keep a dense portion and a sparse portion of an array of whatever object type you give it. It's pretty inefficient for one-dimensional access... I should do something about it.

148
General ENIGMA / Re: Lateral GM question
« on: October 08, 2014, 06:54:38 PM »
That's the plan, Ism. But make no mistake—ENIGMA is best to remain a DLL.

ENIGMA being compilable as a DLL is not a reason to not have a CLI. In general, command-line interfaces are not nearly as responsive, and we're dealing with software in which this latency counts. Originally, you pressed a syntax check button when you wanted to know if your GML was valid. Would you want a disk I/O over an entire directory while we read in script and function names, just so we can report to you that this one code you've changed two lines of is valid? Maybe you do, I don't know. But do you want us implementing continual syntax checking that way? You'd have to be crazy. Even if we cached all the engine data to a file, you wouldn't want us reading that behemoth every time you stopped typing for a second.

Moreover, what if LateralGM wants to invoke the compiler for more accurate code completion? For formatting? For automatic indentation? If ENIGMA were confined to a separate executable, even with pipes, I/O overhead would be insufferable.

Anyway. That said, yes; EGM and GMX eliminate the need to ever have all resource data loaded in memory. This means that the reasons for having LGM pass ENIGMA resource data are dying or dead. THAT SAID, the ability for the engine to work out of EGM files needs to come first. I will not myself implement nor encourage any other individual to implement logic for reading an EGM and appending it to an executable at this phase. My recommendation is for the ENIGMA plugin to keep the game saved in /tmp/lateralgm/<datetime>/game.egm/* as an EGM directory (presently not supported for some reason?) and for the game to load resources out of that directly. Writing resources to the executable is an archaic practice that should only be offered as a final redistributable build option.

149
Programming Help / Re: Why do we use placement new?
« on: October 08, 2014, 06:27:15 PM »
When I wrote var, I had the sense to want to keep the matrix kernel modular, but lacked the sense to do it right. It uses placement new so that the main var class doesn't have to know anything about the type it's storing, which is itself just a pointer. You could easily refactor it so that the lua_table just works with the values data pointer directly, instead of pretending to own it. At this point, I don't even really care if you want to just move the lua_table code into var. If you want to do that refactoring, feel free—it might even speed up var arithmetic because the compiler will be more confident in its optimizations.

150
Didn't notice any replies. I must have loaded the page before you posted it, then forgotten to refresh. I could move it over, but you've already posted this, now. :P