Rezolyze
|
|
Posted on: October 10, 2014, 12:07:19 pm |
|
|
Joined: Jun 2013
Posts: 53
|
This community is discussing a license change for ENIGMA's engine code. All of the most popular license choices are listed and compared here. Something that all of those licenses (excluding the GPL) have in common is: you could submit changes to the engine code under a different license than the chosen license. For example, if the engine code were licensed under the MPLv2.0, I could make changes to the code and submit my changes under the GPLv3. If my changes were merged with the ENIGMA project, the latest version of the engine code would fall under the terms of the GPLv3. Normally this would be undesirable, but in the following hypothetical situation, it could prove useful. A worry among some ENIGMA developers is: a commercial version of ENIGMA that fails to contribute code back to the project. Let's explore this possibility for a moment under the worst possible conditions I can imagine. HYPOTHETICAL SCENARIO vvvvvvvvvvvvvvvvvvvvvv ENGIMA's engine code has been relicensed under the MPLv2.0. Game developers can now distribute their games made with ENIGMA without sharing their game code. ENIGMA's engine is stable, relatively bug free and has almost complete feature parity with GameMaker. ENIGMA's popularity is at an all-time high and everything is going well. This project and its success catches the attention of Some Corp, Inc. Eventually, they release a version of ENIGMA called ENIGMaker. ENIGMaker uses the compiler/parser (GPLv3) and the engine (MPLv2.0) from ENIGMA, but the IDE is proprietary. ENIGMaker includes proprietary features like: Android and IOS compilation, DirectX 12 support and Windows 10 touch input. Also included is a graphical fix for screen tearing that occurs in Linux and a fix for an intermittent popping sound during audio playback in Windows. Some Corp's fixes and features are implemented through proprietary code linked to the engine code. All the changes they've made to ENIGMA's compiler/parser and engine are shared with ENIGMA under the terms of the code's respective licenses. They are not sharing their proprietary fixes and features. What they've done with ENIGMA and it's code is all perfectly legal. (Here's where your license choice can be used as a threat.)As one of ENIGMA's developers, you're not happy with Some Corp's unwillingness to share their fixes. You and a few other developers decide to submit all of your future changes to ENGIMA's engine code under the GPLv3 instead of the MPLv2.0. Such a practice is allowed under the MPLv2.0 and all of the other proposed licenses. Anyone using the latest version of ENIGMA's engine will be required to submit to the terms of the GPLv3 or remove/rewrite your submitted GPL code. The more GPL code submitted by developers and the longer this continues, the more effective this tactic will be. You send an email to Some Corp and post a topic on the ENIGMA forums stating your intentions: Until Some Corp contributes to the ENIGMA project by sharing any and all present and future bug fixes under the appropriate copyleft license, I and other like-minded developers will continue submitting our changes to ENIGMA's engine code under the GPLv3. We realize that this will prevent game developers from using the latest version of ENIGMA with their proprietary projects, but it is necessary to stop and further prevent the uncooperative practices of Some Corp. We are sorry for the inconvenience and we hope that Some Corp will resolve this issue quickly by doing the right thing. Some Corp must stop profiting from the hard work of others without giving back!
Sincerely, The ENIGMA Developers for Software Freedom At this point, Some Corp will be in an awkward situation with limited options: - Some Corp could ignore the ENIGMA developers' demands. They could stay with the latest version of ENIGMA's engine code that was exclusively MPLv2.0. It would fall on Some Corp to update ENIGMaker's engine code on their own. In order to keep their updates proprietary, they could continue linking the engine code to their proprietary code. In the background, they could begin the slow and expensive process of rewriting ENIGMaker's engine from scratch.
- Some Corp could ignore the ENIGMA developers' demands. They could stop working on ENIGMaker, continue selling their latest version of ENIGMaker and try to wait out the situation. In the mean time, Some Corp's ENIGMaker programmers would be reassigned to another product or laid off. As ENIGMaker becomes older without an update it will be less useful as a game development tool and a less profitable product.
- Some Corp could ignore the ENIGMA developers' demands. They could continue using the latest version of ENIGMA's engine code with its changes under the GPLv3. It would be somewhat difficult for ENIGMA's developers to prove that they are violating the GPLv3, but Some Corp could decide that it's worth the potential legal battle in the long run. However, copyright law would be on the ENIGMA developers' side.
- Some Corp could give in to the ENIGMA developers' demands. They could agree to share any and all future bug fixes to ENIGMA's engine under the MPLv2.0. In exchange, all ENIGMA developers that submitted their changes to the engine under the GPLv3, would relicense those changes under the MPLv2.0.
^^^^^^^^^^^^^^^^^ HYPOTHETICAL SCENARIO The fourth option seems most likely to me because it's beneficial for everyone involved. A corporation's goal is to make money in the easiest and cheapest way possible. Options one through three would cost Some Corp both time and money. Option four is the only option that saves them time and money. Some Corp continues to get its updated engine code from the ENIGMA project. The ENIGMA project gets bug fixes for the engine from Some Corp. Game developers get the choice of a free open source project or a commercial product with support and extra features. Everybody wins with option four. I consider this entire scenario to be highly unlikely. If some person or corporation were to begin selling an enhanced version of ENIGMA, they would likely realize that cooperation with ENIGMA's developers is in their best interest. Such license change tactics by ENIGMA's developers would be unnecessary, but the option would be there if needed. Under the MPLv2.0 and other similar licenses, sharing code isn't mandatory due to the linking exception, but that doesn't matter. Sharing bug fixes makes the most sense from an ethical and financial perspective.
|
|
« Last Edit: October 10, 2014, 09:25:36 pm by Rezolyze »
|
Logged
|
|
|
|
edsquare
|
|
Reply #1 Posted on: October 10, 2014, 03:16:38 pm |
|
|
Location: The throne of ringworld Joined: Apr 2014
Posts: 402
|
Any changes made to any code covered by the mpl v2 license fall under the same license see the FAQ please! https://www.mozilla.org/MPL/2.0/FAQ.html Q9: I want to distribute (outside my organization) MPL-licensed source code that I have modified. What do I have to do?
To see the complete set of requirements, read the license. However, generally:
You must inform the recipients that the source code is made available to them under the terms of the MPL (Section 3.1), including any Modifications (as defined in Section 1.10) that you have created.
You must make the grants described in Section 2 of the license.
You must respect the restrictions on removing or altering notices in the source code (Section 3.4).
Q10: I want to distribute (outside my organization) an executable program based on MPL-licensed source code that I have modified. What do I have to do?
You must make available the MPL-licensed portions of the source code as described in the previous question, and inform the recipients how they can obtain such source code (Section 3.2).
Q11: How 'viral' is the MPL? If I use MPL-licensed code in my proprietary application, will I have to give all the source code away?
No. The license requires that Modifications (as defined in Section 1.10 of the license) must be licensed under the MPL and made available to anyone to whom you distribute the Source Code. However, new files containing no MPL-licensed code are not Modifications, and therefore do not need to be distributed under the terms of the MPL, even if you create a Larger Work (as defined in Section 1.7) by using, compiling, or distributing the non-MPL files together with MPL-licensed files. This allows, for example, programs using MPL-licensed code to be statically linked to and distributed as part of a larger proprietary piece of software, which would not generally be possible under the terms of stronger copyleft licenses.
|
|
|
Logged
|
A child of five would understand this. Send someone to fetch a child of five. Groucho Marx
|
|
|
Rezolyze
|
|
Reply #2 Posted on: October 10, 2014, 04:28:12 pm |
|
|
Joined: Jun 2013
Posts: 53
|
edsquare: You really need to stop telling me to read the MPL FAQ. I've read it many times. I'm guessing you haven't read all the references in the License Comparison Table, so here's a quote from one of those references.When you receive work under MPL 2.0, you may make a “Larger Work” that combines that work with work under those GNU licenses. When you do, section 3.3 gives you permission to distribute the MPL-covered work under the terms of the same GNU licenses, with one condition: you must make sure that the files that were originally under the MPL are still available under the MPL's terms as well. In other words, when you make a combination this way, the files that were originally under the MPL will be dual licensed under the MPL and the GNU license(s). The end result is that the Larger Work, as a whole, will be covered under the GNU license(s). People who receive that combination from you will have the option to use any files that were originally covered by the MPL under that license's terms, or distribute the Larger Work in whole or in part under the GNU licenses' terms with no further restrictions. So in the case of the MPLv2.0, it's technically a dual-licensing of both the MPLv2.0 and the GPLv3, but it amounts to the same thing. I was being general in my wording so as to include the other possible license choices. Please stop referencing just the MPL FAQ and consult other sources before making your argument.
|
|
|
Logged
|
|
|
|
edsquare
|
|
Reply #3 Posted on: October 10, 2014, 05:37:53 pm |
|
|
Location: The throne of ringworld Joined: Apr 2014
Posts: 402
|
edsquare: You really need to stop telling me to read the MPL FAQ. I've read it many times. I'm guessing you haven't read all the references in the License Comparison Table, so here's a quote from one of those references.
When you receive work under MPL 2.0, you may make a “Larger Work” that combines that work with work under those GNU licenses. When you do, section 3.3 gives you permission to distribute the MPL-covered work under the terms of the same GNU licenses, with one condition: you must make sure that the files that were originally under the MPL are still available under the MPL's terms as well. In other words, when you make a combination this way, the files that were originally under the MPL will be dual licensed under the MPL and the GNU license(s). The end result is that the Larger Work, as a whole, will be covered under the GNU license(s). People who receive that combination from you will have the option to use any files that were originally covered by the MPL under that license's terms, or distribute the Larger Work in whole or in part under the GNU licenses' terms with no further restrictions. So in the case of the MPLv2.0, it's technically a dual-licensing of both the MPLv2.0 and the GPLv3, but it amounts to the same thing. I was being general in my wording so as to include the other possible license choices. Please stop referencing just the MPL FAQ and consult other sources before making your argument.
And any change you happen to make to those files is also covered under the MPL, as with your post with the comparision table, your wording makes it seem as if can take any MPLed code modify it link it with my larger work and the sell it under a closed licnse and never disclose the changes I made to the MPLed code I'm using.
|
|
|
Logged
|
A child of five would understand this. Send someone to fetch a child of five. Groucho Marx
|
|
|
|
Rezolyze
|
|
Reply #5 Posted on: October 10, 2014, 07:01:14 pm |
|
|
Joined: Jun 2013
Posts: 53
|
edsquare: In the case of a file that is dual licensed under the MPL and the GPL, the terms of the GPL tend to be more important because it is more restrictive than the MPL. If you have a specific suggestion about rewording the topic post, I'd like to read it. My concern is that any further explanation would be confusing. With licensing being so complicated, I wanted to keep it as simple as possible. And any change you happen to make to those files is also covered under the MPL, as with your post with the comparision table, your wording makes it seem as if can take any MPLed code modify it link it with my larger work and the sell it under a closed licnse and never disclose the changes I made to the MPLed code I'm using.
As usual it comes down to linking. MPL code can't be closed, it can only be opened even more by dual licensing under a GNU license. However, linking proprietary code to MPL code can work around that. If you can think of a better way to express that in a table format, please reply in the License Comparison Table thread. The table is meant as a starting point and not an end point. It contains a lot of references so that you may continue reading about each license for yourself. Darkstar2: Greed can cause odd actions in people. Not all of ENIGMA's developers might be so noble in the future. I agree that it's better to protect both ENIGMA'S users and developers with a proper license. The purpose of my scenario was to illustrate that forced sharing of bug fixes, under the GPLv3 is not necessary. Simply encouraging sharing is enough because everyone benefits. Perhaps my point got lost along the way.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #6 Posted on: October 13, 2014, 08:10:10 am |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
Rezolyze
|
|
Reply #7 Posted on: October 13, 2014, 04:45:33 pm |
|
|
Joined: Jun 2013
Posts: 53
|
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.
I didn't forget the scenario you're concerned about. It's included with first option available to Some Corp, but the wording is different: It would fall on Some Corp to update ENIGMaker's engine code on their own. In order to keep their updates proprietary, they could continue linking the engine code to their proprietary code. In the background, they could begin the slow and expensive process of rewriting ENIGMaker's engine from scratch.
I'm saying that Some Corp would fork the engine code and continue programming proprietary fixes and features. Skip the proprietary engine part and it's the same situation. With Some Corp's release of ENIGMaker, you would already "have two teams developing two versions of ENIGMA," even before the ultimatum. 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.
The situation would be similar, but not the same. For ENIGMA users wishing to distribute their closed-source games, you would point them to the last version of ENIGMA's engine that was exclusively MPLv2.0. Legal distribution of GPL incompatible games has never been an option with ENIGMA. 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.
Both the ENIGMA project and Some Corp would be harmed by this license change tactic. That's one of the reasons I don't personally agree with it, but I was trying to craft a worst-case scenario. However, the monetary damage done to Some Corp could be considerable if ENIGMaker were their flagship product. They would need to spend more time and money to keep their product up to date. There's also the potential lose of profits and users from the bad press: "Some Corp Exploits Open Source Game Creation Project." The potential damage done to ENIGMA's users and the potential damage done to Some Corp is difficult to estimate in any scenario, hypothetical or otherwise. 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.
That's one of the arguments being made now against ENIGMA. Are you suggesting that the ENIGMA's engine code license shouldn't be GPL compatible so as to avoid the spread of lies and uncertainty? Maybe so many game engines are MIT and BSD licensed to avoid copyleft propaganda. If Some Corp did tell their users to avoid ENIGMA, they'd be "preaching to the choir." Those people already chose ENIGMaker over ENIGMA. On the other hand, ENIGMA's community could (and has) spread the same uncertainty about any number of End-user license agreements from companies selling game making tools. 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.
Anyone can spread lies and propaganda about anyone or anything on the internet. What will ENIGMA lose? Profits? Popularity? Developers? What? During all of our discussions on licensing, you have failed to name one instance where a commercial product has killed an open source project. I'm just looking for one example. 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.
Why would ENIGMA's contributors need to "outdo a full-time programming team?" Commercial products usually "outdo" the open source projects they're based on in some way. If they didn't, then no one would have a reason to buy the commercial product. That doesn't mean that the open source project is inferior or worthless. Two good examples are CrossOver based on Wine and Unity based on Mono. 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.
I would never think to call my scenario "extremely optimistic." I thought it was quite pessimistic and petty on both sides until you get to option four. However, I agree that this scenario with it's various outcomes is unlikely to occur. I say as much in the last paragraph. I'm guessing that you don't agree with my conclusion that forced sharing of bug fixes is unnecessary. 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.
Here's my main argument against a custom license (with your requirements): A custom license has a greater probability that it will fail to protect the work of both ENIGMA's users and developers than an existing and well-reviewed license. If we're talking about a custom license exception to the GPL, then everyone's work would fall under the GPL if the exception is deemed unenforceable or contra proferentem. Licensing-wise, this project would be right back where it started with ENIGMA's users having to open source their code. Will your custom license go through a two year draft and review process like the GPL or the MPL? Which lawyers are you involving and what are their qualifications? Who will have final say over the terms of this custom license? Trust in a license is important, but the protection of people's work is closer to the issue than trust. I want to be very clear about this: I don't approve of any entity using a license as an excuse to hoard bug fixes from a free software project. Nor do I agree with ever using the license change tactic I outlined in the topic post. The hypothetical scenario I described was "under the worst possible conditions I [could] imagine." I thought I crafted a worst-case scenario, but your hatred and prejudices towards corporations (or maybe just YoYo Games?) seem to paint an even darker possibility. In all of our licensing discussions, you continuously cast corporations as villainous threats to free software projects. In all the history of software development, when has a commercial product ever caused the death of an open source project? If you can't answer that, then you should reexamine your need for a custom license with even more restrictions than the GPL.
|
|
« Last Edit: October 13, 2014, 04:49:33 pm by Rezolyze »
|
Logged
|
|
|
|
onpon
|
|
Reply #8 Posted on: October 13, 2014, 06:53:26 pm |
|
|
Joined: Feb 2010
Posts: 102
|
If we're talking about a custom license exception to the GPL, then everyone's work would fall under the GPL if the exception is deemed unenforceable or contra proferentem.
The GNU GPL isn't a contract. It's a broad grant of permissions to do things that are not allowed by default under copyright law. To "enforce" the GNU GPL is to sue someone for copyright infringement when they do something forbidden by copyright by default which the GNU GPL did not permit. An additional permission added to the GNU GPLv3 could end up having absolutely no effect, or less permissiveness than intended, but I'd worry more about it going in the opposite direction and being too permissive. when has a commercial product ever caused the death of an open source project?
I don't consider that an interesting question. The interesting question is, "when has permissively licensed code ever been made into proprietary software, with changes that were never given back?" The answer to that is... all the time. The first example I'm aware of is the X Window System; proprietary versions of X were incorporated into several Unix systems. Corporations are, by definition, amoral entities. They will not give anything back to a libre software program unless they deem it to be advantageous to their singular goal of profiting more, or are compelled to.
|
|
« Last Edit: October 13, 2014, 07:09:16 pm by onpon »
|
Logged
|
|
|
|
Rezolyze
|
|
Reply #9 Posted on: October 13, 2014, 09:31:53 pm |
|
|
Joined: Jun 2013
Posts: 53
|
The GNU GPL isn't a contract. It's a broad grant of permissions to do things that are not allowed by default under copyright law. To "enforce" the GNU GPL is to sue someone for copyright infringement when they do something forbidden by copyright by default which the GNU GPL did not permit.
The GPL does grant you permissions that wouldn't be allowed under copyright law, but it also places restrictions on the permissions it grants. That's why other licenses with less restrictions are called permissive licenses. To infer that the GPL only grants permissions is misleading. The terms of the GPL don't allow linking proprietary code with GPL code. This is a restriction that we are trying to avoid for game developers that use ENIGMA. The two rough drafts of custom license exceptions to the GPLv3, proposed by Josh, gave various permissions, with restrictions, regarding the usage of ENGIMA's engine code. The basic premise was: you can link proprietary code to ENIGMA's engine code, but only for the purposes of creating a game. If this custom exception were deemed invalid or the terms unenforceable by a court of law, all the terms of the GPLv3 would apply to ENIGMA's engine code. Anyone having used ENIGMA linked with their proprietary code would be in violation of the GPLv3. An additional permission added to the GNU GPLv3 could end up having absolutely no effect, or less permissiveness than intended, but I'd worry more about it going in the opposite direction and being too permissive.
These custom license exceptions were not just "an additional permission." There would be an effect if one of these custom license exceptions became invalid, but there may or may not be a legal action as a result. If the terms of the GPL were violated in regards to ENIGMA's engine code, any one of the copyright holders would have the right to take legal action. when has a commercial product ever caused the death of an open source project?
I don't consider that an interesting question.
This question wasn't directed at you specifically. I'm asking Josh because he has claimed, multiple times, that ENIGMA would die if it had to compete with a commercial version of itself. I would like a real-life example of such a thing occurring. Frankly, I don't care if you find this question interesting. The interesting question is, "when has permissively licensed code ever been made into proprietary software, with changes that were never given back?" The answer to that is... all the time. The first example I'm aware of is the X Window System; proprietary versions of X were incorporated into several Unix systems.
I would say that an uninteresting question is one that you both ask and answer yourself. Corporations are, by definition, amoral entities. They will not give anything back to a libre software program unless they deem it to be advantageous to their singular goal of profiting more, or are compelled to.
A corporation sharing bug fixes with ENIGMA would be "advantageous" to them because it would give them a say in the development direction of ENIGMA. As copyright holders of the code they submit, they would "get a vote." This corporation would not be expending as much time and money developing and bug testing ENIGMA's engine code. A large part of that process would be done by ENIGMA's existing developers and users. The less money and time spent developing and testing by this corporation, the more they profit. Sharing bug fixes with ENIGMA works towards their "goal of profiting." I'd call that compelling and that's what I was trying to convey in my topic post.
|
|
|
Logged
|
|
|
|
Josh @ Dreamland
|
|
Reply #10 Posted on: October 15, 2014, 09:29:16 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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!"
|
|
« Last Edit: October 15, 2014, 09:33:38 pm by Josh @ Dreamland »
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
Rezolyze
|
|
Reply #12 Posted on: October 19, 2014, 04:41:30 am |
|
|
Joined: Jun 2013
Posts: 53
|
The beauty of a free software project is that it can't be killed. Having an ENIGMaker around will not kill ENIGMA,
At least on this point we agree. 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.
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. If a company did manage to kill an open-source project, it would be the perfect crime. You'd never hear about it.
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. 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.
I mentioned Wine and CrossOver, because it's an example that illustrates my point. Collaboration with a company would be beneficial to both the company and the open source project. The Wine team did not change licenses because of CrossOver Office. Please see Wine's History from the WineHQ Wiki for more information. The highlights are that Wine had a BSD-style license at first, but the license was incompatible with the GPL. In 2000, the license was changed to the X11 license. By 2002, the license was changed to the LGPLv2.1 which the project still uses today. In 2002, Jeremy White created a post on the WineHQ mailing list. Jeremy White is the CEO of CodeWeavers, the makers of CrossOver. If CodeWeavers' exploitation of Wine was the cause for the switch to the LGPL, then why would the CEO support this license change? If CrossOver is such a deplorable piece of software, then why does the lead developer of Wine, Alexandre Julliard, work for CodeWeavers? Why would so many Wine developers work for CodeWeavers at all? If you're looking for an example of the exploitation of Wine by CodeWeavers, I doubt that you'll find it. However, I am aware of such exploitation by TransGaming with their Cedega and Cider software. They created their proprietary products based on Wine when it was under the permissive X11 license. Although they did submit code back to the project, it was under a license incompatible with Wine's license. Wine switched to the LGPLv2.1, a copyleft license, to stop and prevent such exploitation. 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? 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.
This is an argument that you've made on multiple occasions. 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? This is a ludicrous argument. The contributions to Wine haven't kept up with CrossOver's features. That's the reason that CodeWeavers has been able to turn a profit on their software. CrossOver made installation and configuration of Wine easier for the average computer user. Their proprietary features focused on an easy-to-use GUI and compatibility fixes for the more popular Windows applications and games. This is what CodeWeavers is selling with it's CrossOver software and if it wasn't "hoard[ing]" these features, it wouldn't have a product to sell. 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.
You're welcome to your opinion on the quality of CrossOver and the general motives of the people at CodeWeavers, but I've seen no evidence to support these statements. CodeWeavers is giving back to Wine in the form of bug fixes and corporate sponsored development. I've read nothing to suggest that CodeWeavers is violating the terms of the LGPLv2.1. These are people trying to make a living by increasing the usability and functionality of an open source project. Just because a company's goal is to make a profit, that doesn't meant that it's "unscrupulous." Also, CrossOver is not the only third party software making use of the Wine code base. 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.
This argument is comparing apples and oranges (no pun intended). FreeBSD is under a permissive license. The license allows for proprietary and closed-source changes to the code. I can only assume that this was the intention of the developers of FreeBSD. They didn't want to restrict what someone could create with their code; they only wanted credit for their own work. These business practices may bother you, but it has little to do with ENIGMA and its copyleft license. 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!"
It is every game designer's right to choose which tools they use to create their game. It's up to the designer to choose which tool works best for them. You can't make that decision on the game designer's behalf. Similarly, if some entity chooses to distribute a modified version of ENIGMA, it is their choice to remain compatible with ENIGMA or not. There may be a reasonable explanation for any incompatibility, but without knowing the circumstances, it's unreasonable to judge. I'm beginning to question if you want anyone, game developer or otherwise, to be able to make money using ENIGMA. It appears that you're bothered by commercial use of any open source code. You are the lead developer and creator of ENIGMA, but when you licensed the code under the GPLv3 and began accepting contributions, the project ceased to be entirely yours. It became the collected work of everyone that ever contributed code to ENIGMA. Your opinion on the licensing of ENIGMA's engine does matter and to some people it matters the most, but the opinions of all the other code contributors matter as well. Some of ENIGMA's developers have already stated that they don't want a custom license for the engine code, but you continue pursuing that goal. Why not seek a compromise that everyone can live with? I would suggest to everyone that has contributed code to ENIGMA: Contact Josh in private and explain your choice of license. It seems that discussion on these forums has accomplished very little; perhaps a private discussion among the copyright holders would be more productive.
|
|
« Last Edit: October 19, 2014, 04:48:04 am by Rezolyze »
|
Logged
|
|
|
|
|
Josh @ Dreamland
|
|
Reply #14 Posted on: October 19, 2014, 06:44:12 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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."
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|