IAAL. My reading of the article and the terms of service strongly suggest that the author of this article is not well informed on the subject.
For example, my informal and cursory analysis of the article:
> Section D.7 requires the person uploading content to waive any and all attribution rights.
It does not. The Github license requires a waiver of the requirement of attribution insofar as such waiver is needed for Github to do what it already does e.g. as the license indicates, provide search results without attribution.
Further, only Github has been given this waiver. Anyone else is still held to any requirement of attribution.
> section D.5 requires ... the right to “reproduce your Content solely on GitHub as permitted through GitHub's functionality”, with no further restructions attached; this is a killer for, I believe, any and all licences falling into the “copyleft” category
While D.5 does permit performing, using, and displaying of a work, it permits reproducing on GitHub only. Any copying from GitHub not granted by way of another license would be a violation of the author's copyright.
Use, performance, or displaying in the absence of a right to reproduce strikes me as a rather narrow set of rights.
I stand to be corrected, but I see nothing sinister, nefarious, or unwarranted by GitHub.
I think you've convinced me. I was concerned that the use, performance or display may be a problem... but thinking it through, I do not really see this as an issue with most copyleft licenses. They are usually tied to distribution of code - which is reproduction.
I echo your disclaimer. If you need a lawyer, get one.
This is a little off topic but these comments make me wonder: why are lawyers so reluctant to give informal advice? I really appreciate the two thoughtful and informed comments at the top of this article here - why the disclaimers? I look for and give informal advice about all kinds of other topics that have the same levels of ambiguity and sometimes the same levels of importance as legal issues but it's always a real challenge to get a lawyer to weigh in informally on a legal issue.
If someone asks me my opinion about an engineering or management issue they're facing, I'll give it to them knowing that I don't know the complete set of facts and they should take my opinion with a grain of salt. I might be missing important context and I might just be wrong. If I ask someone else advice on any topic, I assume that there is an implicit disclaimer. Is there something fundamentally different about the law? Is it because lawyers are in the business of giving advice?
Anyway, appreciate you guys weighing in and hope you do it more frequently :).
> This is a little off topic but these comments make me wonder: why are lawyers so reluctant to give informal advice?
Because an attorney-client relationship is created when the client reasonably believes it to have been created. As a result, you have to be really fucking clear that people are not your clients because, when making the determination of whether someone has reasonably determined that someone is their lawyer, courts look to what the average bloke would think - i.e., a total dumdum. So you really have to hit people over the head with the fact that no, you are not their lawyer.
So, the second part of this is that when an attorney-client relationship is created, the attorney has a tremendous amount of duty to the client, and, if the client acts on the advice of the attorney and gets results they do not like, they can sue the attorney for malpractice.
> If someone asks me my opinion about an engineering or management issue they're facing, I'll give it to them knowing that I don't know the complete set of facts and they should take my opinion with a grain of salt.
Are you a licensed Professional Engineer? If so, for the love of Odin's beard, stop giving informal advice, as you are exposing yourself to professional liability.
Licensed professions - accounting, medicine, law, professional engineering - have extremely high duties of care to their clients. They are exposed to malpractice liability when things go wrong. They have ethical obligations. It can be extremely hard to fire delinquent or terrible clients.
To put it a completely different way: lawyers give advice as their job. There is no such thing as "informal advice" from a lawyer, the same where there is no such thing as a "pick up game" with an NBA player. It is their primary occupation. I don't do it for free - I charge a pretty stiff hourly rate. And every time I take on a client, it has impacts on my firm's malpractice insurance. In fact, I cannot take on clients without the explicit approval of the managing partner at my law firm - I get his written approval for every single one. To make it clear, the managing partner is the guy who, if there was a war between all the lawyers, gets to wear the biggest, fanciest hat. So, no, I am not just going to do the thing I do for my day job as a favor to someone else, any more than your computer programmer friend wants to fix your iphone.
Does that go some distance to answering your question?
> There is no such thing as "informal advice" from a lawyer, the same where there is no such thing as a "pick up game" with an NBA player.
The rest of your post is fascinating, and it made me understand this disclaimer much better; but surely this analogy is misleading.
If I've understood you correctly, there is, legally (or perhaps even by definition?), no such thing as informal advice from a lawyer; but surely it is only conventional that you will probably be in a pick-up game with an NBA player, as no regulation or law prohibits it. (Indeed, by analogy with any field whose practitioners tend to be passionate about it, I would assume that it is quite common for NBA players to play pick-up games with one another.)
Or perhaps, as someone ignorant of all things sports, I have missed the point of the analogy.
The point is that all advice from a lawyer is advice from a lawyer - the same way that an NBA player is still an NBA player whether he is in a playground or on a pro-sports stadium. The point is not what you call the game, it is that the service he is providing - professional level sports ability - remains the same. As in, he is not rendering a different type of service because he is on a playground as opposed to in Madison Square Garden. He is doing literally all the same things, with all the same risks - but for no money. And, importantly, he can still get injured, which would prevent him from doing the thing that makes him all the money.
> Indeed, by analogy with any field whose practitioners tend to be passionate about it, I would assume that it is quite common for NBA players to play pick-up games with one another.
I would be surprised, specifically for the 'injury' reason above. They don't play pick up games - they go to practice - which is supervised and has medical personnel right there. But who knows. That is speculation.
Yes, that's a difference. An NBA player can take it easy, not give his/her best, not slam dunk, not run, watch his/her steps more than the ball - to avoid injury, skip risky defense moves - to avoid injury again, or just because he/she is tired or just not feeling it. And no biggie.
But from a lawyer or an engineer that's not really okay, because even if you say I'm not giving your question my full attention and yeah, I think you'll be okay with just a simple rebar frame and no concrete for your bridge, but don't quote me on that and get a professional's advice ... the asker will be more confident, because he/she just did that, asked a professional, even if not in its proper capacity - and when bridges go down people get angry.
Though thinking about it, people usually get very angry at street ball too!
I think that's exactly what they do sometimes though: and disclaim directly that This Is Not Legal Advice and I Am Not Your Lawyer.
At this point they can take it easy and recommend literally anything since the most painful ramifications have been lifted. If you happen to score against an NBA player in pick-up you might be proud but you'd be dishonest to suggest that this means you have professional skill.
Related question, "... if the client acts on the advice of the attorney and gets results they do not like, they can sue the attorney for malpractice..."
Does that really happen a lot, or is it just something that they drill into you in law school? I never hear about attorney malpractice suits.
Why would you? They are deeply embarassing and lawyers try to make them go away as quickly and quietly as possible. However, the big ones do make the headlines - BUT, while I read Hackernews every day, and you likely do to - do you ALSO read law360, aboveTheLaw and the New York Law Journal? Because that is where you read about malpractice lawsuits. Not on techcrunch. And trust me - they happen all the goddamn time. All the goddamn time. There are lawyers who do nothing but sue other lawyers. There is an entire legal malpractice insurance industry.
And, importantly, if you are a litigator - as in, someone who sues people for a living - your clients are already demonstrably the sorts of people who are willing to sue when they are pissed off. It is not unreasonable to assume that if things go wrong in these circumstances, people turn on their lawyers.
Incompetent lawyers who are unaware of their limits and don't realize they are giving bad advice and corrupt lawyers who think they can get away with deliberately hosing their client are rare cases; the others conservatively avoid giving dangerous advice that could lead to malpractice suits.
This Is Not Legal Advice. (See elsewhere in the thread for why lawyers can't offer "legal advice" to non-clients, even "legal advice that you should have someone else double-check")
I have no law education. When I read IAAL it sounds to me as some professional is about to give me some advice. So I don't really get it why anyone would write that on the internets.
This is how I read it: there is a difference between giving advice and stating facts/giving an opinion. IAAL informs that said opinion/fact has some weight but stating that it is not advice waives any liability as to what one ought to do with whatever statement has been made.
Compare with the following: I am a software engineer, here's my take on this or that technical matter, but don't apply this sample snippet as is in production, also I'm waiving all responsibility, like MIT-license style.
It's not that you shouldn't listen to random professional folks on the internet, it's that when they informally give some opinion on a matter, they may very well be missing some key part of your very specific context, and while common sense just would tell you not to take it as is and that you could hold them liable for anything, J. Random Bloke statistically lacks common sense so one has to spit proactive waiver statements telling people to act on their own responsibility or take advice in a proper, formal client-to-professional context.
> What is the threshold for a reasonable impression of the relationship
"Reasonable belief" is the threshold. There's a whole bunch of case law, of course, on how that applies to specific circumstances, but you aren't going to get a short answer other than the actual standard.
> Could random advice on an internet forum really trigger it?
Maybe; lawyers tend to be fairly conservative about the risk, because the consequences of professional misconduct are potentially quite serious career impacts.
Of all the people commenting about legal topics on the Internet, the probability P(Lawyer) is so low that it would take an especially unreasonable person to honestly believe the discussion creates an attorney-client relationship. But once someone says "I'm a lawyer," I'd guess P(Lawyer) is at least 50%. A mildly retarded but otherwise reasonable person might get the wrong impression at that point.
Depending on legislation it's also not legal for lawyers to give specific advice for free. E.g. in Germany lawyering is a rather heavily regulated business - for obvious reasons - and while there's a whole bunch of exceptions (as usual) in general a lawyer cannot give legal consult for free.
Who is the client? I am French and we do not have this automatic mechanism, a lawyer can provide advice and before I have hired him or her it is just this - advice. In French sites you will get advices without disclaimers, except staying that I may be a dog on Internet and have no idea about what I am taking about.
Is this because HN is located in the US? Would two American citizens have this relationship via a French site?
There are strong legal protections for the attorney-client relationship, such that lawyers are obligated to act scrupulously in their clients' interests. These rules exist for good reason, but a prudent lawyer will want to make it very clear when such a relationship exists and when it doesn't.
But why then, say "this is not legal advice" when you could instead say "I am a lawyer but I'm not your lawyer"?
Or how about "I'm not formally signing off on this statement as a product of my legal-professional persona, but you're free to take what I just wrote to another lawyer and get them to vouch for its veracity, which they probably will"?
I hear that in military and political contexts all the time—"I can tell you this as a friend, but not in my role as X, so go find some other X who's allowed to speak on it if you need formalization"—but I never hear it from lawyers. It always seems to be phrased more as "what I'm about to write is probably wrong and you should go to get your own lawyer who will tell you something entirely different."
This just shows that two lawyers did not even read my article and just comment on it demeaningly.
Please do note that D.5 also covers “reproduce”, which _is_ “distribution of code”, _and_ that I address this point in my article.
So, in short: If you need to give lots of money away, get a lawyer, but even then you’re not getting what you’re paying for. They also only cook with water, they also are just erring human meatbags.
>Any Content you post publicly, including issues, comments, and contributions to other Users' repositories, may be viewed by others. By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of your Content in repositories they control).
>If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality. You may grant further rights if you adopt a license.
"Reproduce" is limited by "solely on github." I simply disagree with your analysis. I've read many hundreds and written dozens of software licenses - this is what I do for a living. Your argument, up to this point, is unpersuasive. I am always willing to change my opinion based on a persuasive argument or evidence, but you are not providing that - you are simply saying I am commenting on it "demeaningly." That is not a "responsive," argument, and, in this case, it is also false.
Have you asked any lawyers about this? Or are you just relying on your interpretation?
GitHub asks for a right to distribute unattributed snippets of the code for the search in the ToS.
If the license under which I got the code from someone else specifies that I can only distribute the code or snippets if I am including the license header, then that causes an issue.
(I asked a family member who is a lawyer about that, and they agreed that this seems to be a problem. I’ve tried to get approval from all authors of the code I used to be on the safe side).
Specifically, the terms under which I licensed the code I put on GitHub from a third party include
> provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.
[EDIT] Due to "you are submitting too fast, please slow down", I will only answer questions on this comment via email.
> The Github license requires a waiver of the requirement of attribution insofar as such waiver is needed for Github to do what it already does e.g. as the license indicates, provide search results without attribution.
The whole problem is that I, as an uploader of code that I did not write, do not have the authority to make that waiver.
Not necessarily. If the license allows you to redistribute the code, you're just redistributing it to GitHub, and you're OK as far as the software license goes.
If GitHub then does things with that code that the license doesn't allow, it was GitHub that is doing something it's not allowed to - unless, as uploader, you've agreed to indemnify GitHub for this sort of thing.
It may be the case that what the license permits (combined with fair use law) is sufficient to allow what GitHub actually, currently does with the code, but not everything their TOS claims the right to do.
In particular, "store and display your Content [..] as necessary to render the Website and provide the Service" is rather broad given that the functionality included in the "Service" (defined as "the applications, software, products, and services provided by GitHub") can change at any time, without notice.
Wrong. My OSS project has over 15 years of history, uploaded to GitHub after migration from SF.net. It has third party dependencies that I use under their licenses - which often do require attribution.
The big problem with this is consent of other parties for works that have been forked or are otherwise mirrored on github, from what I can see.
If I go and fork some random open source project off Sourceforge or whatever, I cannot publish it on GitHub as I do not have the original author's permission to grant GitHub these rights.
Please explain. Did the previous terms also require anything that debatably required getting permissions from copyright holders beyond those granted by, e.g. GPLv3?
The new terms do not grant permission to Github to do anything that they weren't already doing. If you take the view that this agreement is not compatible with a particular software license, then publishing the same software on Github prior to the changes logically must have been a license violation.
What? No. Prior it meant Github was violating your license. Just because they were already doing it doesn't mean they had a right to do so. Now, it means you're granting them a license. I'm not a lawyer, and I have absolutely no clue if it's even legal for Github to change their ToS like this. But I assume if you don't have the right to grant this attribution exception to Github (because you don't own all the code) and you don't remove your code from Github, then you are now also in violation of the rights of contributors to the project that didn't consent to this waiver.
In that case, I'd like to see their terms of service re-worded, as "You grant ... rights, or affirm that you will only submit content that is under a license which grants these rights".
I mean, they could skip the whole "without attribution" thing as well by just providing a link to the LICENSE/COPYING + NOTICES (if included) file in the repository as well when displaying search results.
Overall I feel this was a pretty poor move by GitHub.
IANAL. I'm just a random person who studied the book, "Open Source Licensing: Software Freedom and Intellectual Property Law," by Lawrence Rosen.
The OP doesn't mention D.4 much. The first paragraph of D.4 seems fine to me. But I worry the "clarification" (2nd paragraph) in D.4 could potentially cause problems:
> That means you're giving us the right to do things like reproduce your content (so we can do things like copy it to our database and make backups); display it (so we can do things like show it to you and other users); modify it (so our server can do things like parse it into a search index); distribute it (so we can do things like share it with other users); and perform it (in case your content is something like music or video).
Is "modify it" the same as "create derivative works"? If so, seems you've granted Github the right to "modify it" and "distribute it" potentially without any restrictions.
The Github license requires a waiver of the requirement of attribution insofar as such waiver is needed for Github to do what it already does e.g. as the license indicates, provide search results without attribution.
Assuming github does have feature(s) that require additional privileges to the source beyond what the open source license provides, doesn't that preclude hosting any project where any single one of the contributors don't contribute via github? (ignoring CLAs and work for hire.) The uploader is unauthorized to grant a wider license to github than they received the code under, right?
I stand to be corrected, but I see nothing sinister, nefarious, or unwarranted by GitHub.
I wouldn't say they're being sinister, but I don't think that was the point. The point was that their cover-your-ass move is preventing a large number of open source projects from being hosted on the service in compliance with the ToS.
> Assuming github does have feature(s) that require additional privileges to the source beyond what the open source license provides, doesn't that preclude hosting any project where any single one of the contributors don't contribute via github?
Yes it does. If there's a license that says "you must not make backups of the code on Thursdays", then hosting it on github would be incompatible with the license. So is hosting other people's non-open-source code in a public repo. Github's ToS put the responsibility of checking that the compatibility of the license and github features on whoever uploads the code.
> The point was that their cover-your-ass move is preventing a large number of open source projects from being hosted on the service in compliance with the ToS.
Well, there are features that Github wants to have on public repos, for example public code search with short snippets, and the "fork" button. Their ToS has to "cover their ass" for these features, their lawyers would throw a fit if they kept the features without asking for permission in the ToS.
If there are OSS licenses that are not compatible with these features, then either the uploader or github was breaking copyright laws already.
But I'm not convinced that its anywhere as big deal as the author of the article makes it seem.
So github has public code search, which shows 5 line snippets of code with a link back to the repo. Does this satisfy LPPL's "code must be distributed unmodified" rule? Is this enough attribution to satisfy CC-BY? A reasonable person would say yes, because you can just click on the link to get to the whole repo with the full codebase and authors.txt file.
But github isn't going to take the legal responsibility of checking each license for these questions, people uploading the code will have to do it themselves. (Also, github has no way of checking that the person uploading the code actually has the right to put the license.txt file on the code).
You don't have to contribute via github you would just have to grant the project the rights needed to use github. GPL Java projects usually have a classpath exception added, now github projects need GPL with github exception.
> Further, only Github has been given this waiver. Anyone else is still held to any requirement of attribution.
This convinced me.
I can release my code under GPL, and then sell it to someone else under different terms. It's my code, and I have copyright. I don't have to give the same permissions to everyone.
Likewise, just because I give Github certain permissions doesn't mean I have given the same permission to everyone else.
Even worse, if you've ever accepted a patch or pull request and didn't get copyright transferred to you, then that code is still owned by the author of the patch, and you'll need their permission too.
edit: I don't think forked repos are much of a problem. They're already on Github, so they already accepted the ToS. if they didn't, that's not your problem as a forkee. Unless the code was forked before this new ToS. Copyright is so messy.
Does a link to the source repository (which grants easy access to the usernames of all contributors and the full content of all files in the repo) not count as attribution?
So I need to find a lawyer and pay him $1000+ so I can see if GitHub is safe to use?
I guess I'll just stick with storing projects on my computer at home and skip this cloud-based stuff. I can't afford to retain a lawyer and consult with him for everything I do with code online.
Any (informal) opinion on the validity, according to the new ToS, of mirroring third-party F/LOSS projects on GitHub (ones distributed under GPL, MIT or BSD)?
Do I need to get the permissions from each author of the work to upload it, above what Free Software licences already allow?
Meta question here. Is it necessary to say "I am not a lawyer...if you need legal advice, retain a lawyer."? Is that statement really legally protecting you? Is it intended to encourage the reader to take you less seriously? I'm having trouble not seeing this statement as a cargo cult prefix/postfix to commenting on legal issues, and if it's not really necessary, it seems more tasteful to me to leave it out.
pfffft Bunch of yammering without any good analysis. Disappointing.
The new terms don't do anything except make explicit what they were already doing.
D.7 + D.4: They were already doing activities these terms explicitly give them the right to do. They are internally copying (backups), modifying (compressing and indexing), and displaying anything uploaded. If having it spelled out violates your license, I don't see how them just doing it without having it spelled out doesn't also violate the license. Maybe this just shifts where the license violation is occurring from GitHub's doing to a user's uploading, but it doesn't change the fact that a license is being violated somewhere on either the old or new terms.
D.5: This section was already in the old terms! The new terms actually clarify and limit what they mean by "fork". It still doesn't give the forking user a right to modify, just create their own copy within the context of GitHub. You already granted users the right to "fork" anything publicly submitted under the old terms.
D.3: The rant (the writers own tag, but I find it appropriate) is just nitpicking here. It om-mitts the reason why they would remove content, which is because it violates their policies. GitHub needs this right to enforce their content restrictions. Also, if GitHub ends up removing partial content such that it violates the license it was submitted with YOU aren't the one breaking the license. They are.
I think you're right, but even if they were effectively doing these things already, it does seem likely that individual users don't actually have the ability to give permission for them (on behalf of other contributors to their repos). I guess previously we just had a potential legal quagmire that most people were happy to edge around, blithely whistling.
(edit since I didn't expect many votes, I am not a lawyer at all)
The text doesn't seem totally true, for example:
> Section D.7 requires the person uploading content to waive any and all attribution rights.
Yet, from the ToS, section D.7:
> You retain all moral rights to Content you upload, publish, or submit to any part of the Service, including the rights of integrity and attribution. However, you waive these rights and agree not to assert them against us, to enable us to reasonably exercise the rights granted in Section D.4, but not otherwise.
So you don't waive "any and all" rights.
From the article:
> Section D.5 requires the uploader to grant all other GitHub users… right to “use, display and perform” the work (with no further restrictions attached to it)
From the ToS, D.5:
> If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality.
So uh yeah, there are lots of restrictions on it. "solely on GitHub as permitted through GitHub's functionality", so they can only use Github functionality (i.e. Forking) on your content. They can't sell your content or relicense it or host it on their own website.
The only real problem I see here is that unless you created the work entirely by yourself ("you" here can mean a group), you can't grant the rights necessary to upload to Github, even if you're well intentioned or the original authors may be fine with it. And these rules apply to private repos, too. I wish the author had focused more on that.
The license to "use, display and perform your Content" isn't limited to the GitHub site or functionality. Only the "access your Content" and "reproduce your Content" are limited to GitHub.
> The only real problem I see here is that unless you created the work entirely by yourself ("you" here can mean a group), you can't grant the rights necessary to upload to Github, even if you're well intentioned or the original authors may be fine with it. And these rules apply to private repos, too. I wish the author had focused more on that.
The author did explicitly mention that. But I think it's worth listing all the issues with the ToS, not just one.
> The license to "use, display and perform your Content" isn't limited to the GitHub site
Right. If you put up your code publicly you are implicitly allowing other people to do those things, since there's nothing you can do to stop it. How could you stop someone from privately running your code on their hardware?
You're also implicitly allow people to fork and download the code, since Github doesn't allow public projects to restrict those abilities. Your particular license may restrict making further copies, though.
> Right. If you put up your code publicly you are implicitly allowing other people to do those things,
As one example, "display" isn't made contingent on attribution. As an unusual but plausible example: a GitHub user could grab a pile of code from across GitHub and render it to construct a "movie hacking UI" for a film, without even an attribution for the code they used.
> since there's nothing you can do to stop it. How could you stop someone from privately running your code on their hardware?
(Also, "nothing you can do to stop it" is not a grant of permission.)
As one example, "display" isn't made contingent on attribution.
That's fine, but in general these software licenses do not cover "display", they cover _distribution_. If you consider "using code in a movie hacking UI" to be distribution, then you would already have been bound by the license. If you don't, then you're not. Nothing changes.
> That's fine, but in general these software licenses do not cover "display", they cover _distribution_.
Yes, that means that "display", insofar as that corresponds to a copyright-protected exclusive right like performance, is not licensed by the license, and (if you aren't the original copyright holder) you have no authority to grant a sublicense to GitHub that covers display.
> Also, "nothing you can do to stop it" is not a grant of permission.
Okay, well, I give you permission to copy the words in this sentence into your brain, but you're not allowed to process their semantic content into a coherent idea. If you do, I will sue you.
> The license to "use, display and perform your Content" isn't limited to the GitHub site or functionality. Only the "access your Content" and "reproduce your Content" are limited to GitHub.
Hmmm, I see how the and can be read that way. They really need to use more punctuation in these instead of so many 'and's.
But so if they can only access and reproduce your content through Github, what constitutes use/display/perform, and in what ways could they do that? Judging by the way D.4 is written, I take it to mean things like playing an audio file or running some executable code within the browser.
> The author did explicitly mention that. But I think it's worth listing all the issues with the ToS, not just one.
Yeah, I get that they mentioned it, I meant I wished they spent more than a sentence on it because I feel that's the bigger issue.
> But so if they can only access and reproduce your content through Github, what constitutes use/display/perform, and in what ways could they do that?
IANAL, nor do I have a dog in this fight, since I prefer contracts to copyrights. However...
I think there are at least a few scenarios that require some thinking about, anyway:
Given that the TOS forces allowance of use and performance of content uploaded to Github without regard to any license you might have been bound by otherwise, it seems as though it effectively negates any other such restriction. CC BY-NC doesn't allow commercial use, but now they can just point to the implicit license they got with it because you shared it on Github, right?
The AGPL requires that modified source used to furnish a direct service must be republished. If usage of Github means that you have granted a license, separately from the AGPL, to every user of Github to use your software, then publishing AGPL software via Github seems to negate the license: anyone who has it and who got it using Github may use it to run a server and need not follow the terms of the AGPL to do so.
But this leads to problems with other restrictive licenses as well, such as the GPL, since as long as someone is only distributing your software via Github, they have a license to reproduce it without regard to other terms like modification of source, and other Github users have a license to download and use it.
Even if we see it as a granted license, separately from the AGPL, it would be "solely on GitHub" that people can enjoy those permissions and the permission do not allow making copies that leaves github.
This would of course not work if github became in future a hosting service where people could run projects as services on their platform.
If you set your pages and repositories to be viewed publicly, you hereby grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality. You may grant further rights if you adopt a license.
There seem to me (remember, IANAL) to be three rights granted here to each user of github:
1. to access your Content through the GitHub Service,
2. [and] to use, display and perform your Content,
3. [and] to reproduce your Content solely on GitHub as permitted through GitHub's functionality.
The second right is not limited to "on GitHub". Therefore, if your content is anything that can be used by linking, such as an image, javascript, etc, you're granting each github user the right to use that on their site.
From the pushback on this point here and in other comments, I wonder if people are parsing this as
1. a nonexclusive, worldwide license to access your Content through the GitHub Service,
2. and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality.
...which seems wrong to me. If that were the intent, then I think it would have been easier to say
[...]through the GitHub Service, and to use, display, perform, and reproduce your Content solely on GitHub as permitted through GitHub's functionality.
In that way, usage, display, performance, and reproduction rights would be connected to "solely on GitHub".
I agree that the wording is odd if as you say they intended it to only be "on github", through there is one problem. The rights granted by 2 can't be used in isolation from 1 and 3.
If you ran the program locally by accessing the content through the GitHub Service, without reproducing the content, 2 should grant you the right to use, display and perform the content. I don't see how you could do that using anything requiring a linker, but I can see how agpl javascript could be in danger if script tags on a website can be linked directly to a file on a github. In that way the content is "access through the GitHub Service", used locally by the browser, but depending on legal theory, not reproduced.
In the general case however it is hard to use, display or perform content for which someone can't access or copy.
>> If you set your pages and repositories to be viewed publicly
This is the same non-story that goes around any time someone reads the terms of service of twitter/facebook/dropbox/etc. These services need some license grant to do what you want them to do.
Note that any OSS license fulfills the requirements. I always assumed a free license was a requirement anyway. If that's the case, nothing really changed.
Section D7 seems to specify that they're talking about moral rights. I understood these to be intrinsic rights in some legal environments, e.g. France, that were distinct from anything that any open source licence might insist on. (As an aside, in the UK there are sadly no moral rights in computer programs, the only one that should apply being expressly excluded in sec 79 of the Copyright Designs & Patents Act 1988)
I'd like to point out that taking exception with "the right to “reproduce your Content solely on GitHub as permitted through GitHub's functionality”" means you were probably already not using GitHub, since that literally describes what happens when someone clicks the "fork" button.
Especially given that the actual EULA text is this: "If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality. You may grant further rights if you adopt a license."
(There also seems an odd confusion between "illegal" and "in violation of the terms of service", which are very different things indeed, but that's less crucial to examining what the terms actually say you can, and cannot, do on GitHub)
U.S. courts have repeatedly (see eg. US vs. Nosal & US vs. Drew, both linked in the pages you cited) ruled that ToS or acceptable-use violations are not criminal offenses under the CFAA. In their opinions, they explicitly argued that criminalizing breaches of contract would violate widespread public knowledge of the difference between a contract & a law, and would make the CFAA unenforceably vague. It's pretty likely that Aaron would've been acquitted had the case gone to trial.
yes? no trial was held, for the most unfortunate of reasons, but if it had it would not have been based on an "an EULA violation" alone. The court would not have been able to accept the case as EULA violations are not criminal offenses in and of itself.
Much of this seems to be safeguarding Github from legal issues related to their internal handling of the data the repository: reproducing without attribution is necessary for internal search, integrity of source will be violated by search and backups (which might partition the source on the backend), and conditions of "use, display, perform, and reproduce" were already issues before -- essentially depending on users to obey the license rules -- all that changed is that Github is legally requiring your permission to do these things.
Honestly, to me, these signify more of a problem with either a) legal interpretation of these licenses or b) the licenses themselves. The things that Github wants to do with your code are perfectly reasonable, and I don't think would be interpreted as "breaking the license". All code is attributed to you when displayed to other users and isn't being broken up in its distribution (unless you believe that only viewing a single file is breaking up the source code... which is just silly) in practice.
I really don't view this as a problem. I think fighting any of these issues against Github (without this ToS) in court would likely be very difficult and unfruitful... but the risk makes it necessary for Github to protect themselves anyways.
> Much of this seems to be safeguarding Github from legal issues related to their internal handling of the data the repository: reproducing without attribution is necessary for internal search, integrity of source will be violated by search and backups (which might partition the source on the backend), and conditions of "use, display, perform, and reproduce" were already issues before -- essentially depending on users to obey the license rules -- all that changed is that Github is legally requiring your permission to do these things.
It's relatively normal for a site to claim a permissive license for the purpose of implementing site functionality, such as transmitting, displaying,
rendering, or backing up the content. It's far rarer for a ToS to claim a permissive license for arbitrary other purposes, let alone grant that license to every other user of the site. The ToS changes here grant such a license to all GitHub users, and not just to use site functionality (e.g. hitting the "fork" button).
The few other times I've seen a site attempt to claim such rights over user-submitted content, it has resulted in a backlash just like this.
>The ToS changes here grant such a license to all GitHub users, and not just to use site functionality (e.g. hitting the "fork" button).
Sure. But if you have code that has a licence that doesn't allow that... you shouldn't be putting it on Github.
This is the clause you are referring to "If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality." The key words here are "solely on GitHub as permitted through GitHub's functionality." This doesn't appear to be giving users license to do anything with the code off GitHub's site.
That is, at best, ambiguous and in need of clearer drafting. The author of the article linked here, and others, are reading the "access" and "reproduce" as only for GitHub, but the "use, display, and perform" as granted to each User of GitHub and not just for use/display/performance through the site itself.
The ideal scenario is that the concerns are all drafting errors or otherwise missed details, and can be fixed via clearer drafting of a new version. I don't think there's a systematic intent here to undermine FOSS licensing, just a set of mistakes that didn't take such licensing into account very well.
Sharing code is pretty central to Github's public repositories, so they're in a different position than, for example, flickr or facebook, where other users are primarily consumers of your creative works.
That being said, the license grant Github asks for ("use, display, perform, and reproduce") seems to be a minimal set that is part of any OSS license anyway. It doesn't elaborate on any terms of such a license, but from the context it's clear that GPL/BSD/CC/etc. are considered acceptable (see for example the mention of "granting additional rights via license" which links to an overview of these licenses).
Licenses don't just grant additional rights; they can also set conditions on the exercise of those rights, such as attribution or copyleft. This ToS doesn't acknowledge any of those conditions.
>Licenses don't just grant additional rights; they can also set conditions on the exercise of those rights, such as attribution or copyleft
Usually the right being exercised is that of copying, not merely using; for example, assuming that running a program is a form of use, the GPL does not set conditions on using (or displaying or performing)[1]; are there any copyright licenses that do restrict activities other than distribution?
I don't really see any serious issues with the new terms of service.
As they say, when you upload some code to Github (or any other service or website), they are making a copy, and then more copies for backups. If the code is visible to other users, then they are distributing it to other users. If the code is searchable, then they are taking out and distributing little bits of it.
Github needs a legal basis to do all these "obvious" things - and so would every hosting service.
If LPPL requires the integrity of the author's source code, then it's not just incompatible with Github's ToS, its incompatible with all search engines that show snippets of results.
Is there anything that they are asking for in the new ToS that they have not been already doing by running the website, and everyone being okay with when they upload code?
The possibility that a Github TOS change could force a change to the license of your software hosted there, and that it's complicated enough that I'd have to hire a lawyer to know for sure, makes Github not worth bothering to use.
Vaue proposition was never very high for me, and went negative.
I can only speak for myself. Amount of value others place on the copyrights to the software they've spent blood sweat and tears building is up to them.
It's submissions like this that demonstrates the extent to which user-contributed news aggregators are amplifiers for the prior assumptions—and obsessions—of the users doing the contributing.
My personal favorites are stories of the form "I don't like this Apple product, so Apple has lost touch and is doomed. Not that I've laid hands on the product. But still!"
But this one, an instance of "I have discovered the hidden-in-plain-sight plot by a popular service to commandeer your intellectual property!" is pretty good too.
GitLab's indemnification is mentioned in the article "Gitlab seems to not have such, but requires you to indemnify them… YMMV. I think I’ll self-host the removed content."
They could have avoided the bulk of these problems by the following:
5. License Grant to Other Users
If your project doesn't have a license attached, then the rights you provide GitHub and users are as follows:
You agree to allow others to view and "fork" your repositories (this means that others may make their own copies of your Content in repositories they control).
If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content.
Choosing a License for the repo supersedes the above rights declaration and reverts completely to the License of your choice.
___________________________________________
There's cases where I'm using someone else's GPL3 code. Im using it because of the GPL and am granted rights. I can't comply with the "rights" GH wants because I don't have them to give.
I also have projects that I'd like to share as GPL, but not as BSD or MIT. My choice. The existing version grants GH an effective BSD license for everything on there.
They would have avoided most of the complaints, but I'm sure their lawyers would never have approved such ToS.
It would mean that github is responsible for analyzing each license and what features they can provide for code under each license, and take the risk of potentially defending their understanding of each license in court if other people disagree. It would also mean that if someone illegally changes the license file on someone else's project and then uploads it to github, then github is at risk instead of the uploader.
A better solution would be to describe the features they provide for public repos in detail, and require uploaders to pledge that the license is sufficient to grant these rights, or that they grant the rights themselves.
So people suggest moving to gitlab, what about bitbucket? it also offers free repositories. What makes Gitlab better. Ultimately centralising all the opensource in one service is a bad thing for opensource in general. Github shouldn't become the "defacto" custodian of opensource projects. It's like today the internet is "distributed but heavily centralized in one place". Look at the S3 outage recently, taking down half the internet.
I just created a project using CC4.0 last weekend and I noticed that GitHub didn't have it in the list of suggested license you can choose. When I added it manually, GitHub did recognize it which I thought was awkward. It seems like GitHub is already trying to steer users away from creating the types of repositories they don't want to support in the TOS.
Depends on what kind of project you're working on. Creative Commons is not especially appropriate for software licensing, so it's perfectly sensible for GitHub to avoid recommending it.
This isn't just my personal opinion, by the way. The CC FAQ specifically says:
> We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. We recommend considering licenses made available by the Free Software Foundation or listed as “open source” by the Open Source Initiative.
As far as I can tell this is simply false. At https://creativecommons.org/retiredlicenses/ there is a list of "retired" (deprecated) legal tools, which does include a "Public Domain Dedication and Certification" but in the right column says "Replaced by two separate tools: the CC0 Public Domain Dedication and the Public Domain Mark." Furthermore, at the top of the page it says "CC will no longer offer these licenses via its license chooser or other mechanism for any future work" and if you click on the link (https://creativecommons.org/choose/) there is a "Want public domain instead?" link to https://creativecommons.org/publicdomain/ which prominently features the CC0 dedication.
I actually read through the OSI mailing list thread about the CC0 dedication once, and as far as I recall the OSI people (I think it was Bruce Perens) had reservations and eventually the CC side decided it wasn't worth pursuing, see https://opensource.org/faq#cc-zero for the OSI summary.
No, your comment is complete FUD. Even a cursory skim of that blog post, you can see it's about a completely different issue in the TOS and does not discuss the issues this post is about at all.
Yes, it doesn't, because the thing the blog post talks about is a non-issue -- it instead focuses on a much more minor issue (why would it do that if there was a larger issue that was this bad?).
It's also corroborated by other lawyers in the thread saying basically the same thing though. My conclusion that the blog post is FUD doesn't solely derive from the post I linked to.
> there was a review phase, but my reviews pointing out the problems were not answered, and, while the language is somewhat changed from the draft, they became effective immediately
I find this disturbing.
Also, although extremely unlikely, I would imagine Github finally panicking upon a large exodus of high-profile FOSS projects.
It's sad, but given the (positive, don't get me wrong!) response to the Dear Github letter from a while back, it seems that mass outrage is the only thing the company understands.
Most companies are allergic to lawyers. As in, they'd rather avoid the issue outright and go elsewhere if a hint of a legal question comes up. The fact that they didn't bother floating this change by the greater community at large does not give me the warm fuzzies that they learned their lesson.
They actually had a review period, and did some good changes.
But then, they took a week to look at the reviews (ostensibly; I, as well as others, never got any response to them), went and made some minor changes (which were not enough to address the problems at all) AND BROUGHT THE CHANGED DOCUMENT INTO PRODUCTION RIGHT ON THE NEXT DAY, without any further review or warning. That’s like bad.
So, let's just assume for a second that the author's comments are all completely correct. Then it's still not a good analysis, since it doesn't say at all how these rules came to be and what they try to achieve. I don't think Github's management is so broken that they would F up their core users' businesses for no reason.
It is important to understand it from a progressive point of view, since any compromise would also require Github's needs to be fulfilled at least to some degree. It would also help understand that the author may actually be wrong in his assessment. And last but not least you're just painting half a picture if you just mention your own arguments. Makes your arguments way less convincing.
“how these rules came to be and what they try to achieve”
That’s not my point here.
The intent behind the rules and what they’re trying to achieve is GOOD and A STEP UP from the previous ToS.
HOWEVER, they have language that IS problematic for almost ALL copyleft and/or attribution-requiring works that include contributions from people who did not upload it directly to GitHub themselves. THAT’s what I’m discussing.
Just wanted to expand a bit more on the knee jerk reaction of suggesting GitLab.com. From what I know from their business, GitLab.com is a loss leader and they make their money primarily from the enterprise self-hosted product. Please keep this in mind because this is important. No service is a charity and GitLab.com will always be their low priority. GitLab.com is not magically immune to problems that GitHub.com faces in terms of license. Once GitLab becomes big, you will see the same things all over.
To conclude, I suspect you are better off just self-hosting GitLab (just pay them license fees). It's really just 3.25 per user per month, please support their self-hosted instance.
Hi, Lead FE @ GitLab. When my team and I are developing, we spend a majority of our time, writing code for the community edition (the open source and free version) of GitLab. Also GitLab.com is a priority.
We want to be the platform where everyone can contribute, and that necessarily includes having a great GitLab.com Our strategy [0] page goes into more details there, including our business goals sequence [1] to be the preferred platforms for private repos, then public repos within a few years.
Hey, I was just looking over the GitLab product page[0] and it looks like there might be a small issue with the FAQ:
Under the "Can I add more users to my account" faq it indicates that additional users would be billed at 50% upon renewal, while the following question "The True-Up model seems complicated" indicates that additional users would be billed at full price.
I'm not in the market right now, but for people that are this might be a bit confusing.
You can also run the open source version of GitLab on your own hardware for free. Gitea is also quite good if you don't need the more advanced functionality that Gitlab provides - for basic git and issue tracking it's good enough.
If you want to spend money on things and you're a small team also consider Atlassian's JIRA $10 for 10 users plan. JIRA might be overkill for small projects, but if you want nice agile project management tools it's pretty good.
I generally agree with the statement, but just throwing other tools around - not necessarily just for open source development.
JIRA isn't much worse than GitLab EE license wise - both will give you their full source under a license that you can't do much with it. The only difference is that part of GitLab is available under a better license, but it's not the version you're running if you run EE.
Depends how much you're relying on it I suppose. For even a small business I'd definitely recommend it, but for my personal usage - eh, I'll use whatever's available.
I'm cheap and I don't personally care that much whether they last so long as there's other options available. I wish them the best, but I'm not going to cry over porting some issues to a different system in the worst case.
Dear moderators, please fix the headline. This is IMHO turning into clickbait. The linked article is wrong in many ways, as lawyers have explained in the comments here.
Please stop this misinformation from spreading further. Please.
For those that think this is a problem, is there a ToS and license that everyone would agree gives Github and users the legal right to do what they do today that is compatible with all the OSS licenses?
Yes, that’s actually what GitHub and I are talking about now.
Any OSS licence already grants way enough rights for a hosting platform to operate, period. Anything else can be solved technically and does not need to involve legalities. (For example, when displaying search result snippets, put notices pointing to the original file in the original repository, as “context, complete copyright notices, licence and attributions” right next to each.)
So the ToS simply need to require all those grants only for works that are not under an OSS licence (see also my updated article, remember http://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm is the correct link, NOT the one on top). For any works NOT under such an OSS (Open Knowledge, Free Cultural Work, whatever) licence, the ToS grant is not unjustified to ask (especially as GitHub doesn’t care about hosting OSS projects, or the licences of whatever content they host).
Github has a contact form: https://github.com/contact - Here's the love letter that I just sent them if you need something to copy-paste.
> The internet just told me about the updated ToS and its potentially disastrous effects on the legal certainty of thousands, if not millions of open source contributors. I demand you adjust your ToS to ensure that users can be safe that they will not get into legal trouble by sharing open-source code and artifacts on Github.com. If you fail to provide me with sufficient legal certainty in this matter, I'm prepared to move my source code to other providers or to my private premises.
> Since my employer, $name, is also a paying user of Github.com, I will also refer to my employer's legal department to check which legal concerns could arise from my continued use of Github.com for work purposes, and take appropriate action.
As discussed elsewhere in these comments, "the internet" has most likely misinformed you of the actualities of this license change. It seems premature and unnecessarily aggressive and demeaning to "demand" things from GitHub based off of probably invalid assumptions.
Off topic, but why is GitHub trying to direct potential Homebrew users to the correct contact forms for that project? Is Homebrew sending people to the GitHub contact form for troubleshooting or something?
Someone intelligently (hah) decided to link to the (1 MiB) page with the entire wlog posts of the last decade (plus CSS, webfonts, …) instead of to the permalink of the one article (15K), and then over https.
The webserver is a first-generation Celeron 2.4 GHz (Dell PowerEdge 750, AIUI) with 1 GiB of RAM, running MirBSD (not the fastest OS out there) with Apache. So, no surprise.
Yes, one of _those_ Celeron CPUs with so few L2 cache it can be discounted as having none.
For that, it does remarkably well (though 「ls -l /var/www/logs/」 surely shows the traffic ).
The new Terms of Service of GitHub became effective today, which is quite problematic — there was a review phase, but the problems were not answered, and, while the language is somewhat changed from the draft, they became effective immediately.
Now, the new ToS are not so bad that one immediately must stop using their service for disagreement, but it’s important that certain content may no longer legally be pushed to GitHub. I’ll try to explain which is affected, and why.
I’m mostly working my way backwards through section D, as that’s where the problems I identified lie, and because this is from easier to harder.
Note that using a private repository does not help, as the same terms apply.
Anything requiring attribution (e.g. CC-BY, but also BSD, …)
Section D.7 requires the person uploading content to waive any and all attribution rights. Ostensibly “to allow basic functions like search to work”, which I can even believe, but, for a work the uploader did not create completely by themselves, they can’t grant this licence.
The CC licences are notably bad because they don’t permit sublicencing, but even so, anything requiring attribution can, in almost all cases, not “written or otherwise, created or uploaded by our Users”. This is fact, and the exceptions are few.
Anything putting conditions on the right to “use, display and perform” the work and, worse, “reproduce” (all Copyleft)
Section D.5 requires the uploader to grant all other GitHub users…
the right to “use, display and perform” the work (with no further restrictions attached to it) — while this (likely — I didn’t check) does not exclude the GPL, many others (I believe CC-*-SA) are affected, and…
the right to “reproduce your Content solely on GitHub as permitted through GitHub's functionality”, with no further restructions attached; this is a killer for, I believe, any and all licences falling into the “copyleft” category.
Note that section D.4 is similar, but granting the licence to GitHub (and their successors); while this is worded much more friendly than in the draft, this fact only makes it harder to see if it affects works in a similar way. But that doesn’t matter since D.5 is clear enough.
This means that any and all content under copyleft licences is also no longer welcome on GitHub.
Anything requiring integrity of the author’s source (e.g. LPPL)
Some licences are famous for requiring people to keep the original intact while permitting patches to be piled on top; this is actually permissible for Open Source, even though annoying, and the most common LaTeX licence is rather close to that. Section D.3 says any (partial) content can be removed — though keeping a PKZIP archive of the original is a likely workaround.
But what if I just fork something under such a licence?
Only “continuing to use GitHub” constitutes accepting the new terms. This means that repositories from people who last used GitHub before March 2017 are excluded.
Even then, the new terms likely only apply to content uploaded in March 2017 or later (note that git commit dates are unreliable, you have to actually check whether the contribution dates March 2017 or later).
And then, most people are likely unaware of the new terms. If they upload content they themselves don’t have the appropriate rights (waivers to attribution and copyleft/share-alike clauses), it’s plain illegal and also makes your upload of them or a derivate thereof no more legal.
Granted, people who, in full knowledge of the new ToS, share any “User-Generated Content” with GitHub on or after 1ˢᵗ March, 2017, and actually have the appropriate rights to do that, can do that; and if you encounter such a repository, you can fork, modify and upload that iff you also waive attribution and copyleft/share-alike rights for your portion of the upload. But — especially in the beginning — these will be few and far between (even more so taking into account that GitHub is, legally spoken, a mess, and they don’t even care about hosting only OSS / Free works).
Conclusion (Fazit)
I’ll be starting to remove any such content of mine, such as the source code mirrors of jupp, which is under the GNU GPLv1, now and will be requesting people who forked such repositories on GitHub to also remove them. This is not something I like to do but something I am required to do in order to comply with the licence granted to me by my upstream. Anything you’ve found contributed by me in the meantime is up for review; ping me if I forgot something. (mksh is likely safe, even if I hereby remind you that the attribution requirement of the BSD-style licences still applies outside of GitHub.)
(Pet peeve: why can’t I “adopt a licence” with British spelling? They seem to require oversea barbarian spelling.)
The others
Atlassian Bitbucket has similar terms (even worse actually; I looked at them to see whether I could mirror mksh there, and turns out, I can’t if I don’t want to lose most of what few rights I retain when publishing under a permissive licence). Gitlab seems to not have such, but requires you to indemnify them… YMMV. I think I’ll self-host the removed content.
Nope, I'm not. But plain language in a ToS or contract is pretty easy to go "Nope, I don't like that. I don't agree."
And I'm sure they consulted their legal team regarding this. I don't think I would have to get an attorney on retainer to go "That doesn't look right."
Is it mostly harmless? Probably. But in cases where I'm the creator and set the license to GPL3 Affero, I expect that everyone follows that. I'm not going to grant exceptions unless they pay me.
Any reasonable reading of these ToS will lead to the conclusion that they're merely asking for a minimal license grant necessary to provide their service. Maybe GH will add a sentence to appease the hair-splitting armchair-lawyers, but the speculation is no different than the 100 other, identical conspiracy theories targeting any other service with user-generated content that have made the rounds in the last decade.
Or the people who asked actual lawyers, and got as a response that this is something that’s very risky.
I’ve got code in my repos from third parties under the explicit condition that I can only distribute it with attribution, so I can’t give GitHub the right to distribute it without attribution in search results.
I can’t grant GitHub rights that I don’t have, what they’re asking of me would require me to do the equivalent of "I’ve got a bridge to sell you".
FWIW we're in the process of building https://eversentinel.com/ to monitor ToS changes. It's in beta so we're still adding services but will definitely be adding GitHub
Github doesn’t, it just requires that of its users (that, or to not upload any copylefted works, or works under licences requiring attribution, which contain work from people who have not agreed to waive those requirements for Github).
If Github can continue to use and distribute free software without violating the terms of the license then why demand additional rights? I don't get it.
Google doesn't attribute links to free software appearing in it's search results. Github doesn't need special rights to do it.
Sorry about that, I was more concerned with getting the explanation into more than 140 chars and out to both people and GitHub and getting in touch with GitHub than with writing a lengthy article.
And all this besides $dayjob which suffered on the day, so I’ll probably need to work the weekend to catch up.
Be that as it may, without an extended analysis of the possible multiple interpretations and conflicts with copyleft, it leaves the author looking somewhat shrill.
I am the author. And I am not an academic interested in bringing out a lengthy article with explaining the interpretations and all.
I am, in this instance, pragmatic: explaining what’s bad, why it’s bad, what we need to do right now, and that’s it, and now I’m trying to work on a solution with the GitHub people.
If this is not enough, do your own research. In my referrers, there have popped up some Russian sites that (according to Google Translate) did some of their own research (and came to similar conclusions). Ex-Debian’s joeyh did, too.
Are you using a self hosted GitLab? I feel that GitLab would have the exact same issues that GitHub has. The TOS are just clarifying what is required to run a cloud source code repository. If they want to do things like index the code, run tests on it, fork it to other users, show it on their website, then they need certain permissions from the copyright holders of the code. These permissions are not special to github I don't feel. Anyone with the same set of features would require the same permissions.
The contract states that I have to effectively grant them a BSD license for whatever I do there. Then open source licenses can stack on others' as I choose.
Nah. Not worth it. If I want it as GPL3, I expect them to comply with GPL3.
> I'll move on to things like GitLab or IPFS for transmitting projects I'm working on.
Or NotABug (https://notabug.org) which is a lot more friendlier toward open source projects. IPFS sounds good, I'd love to see something P2P in this space, but nothing P2P seems to be mature enough.
Nothing wrong with gitlab, I personally use their self-hosted product. But just a reminder to all that they lost a bunch of data 1 month ago today [0].
However they were completely open and transparent about what happened, and they handled it as well as they could have.
Also to be clear GitLab (apparently) didn't lose any data actually stored in git from that timeframe, "just" the data stored via GitLab itself (issues, wikis, etc).
It's of course still bad because GitLab makes a big deal of being about the "whole package" rather than just version control, but it's not the massive potential for intellectual property loss "six hours of data" implies for what most think of primarily as a git hosting service.
Not quite. I coincidentally signed up for a GitLab account that very day, at that very time period, to make a minor change to someone else's project. I (1) set up my account, (2) forked their project, (3) made the change, and (4) issued a pull request. Came back the next day and none of that was there, including my forked git repo. I had to do it all over again, and it was clear it was a clean wipeout of everything, because I was allowed to re-register with the exact same userid, etc. I know that is a rare-snowflake event, but the fact I had a repo and had even sent a pull request from it shows they did, in fact, lose some data in git itself.
The git data itself was untouched, but in the eyes of the DB there was no project that got created due to the lost DB data, so the git repo isn't hooked up. If you can give me the username and project name I can have support fix it up for you.
If you don't want to do that in this thread, feel free to email me: connor at gitlab.com
gitlab is a very good alternative... but i think that porting of a working project (not just code) is still complicate to accomplish. Manually import items like:
- issues
- projects
- users
it is very expensive in terms of operation.
I know that there are products, libs and API to, let say, mirror your repository, but all those tools, after you dive into some READMEs, are just not enough.
BTW: if anybody knows how to do "1 to 1" porting from github to gitlab i will appreciate it
Also worth noting is that you can configure a recurring one-way sync to periodically bring the slave repo up to date; this is useful for giving Gitlab a try while not committing to leaving Github as your primary hosting service.
These legal issues are real and no amount of running away and ignoring them will resolve them.
This is an intractable part of open-source software development. We can piss all over GitHub for trying to figure it out and getting it wrong, but at least they're trying.
As far as I can tell: no, unless GitHub takes taking excerpts from works too far and redistributing them without the licence attached. But nobody else is allowed to deal in those excerpts then, except via the original licence, so, likely not.
But 4-clause BSD and similar advertising clauses are _probably_ affected, and Apache 2 _when_ a NOTICE text file exists is _very likely_ affected. (Maybe even without; the Apache 2 licence requires giving recipients a copy of the licence text, too.)
Regarding "Maybe even without; the Apache 2 licence requires giving recipients a copy of the licence text", doesn't the BSD 3-clause license require this as well?
BSD/MIT/etc. only require the licence text to be present, usually by retaining it in the source code or accompanying documentation. Yes, it’s close. No, I don’t want to go there and discuss this detail.
As I see it the underlying issue is that Github doesn't want the GPL of one customer's project to attach to github itself, or to other projects hosted on Github.
I think that's a fair goal for Github to pursue - maybe they didn't get it right this time (IANAL) but I think we can all work with them to get something that makes everyone happy, hopefully with less heat and more light
Disclaimer: I have GPL and LGPL code and hardware hosted on Github
If it's all your code or code from other Github users, you're probably fine. The ToS constitutes an additional license agreement which you can make since you're the copyright holder of your own private creations.
Of course, even if you don't infringe on other people's rights, there's also the question whether you're okay with these ToS.
But, thanks to the new ToS becoming effective immediately (as of 28½ hours ago), you do have to act.
Basically, starting March 2017, uploading anything (new) like that is not allowed. Removing repositories and/or the entire user account, to make it explicit that such grants are not given for what’s already there, may be prudent (yes, overreacting is not necessary, but acting is, and don’t talk legal requirements down to overreacting, because if you DO upload a GPLv2’d work to Github as things are now, YOU lose the right to use it under the GPLv2 in the first place and CANNOT get it back except from the (all!) authors).
For example, my informal and cursory analysis of the article:
> Section D.7 requires the person uploading content to waive any and all attribution rights.
It does not. The Github license requires a waiver of the requirement of attribution insofar as such waiver is needed for Github to do what it already does e.g. as the license indicates, provide search results without attribution.
Further, only Github has been given this waiver. Anyone else is still held to any requirement of attribution.
> section D.5 requires ... the right to “reproduce your Content solely on GitHub as permitted through GitHub's functionality”, with no further restructions attached; this is a killer for, I believe, any and all licences falling into the “copyleft” category
While D.5 does permit performing, using, and displaying of a work, it permits reproducing on GitHub only. Any copying from GitHub not granted by way of another license would be a violation of the author's copyright.
Use, performance, or displaying in the absence of a right to reproduce strikes me as a rather narrow set of rights.
I stand to be corrected, but I see nothing sinister, nefarious, or unwarranted by GitHub.
YMMV. If you need legal advice, retain a lawyer.