Dear all,
I sometimes notice that my code gets cut and pasted or vendored literally or modified in other projects. That’s very fine, it’s the reason why I publish almost all my code under a license that makes that extremely simple.
Yet people often fail to abide by the simple, single phrase request of the license which is (emphasis added):
Copyright (c) [year] [fullname]
Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
In all my source files you can find a header that has the copyright notice and a SPDX license identifier as per convention (example). So I kindly ask you when you reuse my code:
-
If you copy the whole file to retain that copyright header. Reformatting
the header is ok. Also if you end up reworking the code significantly
indicating:
(* Part of this code is based on the xxx project and
Copyright (c) 2020 The xxx programmers.
SPDX-License-Identifier: ISC *)
works for me.
-
If you copy say a single function please add a comment with the copyright
notice and the SPDX license identifier. For example:
(* This code is Copyright (c) 2011 The xxx programmers.
SPDX-License-Identifier: ISC *)
-
If you end up vendoring a significant part of the code without modifying
it (that is if technically you depend on the project) please mention it
in your toplevel LICENSE file.
Now let’s be clear, I will not call the police if don’t do this or if you pretend to have written code you did not. Police and lawyers are at the top of the list of people I do not want to deal with or inflict onto other people.
What I’m seeking here is attribution. Not for having my name in your project, I couldn’t care less and the copyrights of my projects are contributor based anyways. This is so that the code contribution can be traced for the few times I manage to convince people to pay me for making them rather than investing my own money in these projects.
Btw. this should not only be about my code. This is about any open source code you cut and paste from (and I also do this).
Ah and yes, please, if you are using them, also teach your LLMs to do that. If they are able to write OCaml code it’s also thanks to me :–)
Thank for your attention.
Daniel
23 Likes
Thanks for the tutorial!
Can you confirm that if we vendor a significant part (all 
) of the code but do modify it, we still mention it in our toplevel LICENSE file? What if we keep the original LICENSE file in the vendored dir?
(The concrete case is slipshow, where I vendor and modify the cmarkit library (as well as brr currently). There is currently no mention in the toplevel license file, but the original cmarkit LICENSE file is kept at the root of the vendored directory. If that is the wrong way to do it, I’ll be happy to add a mention in the toplevel license file!)
The problem is that it becomes easy to miss for users of your software. By reading the toplevel LICENSE file it should be easy for them to understand to which licenses they subject themselves. In particular if they want to package the software or integrate it in a commercial application. So I think you should at least mention and link on them.
For example since you are redistributing copies of these projects the machine readable LICENSE metadata bit you have here is wrong.
Usually if I integrate third-party code in my projects I always make sure all of it get properly credited in the toplevel LICENSE file and their license identifiers are properly tracked in the corresponding machine readable fields. Here are a few examples:
1 Like
No, it is correct. The license of a project can be a single one, as long as the licenses of all dependencies and source files other files are compatible ones. For example you cannot use the MIT for the whole project if a file or dependency uses the GPL.
As an example take a look at the Linux kernel, with is licensed under the GPL2 (and only this is mentioned in its license file (well, COPYING), but there are many files using compatible licenses.
MIT: linux/fs/vboxsf/file.c at bc9ff192a6c940d9a26e21a0a82f2667067aaf5f · torvalds/linux · GitHub
BSD: linux/arch/arm64/boot/dts/qcom/pm8937.dtsi at bc9ff192a6c940d9a26e21a0a82f2667067aaf5f · torvalds/linux · GitHub
…
This does not mean that the licenses of dependencies or files can be changed or removed or don’t have to be mentioned. It “just” means, that the project itself can have its “own” license (as long as its compatible).
Honestly I don’t care whether it’s correct or not and I rather not discuss this in this thread.
As far as I’m concerned when I devise a project and reuse other’s people licensed work, I prefer to give to end users an exhaustive list of all the license that these other persons chose in the machine readable license data rather than trying to make educated guesses about license compatibilities to eventually have an overly paid lawyer tell you those were wrong.
Again for me this is not about copyright law, which I couldn’t care less about, it’s a kludge I have to live with. It’s about proper attribution traceability for giving credits where it’s due because I also need to earn a living.
2 Likes
Ok, I’ll change the LICENSE file and opam field to include vendored licenses, and the README to better acknowledge the libraries and tools I depend on, especially those which are not directly listed as dependencies. Thanks for clarifying!
About the license opam field: I’m unclear on the “law” part of all this, but if I understand correctly, I would be allowed to change the license of vendored code to a stricter compatible one (eg from MIT to GPL). But I guess that is not the case(?): I’m not changing the license, so the opam license field does need to include the other licenses.
Again I rather not talk about legal issue in this thread because lawyers have a more refined common sense than all of us reunited and I’m not interested in it more than that.
However I suspect that this is not the case: unless you make significant changes to it you are not the author of the code and removing the current license would actually violate the terms of the simple license agreement (see my first message).