Agree strongly with the last two requests, but not so much the first one (but I guess it's to be expected for RMS.)
It's clearly a well intentioned mistake, but it's the kind of thing that can bite you later because someone will accept the license and use it for something you never intended. At that point it's a really big headache.
It gets even more complicated when people try to mix licenses that are incompatible -- it works fine until somebody challenges it. At that point it's an absolute pain. The last thing you want on your project is to have someone say they are going to sue you because you don't have permission to use their code. It's really, really important for people to follow the licenses correctly and GitHub is in a wonderful place to help with that. It's a win for everybody. I would say even if people realise that they can't use GPL for some project because it is incompatible with the license for other code they are using, it's better than going for years and having a problem!
I think it is a good request though. I'm fond of MIT, but with the right wizard, I may also find that GPL or something else may be a better fit for what I'm working on.
It's not under the github.com domain, but they did create it. IIRC they link to it somewhere when you go to create a new repo, along with a drop down to select what license you want (Assuming you're not just pushing an already created repo).
Hardcoding any strings is an antipattern.
Now, if the intent is a one off and they have no intention of drinking from the same well so to speak, go nuts.
I've put them there a bunch of times, they were (at least initially) edited by the same people as the rest of the code and they were required for the app to compile.
I didn't downvote you, but I wrote enough games to hope no young programmer takes your advice.
Games, as iteratively developed creative products, always interweave engine with content. Trying to write a generic engine in parallel to your game is a surefire way to never release a game.
Even if you set out in advance to write an engine, you should do like most market leading engines and develope a game first, then extract the engine out from it (Quake, Half Life, Unreal, Far Cry... the only counterexample I can think of is Unity, wait no wiki says "Over the Edge released its first game, GooBall, in 2005.[4] The game failed commercially, but the three founders saw value in the game development tools that they had created to simplify game development, and so they shifted the company's focus to create an engine for other developers.")
Sure, they are. In different files at a minimum, and likely within a separate directory tree in the overall project.
But not in a separate repository entirely!
Look at how the overall software industry is going towards monorepos. Not just (or even primarily) games, but software in general.
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Someone posted what they think is a reasonable answer to what I proposed and I didn't agree. I could expand on the discussion and haven't changed my mind. I thought we all came here to do that.
And you seem to be wrong about by comment about the guidelines. The other user was informed or reminded about the guidelines and we even had a nice little 'comment chat' about them.
Any kind of online forum inevitably requires participants to remind each other of the rules as it's the principal means of enforcing them.
You could try to put your data in some other repository, but since you are versioning that data anyway, that introduces additional pointless complexity and besides the code is useless without the data to work with - so just stick them together and be done with it. If your VCS cannot handle that, instead of having it dictate your workflow towards an inferior solution, change your VCS.
At least as far as games are concerned, data and code are interwoven and any other approach is guaranteed to either fail or produce unnecessary and easily avoidable complications.
It would be cool if the license metadata currently existing on GH could be extended to carry names, in a way that makes it impossible to strip attribution (depending on the license, of course).
E.G. there are services like small claims court in the UK that _mostly_ automate the billing on unpaid invoices, is there something like that for licensing?
If we have source code and can determine it is derivative of open source but improperly licensed, does it matter? At that point we have the code and we know it's derivative and thus can infer the license. It's not like the publisher could come back at us for taking it back.
I don't see the value in such a tool other than to abuse people who shared incorrectly. And if I ever shared code incorrectly and got slapped on the wrist for it, that might just be incentive for me to never bother to share again.
Companies get away with this because developers don't understand licensing in the first place. Pushing a false message that "once it's out, anything goes" is detrimental to that state of things.
> If we have source code and can determine it is derivative of open source but improperly licensed, does it matter?
Of course it does, a license is a license, you cannot selectively apply only some of it. And yes, if the license is not followed, the original author can revoke consent to redistribution and usage. Have you actually read an open license? The GPL is very explicit on this matter.
> if I ever shared code incorrectly and got slapped on the wrist for it, that might just be incentive for me to never bother to share again.
That's not a problem. Opensource doesn't run on generosity, but on publicity - a currency that can be converted into actual cash. If you don't share your "left pad", sooner or later someone else will share his own version and reap the rewards. The time when we had to beg companies and individuals to share, is long gone.
So, for example, when a Router manufacturer consumes GPL code and doesn't contribute their changes back it's a failure of the developer who GPL'd the code they used? Why is the person sharing responsible for policing and enforcing? That burden encourages developers to either not share, or to share without restrictions.
> Of course it does, a license is a license, you cannot selectively apply only some of it.
Yes you can selectively enforce your own license. But enforcement isn't the point. Developers don't necessarily want the burden of enforcement that you're mandating they must do as part of sharing.
My point was that, if you can determine someone's code is derivative of GPL'd or MIT'd code but with a license stripped, you can still use it. If the person who stripped the license tries to come down on you, you're still protected by the original license that they stripped away.
> That's not a problem. Opensource doesn't run on generosity, but on publicity - a currency that can be converted into actual cash.
I would argue that your perspective is the problem. Open source is or isn't just about money. People who share aren't necessarily trying to do it for currency, social or monetary.
While I freely admit my contributions are limited, I have never sought any currency with them. My contributions fall into two categories, the first was to make a consistent problem I had with some code I consumed go away and the second was to share tools or utilities I made to solve my own problems because I thought someone else might like them.
Your opinion of open source puts unnecessary burdens on people who just want to share and results in much of the drama we see. Look no further than uBlock or WiringPi for examples of developers trying to move away from the burdens you're imposing.
Some people just want to share something they did without burden but you're basically saying "no, sharing comes with obligations like license enforcement, currency, or user support that you're required to invest in"
This seems like a reasonable enough place to ask: if you have a project under MIT, and I pull a function out of one file to use in my project, where exactly do I owe credit? In a comment above the specific function? At the top of the file? In the main license file for the project (even if the whole project is under e.g. GPL)? Some combination of the above?
Like this: https://paste.ubuntu.com/p/BJGhs8qGcr/
RMS is not saying "make everything GPL" (or at least, not in this context). He's just saying if you're going to publish source code, please make clear the condition under which it can be read or used.
> If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking).
> You grant us and our legal successors the right to store, parse, and display Your Content, and make incidental copies as necessary to render the Website and provide the Service.
I think honestly this is something other providers (Google code when it was around, gitlab now) are much better at.
If you're working on something that you hope to (eventually?) make money from, but you also want to benefit from the collegial atmosphere of open source, then choose the GPL. This simple decision instantly eliminates a whole subset of would-be competitors, who you now don't have to worry about undermining your business or otherwise threatening your source of income while they rely on being able to use your own work against you, since the GPL automatically places your work in their do-not-touch category.
This is true, and yet your conversation partner still has the winning answer. The point is that, notwithstanding these restrictions on developers—some of whom have the desire to be able to take without reciprocation—the freedom guaranteed by the GPL to users more than makes up for it. We're essentially talking about local versus global maxima here.
> It's almost impossible for a commercial product to use GPL 3 licensed software at all.
On the contrary—GPL is very beneficial, for the reasons I just laid out in another comment[1]. GPL-licensed code is not ipso facto any harder to commercialize than if you were to make the end result available under MIT. It's arguably even easier, since your competitors will have a more difficult time competing with you than if you'd chosen MIT. As Eben Moglen once put it, if you're trying to decide on a license, then by all means you should go with a permissive one—if you're what you're looking for is "a really good license for your competitor to use"[2].
You need only look to history then compare and contrast it with the industry's current preoccupation with funding the development of free and open source software. Red Hat/Cygnus were largely built on top of GPL code. Meanwhile, today's developers entrenched in the GitHub culture, with its permissive-first obsession with licenses like the MIT, have been bamboozled into working against their own interests by giving away their strongest bargaining chip when they decide to go with the flow instead of choosing the GPL.
And super permissive licenses like MIT hurt developers too, because it means I oftentimes can't see the source code that someone else has modified, even though it would help me a lot to be able to do so. With GPL-licensed software, I am always guaranteed this freedom.
That type of thing is why I think people need to choose one of: GPL, LGPL, MIT, BSD (isn't that essentially MIT?). I dont see the point in other "open source" licenses, they primarily create compatibility issues.
In Rust most code is dual licensed as MIT or Apache 2. You can pick which one to use although IIRC Apache 2 is considered the "primary license" because it provides protections from patent trolls and an explicit contribution licensing clause. However Apache 2 isn't compatible with GPL.
What are you talking about? Let say we have code A licensed as MIT and code B licensed GPL.
You can combine A with B and distribute it. You can combine B with A and distribute it. AB or BA is both a legal combination that a distributor can do. In both cases the distributor need to follow the condition of both MIT and GPL. You can not distribute AB and only follow GPL, or combine BA and only follow MIT.
There is two ways to look at copyright licenses. The slightly incorrect but slightly easier way is to see them as a contract. In order to distribute you need to follow the conditions. If you have two contracts then you have two sets of conditions. Three contracts and three sets of conditions.
The second way, which lawyers prefer as the more "true" perspective, is to see a copyright license as a list of permissions. Copyright law dictate that as a distributor you have no rights, so the license is the specific conditions in order to gain permission. It is like a airplane ticket where in order to travel you got to follow the rules and conditions or the airline. Countries can also have conditions and rules like visas, passports and enter/exiting laws. Thus in order to have permission to travel between countries you need to follow both sets of rules and conditions.
Incompatibility occur when the rules and conditions of two or more licenses demand something impossible, like the case where one condition require an action and the other forbid said action. Both conditions can not be met at the same time and thus the licenses are incompatible.
If neither aspects is an issue then the additional work needed to add GPL code to an MIT licensed project is practically zero.
There are however naturally implication for downstream which in combination of additionally third licenses (such as proprietary licenses) can cause real issues, and the relationship between such downstream and the MIT project could as a result lead to reasons why the MIT project feel like they can not include GPL into their code. There might even be contractional reasons involved which mean not only do you now have three different copyright licenses to follow but you also have contract law involved in order to follow the law and have a legal right to distribute the combined work. I can see how the permissive licenses in those kind of situation feel simpler since they do not interact much with the other legal stake holders.
Previously, someone could use your MIT code in a closed source product and distribute the resulting executables to their customers without including the source. In the future, that someone would have to start following the GPL rules or stop using your not-MIT-anymore project.
Under MIT, Microsoft can take code from A and put it into the source code of Visual Studio, provided that they keep the copyright and license with the code they've copied. Visual Studio can then be licensed however they want.
Let's say that project A takes code from project B. Now because they have GPLed code, A has to be distributed with terms at least as open as the GPL3's terms, due to copyleft.[1]
This might not matter to the maintainers of project A, but it certainly matters to Microsoft, because now if they use code from project A, they also have to distribute it with terms at least as open as the GPL3's terms. So if they use code from project A in Visual Studio, they've effectively licensed Visual Studio under the GPL3.
The GPL3 is "infectious" in this way--once you use GPL3 code in your project, your project is effectively licensed under the GPL3.
[1] https://en.wikipedia.org/wiki/GNU_General_Public_License#Cop...
Doesn't it have to be licensed as GPL3?
I'm no lawyer, but if I'm understanding correctly, yes, it does have to be licensed under the GPL3, but it doesn't have to be licensed only under the GPL3. With a license like MIT, the could apply a second license which would, for example, amend the MIT license to require you to pay for the software.
However, the "No Further Restrictions" paragraph in the GPL I think puts a much stronger set of requirements:
> You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
This is why I think Stallman often uses the language "licensed with terms at least as open as the GPL" instead of saying "licensed under the GPL"--yes, it has to be licensed under the GPL3 but that doesn't quite capture the whole story. Someone can apply another license (i.e. Apache 2, to explicitly grant patents) so their licensing might not be just the GPL3, but further licenses can only expand freedoms, not restrict them.
I would encourage anyone who is interested in this sort of thing to read the license for themselves. Don't get intimidated and assume it's all in legalese: while I'm hesitant to think I understand it since the law is not my area of expertise, the GPL is written in what seems like fairly straightforward English.
In that case we have three licenses. We have the MIT licenses, the GPL license, and the license of Visual Studio owned by microsoft.
If the MIT licensed project have a relation with Microsoft which they value higher than the code from the GPL project then the GPL code will be incompatible with the goals of the MIT project.
The incompatibility depend on the relationship and can only be answered based on defining said relationship.