The article is about the issues that will almost all be open. The complete quote you refer to is is "In fact, even our proprietary version of GitLab, GitLab Enterprise Edition, has a publicly viewable source code.". Can we be any more clear it is proprietary? We think it is notable that even the source code and issues of out proprietary edition are publicly viewable.
Perhaps it's just me, but when they said the enterprise edition was "publicly viewable source code", I assumed they just meant it was "publicly viewable", with no further rights implied.
I don't think they're really openwashing here, and the article was pretty clear to me. Besides, the community edition and CI code are both true open source.
Isn't there a slight problem with having the EE code publicly viewable?
What I mean by this is, what's stopping someone from taking code from the EE, modifying it, and including it in the CE?
On the flip side, what if a feature released to CE is too similar to code in EE, even if the author of the patch never read the EE code for inspiration? Would GitLab be within their rights to stop it?
With these issues in mind, it makes more sense to me to have the EE code available by request only.
That's not the definition of "open source", that's the definition of "free software". As you can see by this very article, "open" and "free" are not the same.
The only difference is their argument. Free software uses ethical arguments, open source denies ethics altogether and uses consequentialist arguments related to business value and technical superiority (which are becoming increasingly criticized).
Yes. Because of the ethical standpoint, free software inherently opposes DRM, Tivoization, "trusted computing" and software patents, whereas open source in general has no intrinsic view on them.
It's far from irrelevant. Free software advocates are clear: proprietary software is unacceptable, in any form, for any reason.
It has nothing to do with being ungrateful. We express our appreciation when software is liberated, or when developers/companies are working toward it. But it does not change the fundamental philosophy.
Irrelevant to you perhaps. But please don't tell people to shut up. What you say can also be regarded as whining btw - you mean good, I think, but this just won't help one bit. Better to participate constructively than to express this type of annoyance.
But that's the enterprise license, not the community license.
When they say "In fact, even our proprietary version of GitLab, GitLab Enterprise Edition, has a publicly viewable source code", I don't think they're implying it's open source.
> You are free to modify this Software and publish patches.
> It is forbidden to copy, merge, publish, distribute, sublicense, and/or sell copies of the Software.
You might want to get a lawyer on the phone - because that seems contradicting to me. This is why you should stick with open source licenses that have been vetted by a team of lawyers already. You should check out the AGPL license.
It doesn't matter which product it was for - it still seems contradictory. It says I can distribute patches but then it says I can't.
I wasn't joking when telling you that you should get a lawyer on the phone. I've seen a number of people try to write their own software license - and fail miserably. It really has me kind of worried that your response wasn't "we did consult with a lawyer when creating that license".
In what way does it seem contradictory? It seems to allow one to write and publish patches, while disallowing the redistribution/resale of the original code.
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 coughOraclecough 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).
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.
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.
Just as an aside - we seem to be crossing paths a lot on here...
I think you should just hire me as your PR and/or developer guy ;). It's always good to have a guy with a different perspective who thinks and plays outside the box. I mean inside the box is so boring....
> I do wonder how would you define the patch file?
Something like....
> A patch file contains the modified file name, author of the change, date, hash with snippets of content recording the changes. A patch file cannot contain enough information to reconstruct the software in whole or modify the CE to include copyrighted features in the EE edition. The author must not knowingly introduce backdoors, exploits, or other code that introduces malicious intent. If the author is identified their gitlab EE license will be revoked irrevocably and permanently and requested to halt any use of gitlab EE.
(However - a patch may still introduce features from the EE edition that were written with original code)
> A patch may be released under whatever license or agreements the author wants without the requirement for permission from Gitlab if it satisfies the previous conditions.
It might be good to add a clause:
> By applying a third party patch you agree to not hold Gitlab liable for any damages or misconfigurations that might happen by applying the patch. You acknowledge by applying a third party patch that it may fix your problem, introduce a new problem, or open a tear in the space-time continuum.
I'm sure you get the idea. I'm tired and I just watched an episode of Doctor Who - so I had to include something related to time :).
Thanks! We're hiring https://about.gitlab.com/jobs/ Our lawyer will also study this comment. I'm sure he'll discourage us from offering guaranties against tears in the space-time continuum. Have a good night.
