Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Almost Everything We Do Will Be Open

about.gitlab.com

Post reply on HN
Print view View original

171–180 of 208 posts

Re: Almost Everything We Do Will Be Open

#171

Post by scrollaway »

hk__2 wrote: post #131
scrollaway wrote: post #62

Earlier quoted context omitted.

I'm not sure you can fix it unfortunately but the number 1 thing I would miss is the community . I work with a lot of open source projects and the consistency and speed at which I can file bugs, fork repositories and pretty much do anything is really important, and the access to all the github users is a major part of that. -- OK, this post was going to be some minor thoughts but turned into actual UX/dev feedback. T…

> SSL support for gh-pages on custom domains is lacking How could they do that? You’re responsible for your own domain, you have to buy an SSL certificate by yourself.

It's not supported.

Re: Almost Everything We Do Will Be Open

#172

Post by nadams »

sytse wrote: post #146
nadams wrote: post #136

Earlier quoted context omitted.

Distributing a patch would require distributing parts of the original code (the patch file will include lines of original and changed code) - which the latter is not allowed per the license. I'm not saying that gitlab would go after you for just distributing a patch - but if anyone gobbled up gitlab cough Oracle cough I'm sure they would summon a swarm of lawyers at your doorstep.

If you have any suggestions how to word this better I'm open to them. We did have a lawyer look at this. It is like sampling, you can use a bit but you can't use it all.

Well for starters most licenses will define the meaning of the terms in question. You should define exactly what is a patch file (such as format and what it contains). Potentially a patch file could include whole files.

Here is a hypothetical situation: what would you say if I included your entire program in a patch file. If you are saying patch files that contain your code are ok to distribute - but I'm sure you are going to say that's not ok. But why not? Your license says I can distribute patches - it just so happens this patch file contains every file in your program.

The question here is how much patch file is too much? Is there a limit?

A better idea would be to require your sign off on every patch. Or only allow patch files to be uploaded to a forum that is accessible to enterprise only customers (vBulletin has a similar setup).

Re: Almost Everything We Do Will Be Open

#173

Post by sytse »

nadams wrote: post #172
sytse wrote: post #146

Earlier quoted context omitted.

If you have any suggestions how to word this better I'm open to them. We did have a lawyer look at this. It is like sampling, you can use a bit but you can't use it all.

Well for starters most licenses will define the meaning of the terms in question. You should define exactly what is a patch file (such as format and what it contains). Potentially a patch file could include whole files. Here is a hypothetical situation: what would you say if I included your entire program in a patch file. If you are saying patch files that contain your code are ok to distribute - but I'm sure you are…

In contracts most terms are not defined. This allows the judge to interpret them according to their common meaning, for example https://en.wikipedia.org/wiki/Patch_(computing)

I don't think most people will consider an entire program a patch.

Having us sign off on every patch defeats the intent of the clause. The intent is to give our customers a way to submit merge requests on https://gitlab.com/gitlab-org/gitlab-ee/merge_requests and to be able to comment on for example Stack Overflow with fixes they made so other customers can learn from that. We don't want to slow down that process.

Re: Almost Everything We Do Will Be Open

#174

Post by hobofan »

skyraider wrote: post #72

GitLab Enterprise user here. GitLab's open-source policy is one of the major reasons we chose it (along with self-hosting and fairly modern, built-in continuous integration), but the GitLab community could use some additional design and documentation effort. Things that almost make me want to switch back to GitHub: - GitLab is really hard to look at. All of our devs are having trouble visually locating comments in di…

> And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.

Why not? We are doing DinD testing on gitlab CI and it works great.

Re: Almost Everything We Do Will Be Open

#175

Post by technomancy »

ojanik wrote: post #48

Coincidentally, I just installed GitLab to try it out for our small team to replace BitBucket + Jira. And while its more than capable filling Bitbucket shoes the issues subsystem is probably worse than github's and nowhere near flexible as jira. Most notably: Missing more sophisticated workflows. Search for issues using multiple labels. Search for issues across multiple projects. We would also love to be able to do s…

After my experiences with Jira, "nowhere near as flexible as Jira" sounds like high praise.

Re: Almost Everything We Do Will Be Open

#176

Post by technomancy »

hikarudo wrote: post #91
p0nce wrote: post #78

Earlier quoted context omitted.

Precisely the one reason I can't bother to use it for real: I'd like the source tree to be the default view.

Settings -> Repository details -> Landing page -> Source

On an unrelated note, I gave up on GitLab last year because the landing page always showed recent commits instead of the readme, making it less welcoming to new users who just want to see what the project is about.

I'm glad to see they have changed this; navigating to a GitLab project now shows you the readme. Definitely going to give it a long hard look to see if I can switch again.

Re: Almost Everything We Do Will Be Open

#177

Post by nadams »

sytse wrote: post #173
nadams wrote: post #172

Earlier quoted context omitted.

