Open Quintus opened 8 years ago
Bugsbane
commented
8 years ago Personally I prefer GPL than MIT/BSD etc, but I'm not about to turn it into the holy war many would. I'm fine with the creative commons license chosen for art assets, and while I would prefer GPL, I consider the license the code is under more important to the people writing the code. As long as it remains FLOSS, I can handle it.
datahead8888
commented
8 years ago As far as I understand it, code licensed under MIT/BSD can be relicensed under the GPL. Quintus can probably speak to the fine points of the licenses better, however. At any rate, I think these licenses generally meet our primary needs. If MIT/BSD are not found sufficient, some sort of dual licensing might be another option.
Basically, I think someone who contributes a reasonable amount of code should be able to use this in another project he or she does, even if it is a commercial one that is not made available for free. They can already do this if they code the entire system by themselves then give it to TSC. The issue that comes up is if someone else contributes a little bit of code to this subsystem intermittently. If this small snippet of code falls under the GPL, it makes the code of questionable use for the original programmer in other projects. The second project pretty much has to be made available free of charge, which can create a number of challenges, especially in games.
This argument extends beyond just subsystems like lighting. The same question comes up for extensive contributions to other, interdependent systems.
Bugsbane
commented
8 years ago I think someone who contributes a reasonable amount of code should be able to use this in another project he or she does
The person who writes a specific piece of code can always use their own code anywhere they wish. None of the open source licenses, either copyleft or permissive are exclusive or transfer ownership. The license choice is really just about whether other people using the code need to contribute modifications back or not.
datahead8888
commented
8 years ago The person who writes a specific piece of code can always use their own code anywhere they wish.
This is only true until someone else starts making changes (even very small ones) to it. Unless the other contributor explicitly grants permission, the resulting code then becomes GPL only code. The only option at that point is to branch the code into two different lines, one under the GNU license and the other under a different license.
datahead8888
commented
8 years ago Furthermore, since most code ends up becoming collaborative in some way, the majority of code thus "effectively" falls under the GNU license with this model. It is technically possible to strip out snippets that an individual contributor wrote, but at that point it is not worth the effort. Such code is not really useful in non GNU projects at all. If a project becomes GNU licensed, it must be made available for free, and people will not pay for such a product (excluding distribution costs and support, which are harder to charge for in games generally).
Quintus
commented
8 years ago As should be known, I’m a fan of the GPL for enduser programs. I can see datahead’s point, but to be honest, I think the whole point of the GPL is to guarantee code stays free for access. datahead wants to lift the GPL clause as a "reward" for contributions to the game if I understand him correctly, which I find difficult to bring together with the ethical approach of the GPL.
However, I’m also a fan of clear and easy legal situations. We could set up the new code in such a way that contributions require a CLA (Contributor License Agreement). That can easily be connected with our planned new project infrastructure, where it’s just an additional checkbox on registration. The CLA would grant the TSC team a right to use, modify, sublicense, etc. — of course not an exclusive right, the contributor may use his code everywhere he wants still. But such an approach would set the TSC team into full licensing ability, i.e. it remains the sole holder of a use right on the entire codebase. We can decide at any time what license is appropriate. If for example some cool new license comes out that is much better than the GPL, we could switch to that license without having to go after all the contributors. And, as far as datahead is concerned, it would be possible to grant someone a license exception by team decision. The person who wants the exception still has to convince the majority of the team, otherwise he won’t get one. That being said, I think I would vote against such exceptions because I think it is against the spirit of the GPL. If the TSC project received some money in exchange for an exception, I might change my mind, because that benefits the project in another way.
Apart from the possibility of an exception to the license, which I’m somewhat reluctant to as I outlined above, there’d be the following advantages:
Finally, since we already have a good amount of contributors, I think a CLA is not going to heavily slow down our development progress. I wouldn’t suggest it if only two people were involved, but as of now I think it is a possibility, and a rewrite is a good point in time to suggest it.
Valete, Quintus
refi64
commented
8 years ago Has anyone here considered the MPL? Although it requires modifications to the code to be shared, MPL-licensed code can be statically linked to proprietary code, something neither the GPL nor LGPL support. It's personally my favorite OSS license, since it strikes that nice area between supporting free software and supporting proprietary usage.
Quintus
commented
8 years ago Has anyone here considered the MPL?
I have now read up on this license, and it follows an interesting concept known as "file-based copyleft". This means that the licensee has to make available
a) The original source code b) His modifications of the source code
under the terms of the MPL (§3.1 MPL) , unless he manages to do his modifications in such a way, that they are not a modification in the sense of the definition in §1.10 MPL. That definition of a modification is probably the most clear I have ever seen. It states that a modification is only given if you modify a pre-existing MPL-licensed sourcefile (by insertions or deletions; §1.10(a)) or insert MPL-licensed code into a new sourcefile (§1.10(b)).
That is, if I base a work on an MPL-licensed program and do all of my modifications in new source code files, I am not subject to the copyleft clause in §3.1 MPL. I still have to provide original MPL-licensed portions, though.
This is an interesting approach, but I see a provability problem. Without access to the potentially infringing code I cannot check easily if the license was violated, because from the final executable I cannot determine if the code was in multiple files. Following the most German courts’ opinions (cf. OLG Nuremberg and Federal Court of Justice), §101a UrhG (German Law on Intellectual Property) grants a right to request inspection of sourcecode if an infringement is "sufficiently likely". It is on the licensor to prove that probability.
For the GPL stuff is more easily to prove if I only have the executable. If I find symbols from my source code in the executable, this is a very strong indicator that it includes my source code. That is enough for the GPL to take effect (under regular circumstances, see below). Without having to request inspection into the sourcecode of the infringer, I can prove he infringes my copyright.
When we talk about the GPL, I suggest to exclude the old GPLv2 from the discussion The license is old and designed towards the specifics of the US law. After all, TSC currently is under the terms of the GPLv3 anyway. The GPLv3’s copyleft effect (§5(c) GPL) is effective as soon as you have a "work based on" the program, which is, given the definition in §0(4)(2) GPL, basically always, unless you are under a copyright exemption (the most widely known is probably the U.S. "fair use" right). This makes a violation easy to prove, as outlined above.
However, a less widely known fact is that §7(1) GPL allows the licensor to add "additional permissions" to the license that can even grant exceptions from the license. There is practically no limitation on these; they can be used to lift the copyleft effect under specific conditions. For example, the GNU C Compiler (GCC) is licensed under GPLv3. During compilation, it includes some of its own sourcecode into the executable compiled. Under normal conditions this would "infect" the executable with GCC’s GPLv3 license, but the GCC team has added a §7(1) "additional permission" to their license. You may read it online here if you are interested. This "additional permission" exempts those parts of GCC that are included during compilation into the final executable from the copyleft effect.
Similaryly, we could use a §7(1) "additional permission" if we really needed to. However, I think such a general and broad exception is okay for a project used as widely as GCC, but I think for us exceptions on an individual base are much more useful. Those can, as I explained in an earlier post, most easily be done if we request a CLA from conributors as then we can as a team decide to whom grant an exception and to whom not.
The GPL has an ethical approach to freeing software for the user. For libraries, I usually decide on a case-by-case base how "free" I want them to be, but for and end-user program I have the opinion that the program should be available to the user in sourcecode if he wants to, to learn from it and to inspect it so he can be sure it won’t phone home behind his back. Programs that don’t allow this take the user as "hostage" (quote from Stallman). I don’t want my programs to help hostaging people, neither in pure form, nor in modified form. That’s why I advocate the use of the GPL(v3) in all its strictness.
While the above is my base point, I am not inherently against exceptions. The probably most obvious exception is if the person who wants an exception from the license pays for this. I view this as a comprehension for diminishing freedom. (sidenote: Until today nobody has ever payed me for a GPL exception)
Another possible reason for an exception is that I am guaranteed the program is not going to phone home, collect data about its users, restrict their hardware in its use, etc. I’d decide on a case-by-case base if I believe such a guarantee.
I repeat my above suggestion, probably in a more terse form. License as GPLv3, request a CLA from contributors, and have the team decide on an individual case-by-case base if a license exception is to be granted. My vote will usually be against such exceptions, but if the majority of the team things otherwise, I won’t stand in the way, as long as the base condition is freedom for the software’s users.
Valete, Quintus
Bugsbane
commented
8 years ago I agree with Quintus on all points in the above comment.
Quintus
commented
8 years ago A side note here. In order to achieve full legal disposal of the licensing, we need to rewrite the game without copying any of FluXy’s (or a previous, now unreachable coder’s) source code. Alternatively, we could start with some code copied, but also directly request CLAs, and then slowly remove the source code copied from FluXy et al. Once all of those pieces are gone, we have full disposal then as well.
Valete, Quintus
datahead8888
commented
8 years ago Sorry for the slow response. I have been very busy.
The MPL license is interesting, though I would still have the same concerns about being able to reuse code in files one had spent a significant amount of time helping develop.
datahead wants to lift the GPL clause as a "reward" for contributions to the game
No, it would not be a reward so much as a right to reuse a body of code that you had codeveloped in proprietary projects.
If the TSC project received some money in exchange for an exception, I might change my mind, because that benefits the project in another way.
In all honesty, I don't think someone should have to pay to reuse a body of code he helped develop, especially if he wrote a significant part of it.
I for one will probably spend a lot more time developing the new TSC codebase if I know I can reuse the resulting code in other projects. Otherwise I'm effectively restricted in reusing the code in subsequent projects, which would end up playing into my time decisions. The new TSC codebase probably will take 5-10 years to develop for a good feature set.
Currently the situation is not entirely clear, which is why we demand a CC-BY license for assets as that does not conflict with the GPL.
It certainly is contradictory to try to enforce copyleft on the code but not on image assets. Of course, I'm not a fan of copyleft in either case :)
A side note here. In order to achieve full legal disposal of the licensing, we need to rewrite the game without copying any of FluXy’s (or a previous, now unreachable coder’s) source code.
This is very true. We could try to contact old contributors, however.
Quintus
commented
8 years ago In all honesty, I don't think someone should have to pay to reuse a body of code he helped develop, especially if he wrote a significant part of it.
This was not the intention. I meant to say that externals who never touched a line of code would have to pay. For co-devs, another solution must be sought for. I thought that would be clear from the context of the statement (my personal views on GPL in general, not specifically related to TSC).
I for one will probably spend a lot more time developing the new TSC codebase if I know I can reuse the resulting code in other projects.
I know you know that, but to clarify to readers: The code originally written by you can of course be used in other projects without any permission from us. However, as soon as somebody else makes an improvement to the code you submitted, you may not take the improvement without permission from the person who contributed it. As per our current contribution terms, this permission is currently only given in form of GPL. It is of course possible to reach out to the improvement contributor and ask him for another license specifically for you.
Vale, Quintus
datahead8888
commented
8 years ago I meant to say that externals who never touched a line of code would have to pay.
I see.
It is of course possible to reach out to the improvement contributor and ask him for another license specifically for you.
Yes, it is technically possible to seek out a license (or licenses if multiple people are involved), though it tends to end up being infeasible in practice.
Quintus
commented
8 years ago Before starting work, we should resolve this. Is everybody fine now with suggestion of requesting CLAs to give the team full licensing flexability?
Valete, Quintus
Bugsbane
commented
8 years ago As long as it's a non-evil CLA ;) I consider a CLA to be evil if it allows for the project to become proprietary-only licensed down the track (as opposed to copyleft/liberal licensed). I have no objections to any CLA that limits re-licensing to some form of FOSS license (as defined by the FSF / OSS ).
Quintus
commented
8 years ago That simply depends on the wording of the CLA. Canonical has created the Harmony agreements, which contain standard texts for CLAs compiled from a module system. Disregarding the ugly website, I think using one of these standardised texts serves us best.
Vale, Quintus
Bugsbane
commented
8 years ago As long as it's a non-evil standardised text. ;)
Quintus
commented
8 years ago As long as it's a non-evil standardised text. ;)
Yes, it will be a non-evil one :-). I am not interesting in closing down TSC either.
Quintus
commented
8 years ago To get an impression what we are talking about, here's a slightly modified version of the copyleft-enforcing Harmony CLA: http://team.secretchronicles.de/~quintus/stuff/cla/cla-draft-2016-07-28.pdf
The preamble is a little different from the original and the last clause that attributes Canonical was added by me to comply with CC-BY 3.0 (which the texts are licensed under). The list of licenses approved by the FSF is this one I think. Note the list also include a non-copyleft license (Apache license), but the CLA explicitely refers to "copyleft licenses approved by the FSF" so that would not be possible.
We'll have to revise 3(c)(3) a little because it does not fit the project infrastructure. The CLA would be accepted by signing up, and one can't have the parents sign up separately. For these cases I think an email by the parents containing consent indication is the best.
Valete, Quintus
datahead8888
commented
8 years ago As long as it's a non-evil CLA ;) I consider a CLA to be evil if it allows for the project to become proprietary-only licensed down the track (as opposed to copyleft/liberal licensed).
As discussed further above, I think people who contribute to the project should be allowed to use code within proprietary projects. Otherwise the code is not really "reusable" from a certain perspective.
For example, if I were to contribute a first version of an OpenGL rendering system, a copyleft license would end up causing it to branch into two versions: a copyleft version (with copyleft code integrated into it by other people) and a proprietary version of my own. Granted, OpenGL shader code is called separately from code in other languages, but it would still end up being limiting. I would like to be easily able to put things I put a lot of time into in games of my own without making the full games open source and free of charge. If I were to put a game on the market, almost no one would pay for it if they found out there was a free copy available elsewhere, regardless of why.
I had said:
In all honesty, I don't think someone should have to pay to reuse a body of code he helped develop, especially if he wrote a significant part of it.
@Quintus, you had then said:
This was not the intention. I meant to say that externals who never touched a line of code would have to pay. For co-devs, another solution must be sought for.
This is worth discussing further.
I was a bit unsure how much time I could put into the new project, but if it is only under a copyleft license, I'm not sure I will end up putting very much time in at all, for a newly written game. I respect the team's decision, however.
Quintus
commented
8 years ago datahead is right, with the CLA suggestion I posted there is no possibility to automatically relicense code not written by him as something else than a copyleft license. I do well understand Bugsbane's point though, and I share his views on the game of TSC itself (which was why I came up with the copyleft CLA). It is going to need modification of the draft to get co-devs out of the copyleft clause. Something like "If the majority of the TSC team agrees, source code Submissions can be relicensed outside of TSC under any license as long as their origin is attributed."
This comes more close to the team decision making discussed above. But I have doubts it fulfills @Bugsbane's views on the topic. I think that before going any further, we need to resolve the differences between @datahead8888 and @Bugsbane. I'll wait how you two argue :-)
Vale, Quintus
datahead8888
commented
8 years ago I consider a CLA to be evil if it allows for the project to become proprietary-only licensed down the track
and I share his views on the game of TSC itself (which was why I came up with the copyleft CLA).
I should clarify -- I don't have any interest in trying to fork TSC and create a proprietary only, new version of TSC as a whole. My only interest is in reusing modules and portions of code, which I would have had some level of involvement in.
It would be a complete lack of creativity for me blatantly to rip TSC as a whole for a new commercial game; I would rather pursue my own creative ideas.
Karkus476
commented
8 years ago My irrelevant opinion:
GPL is a disease which means people fear even looking at your code. MIT/BSD/ISC means you might as well give your code away. Anything +CLA means that losing a vote could result in your code being relicensed. I would say choose a license and stick to it. When I write code I want to know exactly where it's gonna go. MIT/BSD/ISC: Would you mind if someone else took your (fantastic) code and made money from it? GPL: Would you mind if you wrote (fantastic) code and couldn't use it elsewhere? Basically everything sucks and we all die some day. Choose MIT/BSD/ISC and embrace true freedom. Disclaimer: I'm not a lawyer
Quintus
commented
8 years ago On Fri, Aug 26, 2016 at 12:33:26PM -0700, Karkus476 wrote:
My irrelevant opinion:
GPL is a disease which means people fear even looking at your code. MIT/BSD/ISC means you might as well give your code away.
I have attended talks by Stallman and can well say that I am a fan of the GPL. The people who favour MIT-like licenses completely neglect the user's freedom, which is all the GPL is about. Yes, the GPL binds developers very strictly by means of copyright, and this is good and required to protect the user's freedom. And specifically related to this project, TSC is an end-user programme and not a library that is meant to be re-used.
Anything +CLA means that losing a vote could result in your code being relicensed.
Not necessaryly, and it is not even my primary intention (see below). It depends on the wording of the statute. There is no final wording there yet, so we can well forbid this and enforce licensing only under copyleft licenses or even under GPL. As of now however nothing is decided; especially I am waiting for Bugsbane to take position with regard to datahead's requests. It is entirely possible to have a CLA that forbids relicensing to anything non-copyleft, and if you had taken a look on the CLA text I linked in a previous post, you would have noticed that that one demands exactly that.
Your post, however, has made me think about the wording of a CLA again. I originally proposed it because it simplifies the judicial treatmeant of the project, as it is unclear how a conglomerate of code and assets such as a game is to be handled if there is not one entity behind it that holds all rights. This is a flaw of copyright law as it (at least in Europe) did not foresee that there might exist works created by a really large amount of people who cannot be reached after they completed their contribution. For example, demanding compensation for copyright infringement requires that all involved people agree on that for the maximum possible effect. The only possibility to circumvent this problem is to collect all rights in a single entity. However, and this is what came to my mind when I read your post, to get this effect this entity must own the exclusive rights as that would mean that any other person must have gotten a license from this entity either directly or through sublicensees, and failure to do so is a copyright infringement.
The CLA I linked to originally only grants the entity a non-exclusive license which fails to achieve the effect I want to have. Since exclusive rights mean that the contributor loses his own right to use his contribution, there need to be countermeasures as I am probably right when I assume that this would cause problems. If we decide to go with a CLA, it should thus
This cumulates the exclusive rights in one entity and still allows the author to continue on his merry way; the difference is that now he has a "child right" that is a derivative of the entity's exclusive right. For him, there is no difference to retaining the exclusive rights since
The entity holding the rights will probably be the TSC team, as defined by the voting rules document. I would like to keep the option open to transfer the exclusive rights to a nonprofit organisation if we grow big enough, but that shouldn't cause problems if worded carefully.
While the above suggestion will resolve both the problem of treatment of several authors in one work and that one of giving the entity the necessary standing in a compensation process, it falls short on datahead's concerns, which are centered on number 2. above, i.e. the outbound license. He wants the possibility to take some of the code away and use it in his own (proprietary) projects, while I and Bugsbane (I think) would rather like to see things remaining copyleft all the way through. I do not yet see a solution to this opposition; as said, I'm waiting for Bugsbane's input. I am willing to step back from my position a little to make it possible for datahead to remain in this project (-> this is where the vote-on-the-outbound-license suggestion came from), but I am unsure as to whether Bugsbane would be willing to do that.
Choose MIT/BSD/ISC and embrace true freedom.
I definitely do not share your opinion. I do care about the end-user's freedoms, not the developer's.
Also, please stop wrapping your arguments in offending statements like calling the other party of your argument a "desease". You are not doing yourself a favour if you do that and want to be heared.
Disclaimer: I'm not a lawyer
Then I am happy to tell you that I am a law student.
Vale, Quintus
Blog: http://www.guelkerdev.de PGP/GPG ID: F1D8799FBCC8BC4F
Karkus476
commented
8 years ago It is of course, down to all of you developers to make a final decision. It is most likely datahead cannot get his way, unless he retains a personal copy of all the code he writes, or produces it as a library. This is because when another person alters his code, it is no longer fully his to relicense or reuse in a different project.
"Disease" is a metaphor of the fact that it cannot be used in conjunction with other code without "infecting" it.
Being a lawyer, it looks like you've got the right person for the job.
GPL doesn't help the end user at all if no one bothers to write software. But for a small project like this, it will work absolutely fine, even if it displeases some people.
refi64
commented
8 years ago Again, this is why I usually use the MPL; it can be around the middle, where you can use it in a proprietary project, but any modifications need to remain open source.
Quintus
commented
8 years ago Again, this is why I usually use the MPL; it can be around the middle, where you can use it in a proprietary project, but any modifications need to remain open source.
The MPL suffers from the problem I outlined further above: If you have a party who modifies your code in the sense of MPL(1)(1.10) and offers for download only your original sourcecode without the modifications, you will not even notice the copyright infringement, and you will be unable to enforce compliance as the MPL does not grant you a right to unconditionally check the other party's source code for compliance. Yes, this behaviour probably requires kind of criminal energy as that party intentionally violates the license, but how unlikely is it really?
This problem does not arise with the LGPL, which is why I think that license is preferrable if you want to restrict the copyleft to the original sources. LGPL(4)(d)(0) forces the licensee to ship the sourcecode of his programme if he links in the LGPL code statically (but note that it does not force him to license his sourcecode under LGPL -- he just has to provide it). If he chooses dynamic linking instead, he doesn't have to provide the sourcecode of his application (LGPL(4)(d)(1)), but since this results in the LGPL library being extracted into a separate file, it is much easier to detect whether he illegally modified the library and did not make his changes available under LGPL.
With the GPL, the entire problem does not even exist as any use of the GPL'ed code usually causes the copyleft effect to kick in and you can easily detect a license violation.
To your point, the LGPL fits the middle position better than the MPL due to this problem in my opinion.
Being a lawyer, it looks like you've got the right person for the job.
I'm not a lawyer, but I'm on the way (student, as said).
I think I could imagine TSC to be developed under the LGPL, but give me some more time to evaluate the license more in detail. This will resolve datahead's concerns and still keep the game sourcecode copylefted to accommodate my and Bugsbane's position. It also voids the matter of voting, since the license allows use in proprietary projects per se, if certain conditions are met. I want to be clear, however, that I would prefer plain GPL, but I can see that I have too much opposition against me in this regard.
And please don't forget that even if we decided to go GPL, datahead could still develop his changes as a separate library and make that one available under the licensing terms of his choice; we'd then just use it. This solution definitely grants him the most freedom regarding licensing.
Valete, Quintus
Bugsbane
commented
8 years ago Ugh. Ok, at this point I must confess that it's 2am here, and I have to get up in 4 hours, I'm tired and I skimmed much of what's above, so forgive me for anything obvious that I misunderstood / missed...
That said, I don't quite understand what the issue is if we have a CLA that demands relicensing under copyleft, but gets non-exclusive rights from contributors. As far as I can see, that lets @datahead8888 use all of his own code in products using whatever license he wishes, while ensuring that any code gotten by people via TSC is under a copyleft basis as is any future re-licensing of the TSC code... Doesn't this cover everyone's wishes?
(Note: this is the point where you all quote the parts that I've clearly missed in my sleep deprived brain-fog... ;P )
Quintus
commented
8 years ago (Note: this is the point where you all quote the parts that I've clearly missed in my sleep deprived brain-fog... ;P )
@Bugsbane Indeed you missed something, but that's okay at 2 am :-). In a nutshell: datahead wants to use changes others made to the code he contributed to TSC in his proprietary projects without asking for extra permission. An outbound copyleft license will not allow that.
Vale, Quintus
Karkus476
commented
8 years ago In all fairness, @datahead8888 is asking for something not easy or fun to achieve. My solution:
I hope this fits all your requirements.
On 29 Aug 2016, at 17:34, Marvin Gülker notifications@github.com wrote:
(Note: this is the point where you all quote the parts that I've clearly missed in my sleep deprived brain-fog... ;P )
@Bugsbane Indeed you missed something, but that's okay at 2 am :-). In a nutshell: datahead wants to use changes others made to the code he contributed to TSC in his proprietary projects without asking for extra permission. An outbound copyleft license will not allow that.
Vale, Quintus
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Quintus
commented
8 years ago
- @datahead8888 moves his large code contributions [...] into libraries, [...] under a license such as ISC.
- All his other contributions will only be usable under the license TSC is under
+1 for this solution. @datahead8888 ?
Bugsbane
commented
8 years ago datahead wants to use changes others made to the code he contributed to TSC in his proprietary projects
Really? I must admit I'm surprised. Is there any kind of precedent for that working in other copyleft projects? I can't imagine many people being willing to contribute for free to a copyleft project, knowing that their work could be used by some people in proprietary products, and even worse, that the right was only available to some people and not others.
I can totally understand wanting to have the right to profit from ones own work, or wanting to have ones work freely contributing to the common good of all, but to me, having it be enforced copyleft for some people but not others seems quite against the spirit of open source, both liberal and copyleft.
If I'm misunderstanding @datahead8888, then please do correct me. As I currently understand it though, I would have grave concerns.
Karkus476
commented
8 years ago Many projects use non-copyleft licenses, so in that sense it is not unusual at all... @datahead8888 never said he wanted extra special treatment, just more freedom. It was @Quintus who came up with the idea of the CLA iirc, giving the TSC team more power over contributed code.
On 29 Aug 2016, at 21:44, Bugsbane notifications@github.com wrote:
datahead wants to use changes others made to the code he contributed to TSC in his proprietary projects
Really? I must admit I'm surprised. Is there any kind of precedent for that working in other copyleft projects? I can't imagine many people being willing to contribute for free to a copyleft project, knowing that their work could be used by some people in proprietary products, and even worse, that the right was only available to some people and not others.
I can totally understand wanting to have the right to profit from ones own work, or wanting to have ones work freely contributing to the common good of all, but to me, having it be enforced copyleft for some people but not others seems quite against the spirit of open source, both liberal and copyleft.
If I'm misunderstanding @datahead8888, then please do correct me. As I currently understand it though, I would have grave concerns.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
datahead8888
commented
8 years ago @datahead8888 never said he wanted extra special treatment, just more freedom. It was @Quintus who came up with the idea of the CLA iirc, giving the TSC team more power over contributed code.
I originally suggested the MIT or BSD licenses and suggested the idea of allowing people who contribute a lot of code the right to use it as a second option if the MIT/BSD licenses were rejected by the team. Quintus's CLA is one possibility for this.
never said he wanted extra special treatment
To clarify, I wouldn't call it special treatment - anyone who made reasonable contributions could go through the same process and gain a right to use it in other projects. The team would probably review such a request before approving it.
Is there any kind of precedent for that working in other copyleft projects?
The rewrite has not yet been formally declared as being a copyleft project. The team also has the freedom to custom define any license it wants for brand new code. Given the current course of the discussions, however, I suspect the project will be copyleft.
I think I could imagine TSC to be developed under the LGPL, but give me some more time to evaluate the license more in detail. This will resolve datahead's concerns and still keep the game sourcecode copylefted to accommodate my and Bugsbane's position.
This really wouldn't work as well for separate subsystem components:
Again, this is why I usually use the MPL; it can be around the middle, where you can use it in a proprietary project, but any modifications need to remain open source.
This is going to be less trouble than the LGPL, but it still turns into a bit of a game of separating things into different files. It's not impossible, though; I'd have to think on it some more. It doesn't sound like Quintus is going to agree with this, however.
It is most likely datahead cannot get his way
I never really expected anything to come of this discussion. I just went ahead and threw the idea out, since the beginning of a rewrite is the time to discuss this.
It's pretty obvious the vast majority of the core team members want a copyleft based project, probably without exceptions being granted for people who contribute frequently. There isn't really even a point in voting. It sounds like this is what should be done in order to meet the general intent of the team thus. We need to come to a decision on this so that formal game architecture discussions and initial code prototyping can begin.
It doesn't mean I will never contribute source code at all; there just is a good chance I will contribute less often than I did for the prior version of TSC, and I probably will not contribute entire systems on my own. I am, however, wanting to see the current version of TSC get to release 2.1 and still have some amount of interest in the current story development; beyond that we will just have to see what happens.
Quintus
commented
7 years ago For a general library, such as a rendering library, it would still be a bit difficult to add onto it in a proprietary project. For example, I am likely to want to add a retro rendering mode and may not want to make it openly available.
You are asking for something impossible now. You want effectively proprietary closed-source code to be used in our project, i.e. code exclusively licensed only to the TSC team. This is, to be fair, inacceptable for an open-source project and would even be it if we were all under MIT license here.
It doesn't sound like Quintus is going to agree with this, however.
I have major concerns against the practicability of the MPL. The infringer can just claim he has separated everything into separate files, and lacking a legal right to demand from him that he shows the source code, the claim can not be attacked successfully. I would be interested if Mozilla has succeeded in enforcing the MPL under such circumstances, especially in a European jurisdiction. I personally think the license has a flaw here. It needs a clause that forces the possible infringer to reveal his source code in proceedings.
It doesn't mean I will never contribute source code at all; there just is a good chance I will contribute less often than I did for the prior version of TSC, and I probably will not contribute entire systems on my own. I am, however, wanting to see the current version of TSC get to release 2.1 and still have some amount of interest in the current story development; beyond that we will just have to see what happens.
Okay. Continueing under GPLv3+ is definitely what suites me and probably most other members most. Remember that of course you are free to use your own contributions elsewhere just as you like. I do hope that you will not entirely lose interest into TSC, but still continue at least with occasional contributions.
Can we take GPLv3+ as a baseline for the code then now? I would like to move this discussion to a decision now, and there's another open point I'd like to discuss with you: asset licensing.
Currently we demand people to agree that their assets are under CC-BY 4.0. This is great for combination with our code as it will never cause any licensing problems. However, the license is extremely permissive and it may happen that other people take the assets from TSC and make another game from them, which is legally okay. How strong are your opinions about preventing that? If you think "that's okay, it's just open-source spirit after all", then we can simply continue on our merry way as we do already. If you think that's bad and must be prohibited, we need to find a solution. I am open to both approaches and have no strong opinion on the topic, so feel free to post what you think about TSC's assets being used in different games (or even completely unrelated contexts, like a website that has nothing to do with TSC).
Greetings Marvin
datahead8888
commented
7 years ago You are asking for something impossible now. You want effectively proprietary closed-source code to be used in our project, i.e. code exclusively licensed only to the TSC team. This is, to be fair, inacceptable for an open-source project and would even be it if we were all under MIT license here.
No, I did not mean for us to use closed source code in TSC (making it no longer be a 100% open source project). I meant that for a different proprietary, closed sourced project that essentially has a mini library in it, it is more workable to statically link against borrowed TSC code than to dynamically link against it. This is not possible with the LGPL.
Remember that of course you are free to use your own contributions elsewhere just as you like.
As I mentioned before, this only holds true until someone else modifies the resulting code. The moment a subsystem becomes collaborative, it is effectively copyleft-only (excepting dynamic linking for the LGPL). This point sometimes is often forgotten in discussions, so I just wanted to make sure I was clear.
Can we take GPLv3+ as a baseline for the code then now?
The vast majority of the core team members and most fans seem to want this, so it would be logical for the team.
How strong are your opinions about preventing that? If you think "that's okay, it's just open-source spirit after all", then we can simply continue on our merry way as we do already. If you think that's bad and must be prohibited, we need to find a solution.
I don't have any problem at all with people using assets in other games; it's part of the open source spirit. Assets such as the title theme music or title screen graphics are a tougher question, but I still think we should allow them to be reused.
As I've said, I don't generally agree with copyleft for general projects, but since we are using copyleft for the code, the images should have copyleft, too, for consistency. We just ought to move toward consistent licensing for all assets as possible, eventually. A notable exception would be assets borrowed from other projects.
Quintus
commented
6 years ago So, enough of this. I've started the rewrite at https://github.com/Secretchronicles/TSC3 and it's under GPL3. As of now, no existing code from anywhere has been incorporated (other than library dependencies). I'm thus the sole copyright holder on the source code for the moment. With datahead mostly having retracted from development, I don't think we've any serious GPL opponents for TSC left.
For source code, I'm not going after the CLA idea anymore. I'm aiming for a normal community-driving coding cycle.
Regarding assets, the last word on CC-BY 4.0 isn't said. I find it suboptimal that it allows use of the assets even in proprietary projects. The code is GPL for a reason, but CC-BY-SA and GPL can't be combined. I thus leave this ticket open for a moment.
Quintus
commented
4 years ago I have spent this weekend with thinking about the unresolved part of this issue, i.e. the assets license. I have reached the following conclusions.
Currently, assets are contributed under CC-BY 4.0+. This license is good for our use, but has a major flaw noted earlier: it allows the assets to be used by proprietary projects as long as the attribution clause is honoured. CC-BY-SA does not allow this: the share-alike clause prevents it. I want a license that does not permit reuse of our assets in proprietary projects. Ideally, use of assets outside of TSC should be forbidden, but such a clause would make the license unfree and prevent packaging by Linux distributions (most notably Debian). Thus, I think we should go with the next-best option and use a license that at least prevents proprietary use.
The final TSC game in compiled form however is most likely an adaption of both the source code and the assets. It is thus required to comply with both the assets and the source code licenses on redistribution, and I've long been under the impression that CC-BY-SA and the GPL conflict as it is not possible to comply with both simultaneously: CC-BY-SA requiring to license the result as CC-BY-SA, and GPL requiring to license the result as GPL. As it turns out, however, § 3(b)(1) of the CC-BY-SA 4.0 has an opening clause that allows to fulfill the share-alike requirement not only by relicensing as CC-BY-SA, but also by relicensing under a "compatible license". § 1(c) CC-BY-SA 4.0 defines "compatible licenses" to be those listed by the CreativeCommons project under https://creativecommons.org/compatiblelicenses. Luckily, the GPLv3 (not any other version -- exactly GPLv3) is listed as compatible. This means that it is possible to adapt a CC-BY-SA-4.0-licensed work and relicense it to downstream recipients as GPLv3. This is exactly what we need. Even more, CreativeCommons specifically wanted compatibility with the GPLv3 to allow use of CC-BY-SA-licensed works in GPL-licensed video games (second-to-last section on that page). Since only GPLv3 is listed as compatible, it is not possible to redistribute the compiled game under GPLv3+, but only exactly under GPLv3. This may change later on, when a hypothetical GPLv4 license is listed as compatible by the CC project. In any case, redistribution of TSC's source code alone (without the assets) is not affected and thus the code license can remain at GPLv3+ as it is today. The compiled game however will have to be GPLv3-only.
There's a caveat with the license compatibility that needs to be honoured. It is (of course) required to fulfill, as licensor, all obligations under the GPLv3. This includes the obligation to provide the preferred working form of any object licensed. While for the programme this is the source code, for our assets this is the respective programme's working format, most notably the SVG files for our PNG assets. Any further contribution to TSC will have to be made dependent on the provision of those files. Luckily, for most assets, we do have the sources anyway. The most notable exception are the music files; I have to give these a second thought before the suggestion I make in this post can be applied. Unless all sources can be obtained, it might be required to extract these non-sourceable assets into a separate package that needs to be distributed separately from the rest of TSC.
Until now, contributions to TSC were licensed as CC-BY. This does not pose a problem. CC-BY is compatible with CC-BY-SA, i.e. we can relicense these assets without having to ask all the authors of those assets. As explained above, however, we do need access to the source of such assets (which we often have) in order to further relicense as GPL.
Finally, I want to apply these changes immediately after the 2.1.0 release, that is, 2.1.0 shall be the last release under the current terms. There might not be a completion of the 3.0.0 rewrite anytime soon and I want to have a clear legal situation.
Quintus
commented
4 years ago Side note: When the repository's directory layout is changed at some point, it should be setup in such a way that the license situation can be inferred from the directory layout. The current situation with the license in the .txt and .settings files is rather difficult to handle. It'd be good if the new directory layout could separate out the CC-BY-SA parts into a directory /assets/, while the source code is in /src.
Extracted from #534
@datahead8888 wrote: