Hi there - yWorks CTO here. That's a dilemma we have here:

• our library is a commercial library and under a commercial (non-permissive) license

• we are happy to (and actually want to) include our d.ts file(s) in Definitely Typed/typings/whatever.

• we don't want anyone to go and use the d.ts. files other than in accordance with our license agreement

I don't see that we can put another header in there that says that this file is under some permissive license. The file contains copyrighted content and we don't want to enable "evil-doers" to scrape the contents of the documentation or actually copy our API using automated tools that crawl/process the d.ts files to recreate our APIs, etc.

Only devs that have a valid license for our libraries can (legally) benefit from the d.ts file. This means that those devs will have to agree with our license terms, anyway, so they should be perfectly fine with this license header. Only those devs who don't want to accept our license terms should have a problem with this header. But they should not be using the file anyway, so what is the problem here?

Can you please clarify? Does everything have to be under a permissive license that is in this repo? I see lots of proprietary APIs - do all of them distribute the .d.ts file in this repo under a different license than the actual project?

The license issue just popped up in the context of a general OSS scan we're doing on the DefinitelyTyped repo. We're not using yFiles, but still I believe you cannot include a "proprietary/confidential" piece of code into a project that is otherwise licensed under MIT, like DefinitelyTyped is. However, I'm not a lawyer, and I might be wrong here.

Are you saying you are complaining about every file in the repo that is not OSS (or that we are the only ones who have an "offending license"), even though you never ever download or use the files? You do know that in order to use the typings you don't need to clone the whole repo, don't you? Typings will just download the files that you explicitly specify and require.... So if you don't depend on our software, you will never get to see those files.

I'd say: "If you're not a lawyer and you don't download that specific file and you still want to use typings, then just go ahead and do it!" ;-)

I'm aware of the technical possibilities / constraints. But I also believe that an OSS project that declares itself as MIT licensed should not accept code contributions that are made under a license incompatible with MIT, no matter whether you could technically use only a subset of the project.

With pretty much the same reasoning I could go to any OSS project, ignore its top-level LICENSE file, copy any contained file that does not have any license header on it's own, and claim it's fine to be used commercially because it comes from a sub-directory.

Then I'd say that this project has a severe problem.

I agree with you that this is very unclear from the documentation: what is "this project" in the statement "This project is licensed under MIT". My interpretation would be (and always was) that the typings itself are "just the data" that don't have to be under MIT and the project is the framework around the actual data. It's a technical requirement that the files live in the same repository and the MIT license is "top-level". If they are OK with non-MIT licensed typings (which I hope), then they should really clarify this and explicitly state that the .d.ts files are licensed according to their specific license header, if they have a header and only if they don't there can be a fallback license (which doesn't even have to be the MIT license).

If the only other "solution" to this problem is that everything that is not licensed under MIT needs to be removed or migrated to MIT, then for us it's clear: we are going to remove our typings. We won't change the license. I believe others will have to do the same, which would be a pity.

What exactly is the "license issue" you see in our case. Where exactly do you think we (or someone else) has done something wrong?

Or is this issue actually about making the whole licensing situation of "this project" more clear?

With pretty much the same reasoning I could go to any OSS project, ignore its top-level LICENSE file, copy any contained file that does not have any license header on it's own, and claim it's fine to be used commercially because it comes from a sub-directory.

That's the reason why with bigger projects (like angular, e.g.) every single file has its own license header.

Or is this issue actually about making the whole licensing situation of "this project" more clear?

Yes (at the example of your license).

All definition files under this project are distributed under the same licence. this also applies to the npm packages under @types. the main project licence overrides any disclaimers you have in the specific files.

If the project licence does not work for your needs, I would recommend taking off your declaration file from this repo, and file a new issue for us to deprecate the matching @types package.

@yGuy DefinitelyTyped maintainer from the Microsoft side here. Let me explain what's going on and why this needs to be fixed immediately.

our library is a commercial library and under a commercial (non-permissive) license

Naturally, this is no problem whatsoever. The licensing or distribution of the underlying library is not at issue here; there are many commercial packages on DefinitelyTyped.

we are happy to (and actually want to) include our d.ts file(s) in Definitely Typed/typings/whatever.
we don't want anyone to go and use the d.ts. files other than in accordance with our license agreement

By contributing a .d.ts file to an MIT-licensed project (or realistically to the internet in general!) you have effectively waived any control over what someone does with it. You cannot, for example, write some documentation pages, put them up on PasteBin, and then claim that those files cannot be read except in ways that you approve of. I'm not making a legal argument here, simply a practical one.

The file contains copyrighted content and we don't want to enable "evil-doers" to scrape the contents of the documentation or actually copy our API using automated tools that crawl/process the d.ts files to recreate our APIs, etc.

I don't understand how this is any different from your documentation? You might not "want" someone to crawl docs.yworks.com to recreate your API surface, but nothing can be done to stop it.

Only devs that have a valid license for our libraries can (legally) benefit from the d.ts file.

This is very disconcerting. Anyone is allowed to read this file and "benefit" from it in any way that doesn't directly violated your legitimate IP claims. Where do you think the obligation originates from? No one signed a EULA to run git clone https://github.com/DefinitelyTyped/DefinitelyTyped.git.

Where exactly do you think we (or someone else) has done something wrong?

@yGuy By claiming that you've submitted a non-MIT, non-Apache licensed, confidential work to DefinitelyTyped (in clear contradiction to the repo's published LICENSE file), you've put us and everyone else in legal jeopardy. We take the submitted files and automatically publish them to the NPM @types account. Other people have automated publishing to NuGet, or other services. We are not cleared by our legal team to do this for works that aren't under a license that allows redistribution.

The header itself doesn't even specify which license they're under; how do you expect anyone to comply with an unspecified license?

AT A MINIMUM, works you submit to DefinitelyTyped must be licensed under a license that allows us to redistribute the file to NPM. You may choose between MIT and Apache as these are the licenses our legal team has cleared. On a practical level, neither of these should be a problem for you, as you do retain copyright ownership of the original work. There isn't anything either license allows that is problematic for the purposes of documentation.

If your position is that no one may read the definition files except those with a license to use yWorks software and/or developers with only certain intent, then I can only say you should not have put these files on a public repo on the public internet on an website devoted to open source. We can't "undo" the git history of these files being publicly available or the prior NPM versions.

Again, I'd encourage you to rethink your position that you cannot license the documentation under Apache or MIT license. You don't have to change the license of the underlying software to match the .d.ts. There is no license you can apply to a publicly-available file that can stop someone from reading the .d.ts file, or your public documentation, in a way that you don't like.

documentation or actually copy our API using automated tools that crawl/process the d.ts files to recreate our APIs, etc.

I just need to make this explicitly clear: You cannot invoke a legal claim against this behavior regardless of which license you publish under. No one reading your documentation website has any obligation to follow your wishes (apart from not violating your established copyright, trademark, or patent interests). If you're putting this information out there in a public forum, you cannot apply a EULA to people who read it any more than I can say "Anyone reading this GitHub comment owes me $10".

Choosing to not license your .d.ts under MIT / Apache does not change this situation; not licensing your documentation under a permissive license does not give you the ability to apply a restrictive license instead. You cannot unilaterally bind third parties to a contract of your choosing.

Hi @RyanCavanaugh - thank you for joining and thank you for your valuable input.