Well for starters most licenses will define the meaning of the terms in question. You should define exactly what is a patch file (such as format and what it contains). Potentially a patch file could include whole files. Here is a hypothetical situation: what would you say if I included your entire program in a patch file. If you are saying patch files that contain your code are ok to distribute - but I'm sure you are…

In contracts most terms are not defined. This allows the judge to interpret them according to their common meaning, for example https://en.wikipedia.org/wiki/Patch_(computing) I don't think most people will consider an entire program a patch. Having us sign off on every patch defeats the intent of the clause. The intent is to give our customers a way to submit merge requests on https://gitlab.com/gitlab-org/gitlab-ee…

> In contracts most terms are not defined.

The GPL is one that I know that spells it out [1]:

> This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".

> This allows the judge to interpret them according to their common meaning

Uhhh....you mean the same legal system that claimed that Ron Rivest et al. were not the original inventors of the RSA algorithm? [2]

I don't know who is counseling you on legal matters but I strongly believe you should define anything that can be ambiguous.

[3] > DO define all technical terms.

[3] > DON'T assume the other party defines terms the way you do. If there is any doubt, include a definition in the contract.

[3] > DON'T accept the other party's oral explanation of a confusing term. Include everything in writing.

[3] > I don't think most people will consider an entire program a patch.

Why not? It can easily be done [4]. Example: here is a patch file to upgrade from CE to EE.

[1] http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html#SEC...

[2] https://gigaom.com/2013/11/26/troll-wins-newegg-encryption-p...

[3] http://smallbusiness.findlaw.com/business-contracts-forms/do...

[4] http://stackoverflow.com/a/9982282/195722

Re: Almost Everything We Do Will Be Open

#178

Post by nadams »

exstudent2 wrote: post #160
sytse wrote: post #157

Earlier quoted context omitted.

Where do you feel I injected politics where it didn't belong? I want to understand where you're coming from.

https://archive.is/d1Sd7 You should not have got involved in this as a company. I want to support you and do self-host GitLab but because of this I won't be a customer.

I upvoted you only because people should know where companies like gitlab stand on these kinds of issues. I'm not agreeing or disagreeing what he did was right - but it is important to know about it.

I host my own free source code hosting service and I couldn't tell you what I would have done in his position.

This question isn't meant to spark a heated debate (I'm on the fence and could argue either way) - but I'm honestly curious on how you think it should have been handled? I honestly want to know if there is an action that benefits everyone.

Re: Almost Everything We Do Will Be Open

#179

Post by exstudent2 »

nadams wrote: post #178
exstudent2 wrote: post #160

Earlier quoted context omitted.

https://archive.is/d1Sd7 You should not have got involved in this as a company. I want to support you and do self-host GitLab but because of this I won't be a customer.

I upvoted you only because people should know where companies like gitlab stand on these kinds of issues. I'm not agreeing or disagreeing what he did was right - but it is important to know about it. I host my own free source code hosting service and I couldn't tell you what I would have done in his position. This question isn't meant to spark a heated debate (I'm on the fence and could argue either way) - but I'm ho…

Thank you for the upvote, I wish more people would engage in conversation vs. just downvote opinions they don't agree with.

I think the best course of action is to have a policy of:

"We don't delete repos unless required by law."

That would satisfy me as a potential customer.

I think commenting on Twitter and getting involved at all was probably a mistake unless they were going to stick with the above philosophy. All they did was call attention to the issue then delete the repo once everyone was watching.

The tweet seems like an honest mistake since I don't think they wanted to get involved with this controversy. They made it though and had to make some decision on what to do. I think they chose the most damaging option.

The staff doesn't have to personally endorse the opinions of their users and the repos they host. I wouldn't expect that of them, but they shouldn't delete repos they don't agree with.

Re: Almost Everything We Do Will Be Open

#180

Post by nadams »

exstudent2 wrote: post #179
nadams wrote: post #178

Earlier quoted context omitted.

I upvoted you only because people should know where companies like gitlab stand on these kinds of issues. I'm not agreeing or disagreeing what he did was right - but it is important to know about it. I host my own free source code hosting service and I couldn't tell you what I would have done in his position. This question isn't meant to spark a heated debate (I'm on the fence and could argue either way) - but I'm ho…

Thank you for the upvote, I wish more people would engage in conversation vs. just downvote opinions they don't agree with. I think the best course of action is to have a policy of: "We don't delete repos unless required by law." That would satisfy me as a potential customer. I think commenting on Twitter and getting involved at all was probably a mistake unless they were going to stick with the above philosophy. All…

Would you be ok with a policy of:

> We don't delete repos unless explicitly requested by law enforcement or a DMCA takedown notice.

What you said could be interpreted as "well...this repo was technically breaking the law so that's why we deleted it" - I would rather say "I deleted it to cooperate with law enforcement". And the DMCA takedown policy is required to protect service providers in the event some idiot decides to upload copyrighted material - the RIAA/MPAA won't go after the service provider they will just ask them to take it down.

Post reply on HN