First things first: It was never my intent to do any harm to this project or anyone involved in this project (and I firmly believe it's not "too late", either). Also I am very sure that the guy who originally submitted the initial pull-request, nor the guy who accepted it had any bad intentions. And of course: IANAL.

Also: I don't think anyone should be in trouble right now. I would think differently if someone had removed or changed the header in our files, though, but I don't see that this is the case.

Still I think I need to disagree with you in two important points: Just because something is "available on the internet" for whatever reason, this doesn't mean that it is out of control of any licensing. With this reasoning, we would not need lawyers at all (which might be a good thing), and we would not need licenses, either. Why does this project have a license after all? Anyone can clone the repository and upload the files with a modified license or even try to sell the contents and whatnot. Just because you can do something, doesn't meant it's legal. Just because someone uploaded the sources of MS Windows someday, somewhere, doesn't mean its open-source, now, and no license applies to it anymore.

Licensing stuff is difficult. People make mistakes. In this case, I could very well argue that the pull-request should have never been accepted if the policy is really the way you describe it, here. After all it came with the "offending" header and the project received it from some random anonymous guy on the internet who claimed to have the right to upload the content. But I don't want to blame the one who accepted the pull-request. Nor do I want to blame you, the project in general, nor even the guy who created the pull-request. In fact (as far as I can, legally), I will take responsibility for any damage that might arise from this (which I am sure there will not be).

Maybe this project should make the licensing status of the contents even more explicit. Maybe they should introduce a stricter contribution policy like other major OSS projects do it on GitHub where you need to sign paperwork in order to contribute. IMHO (again I am not a lawyer, just someone who loves coding and software development) it should be possible to improve the situation by making it clear that files in this project may be used for "the purpose of this project" and unless otherwise noted in the files, the MIT license of the project also applies to the "data", making it possible to have a different license in effect for the case when people actually use the files in question in the context of the software development with the corresponding library.

I always thought of this project to be more like the npm registry which for technical/historical reasons is technically backed by a simple GitHub repo. With the npm registry (or almost any other registry) you can download all kinds of materials, but still not everything that you download is under the same license as npm itself - packages have their own licenses and often they have dependencies that have yet another license and this can all be perfectly fine from a legal/licensing point of view.

That's why I think it is an unnecessary restriction to enforce the MIT/Apache license on the usage of all the files and it should be possible to tell devs that if they decide to actually work with the contents of some of the files, they might have to agree to some other less or more restrictive license.

I will have to talk to the legal team, but I think we will simply remove our d.ts file from the repo (and don't require git history to be rewritten) if the project maintainers think we are violating the license with the header or causing any other problems, which I really don't want to.

And did I mention I hate licensing and legal issues?

Peace! - Sebastian

Some comments that don't really contribute to the actual issue, but I feel like I have to defend our position. I think there are some statements that make us look really bad, and I am very positive that we are not that evil:

You cannot invoke a legal claim against this behavior regardless of which license you publish under. No one reading your documentation website has any obligation to follow your wishes (apart from not violating your established copyright, trademark, or patent interests).

Really? How often do you read this every day: "By using this site/software you agree to .... blabla". Are you saying that all of this is superfluous (from a legal point of view, at least)?

You cannot unilaterally bind third parties to a contract of your choosing.

To be clear: I don't think that we are doing this. Just like with the above example there are things that can be legally prohibited. And to be clear again: Nothing what this project does or did is something that we try to prohibit.

If you're putting this information out there in a public forum, you cannot apply a EULA to people who read it any more than I can say "Anyone reading this GitHub comment owes me $10".

And to make it clear again: I don't think we are doing this. And for sure this is not how I would like it to be interpreted.

Also: I don't think anyone should be in trouble right now.

I don't agree here. Even if the licensing issue was corrected right now, there will always be a state in the Git history recoverable by anyone which creates the invalid license mix.

Just because something is "available on the internet" for whatever reason, this doesn't mean that it is out of control of any licensing.

AFAIU that's not what @RyanCavanaugh is saying. He's just say there's no realistic technical means to enforce the license obligations. But of course the obligations still apply, and you have all rights to sue someone who's not adhering to these obligations, if you manage to find that someone.

Just because you can do something, doesn't meant it's legal.

Exactly. Just because you can submit proprietary/confidential material to this project, it doesn't mean it's legal.

In this case, I could very well argue that the pull-request should have never been accepted if the policy is really the way you describe it, here.

I totally agree here, the PR should have never need accepted, and I'd like to propose to add a check to .travis.yml that runs e.g. ScanCode on any added files and blocks if anything else than MIT or Apache is found.

Also: I don't think anyone should be in trouble right now.

I don't agree here. Even if the licensing issue was corrected right now, there will always be a state in the Git history recoverable by anyone which creates the invalid license mix.

What I meant here, is that I don't see us (yWorks) wanting to take legal actions against anybody from this project or projects that depend on this project which are about redistributing the files for the purposes of what .d.ts files have been created for initially (IDE tooling, typescript compiler, etc.).

And most importantly we certainly never intended to affect the project itself or anybody who is using any of the other files in this repo.

If someone takes our copyrighted material and creates derivative works, released under a different license, this may be a different story. But I don't think this has happened, yet, and I don't think this would be a problem, unless that person really knowingly intended to do harm. Most importantly I personally would not blame this project for that. That said: our license terms aren't that strict (and they are available publicly and on request) and I don't think you can violate them "accidentally".

And regarding the "bad state in the repo" - I can't believe that this really is an issue, but IANAL. This would mean that every mistake that was ever made cannot be corrected anymore. Just because there was a time when something was legal/illegal, this doesn't mean it has to stay legal/illegal. If I could make it legal for the past (using whatever resolution), I would certainly want to do that. :-(